Sto progettando un po 'di software che si integrerà con il nostro sistema aziendale utilizzando i servizi web. Abbiamo a che fare con gli ordini di lavoro necessari per mantenere le attrezzature.
Abbiamo un po 'di disaccordo riguardo alla struttura del contratto. Ci sono due metodi al mio fianco, vorrei una singola classe di ordine di lavoro con tutte le proprietà relative all'ordine di lavoro al suo interno.
esempio (semplificato)
WO - class
Number - property
Description - property
WarrantyStatus - property
WarrantySettlementDate - property
LabourSteps<LabourStep>[] - list property
Children<WO>[] - list property
Da parte loro, vogliono creare una classe ordine di lavoro, ma per ciascun gruppo logico di dati, vogliono creare un'altra classe per racchiudere le proprietà.
esempio (semplificato)
WO - class
WOHeader - class
Number - property
Description - property
Warranty - class
WarrantyStatus - property
WarrantySettlementDate - property
LabourSteps<LabourStep>[] - list property
Children<WO>[] - list property
Ora avranno circa 8 classi nella definizione completa che vogliono creare tutte con alcune proprietà in ciascuna. Questo mi sembra un po 'esagerato e ha un po' di odore di codice o di anti-pattern.
Per il mio esempio, ho due classi, WO e LabourStep.
Hanno 4 classi per la stessa cosa WO, WOHeader, Warranty, LabourStep. Ci sarà sempre e solo un WOHeader per WO e lo stesso per Garanzia.
Il mio sembra molto più semplice da gestire i cambiamenti (aggiungi una nuova proprietà a WO e così via), ma è meno leggibile. Dalla loro parte, la struttura è un po 'più facile da leggere da parte di un umano, ma sembra che stia spingendo una visione logica sul contratto a cui non appartiene veramente. E aggiungere una nuova proprietà richiede potenzialmente una modifica al WO e la creazione di una nuova classe se è stato aggiunto un nuovo gruppo logico. Queste classi extra sono disponibili solo per raggruppare le proprietà.
Qual è la strada giusta da fare?
====== EDIT ==========
Frank - Sono completamente d'accordo con i tuoi pensieri ed è il modo in cui mi avvicino al mio sviluppo. Tranne in questo caso, il sistema aziendale monolitico di terze parti con cui ci stiamo integrando è stato scritto in un modo molto generico per cercare di soddisfare il maggior numero possibile di aziende. I dati sono distribuiti su tre tabelle in una mappatura uno a uno con la maggioranza in una tabella. C'è a malapena qualsiasi convalida. Non esiste il concetto di oggetto / cosa "Garanzia" in quel sistema. Le sue sole 3 proprietà contro un WO. Tutto il servizio Web funzionerà come un archivio dati, con il WO persistente nel suo complesso. per esempio. getWO () updateWO () createWO (). Non ci saranno mai metodi get / updateWarranty (). È tutto un solo blob di dati da leggere / persistere.
Da parte nostra, non usiamo mai il risultato direttamente dai servizi web, anche se sono nostri. Li convertiamo in modelli appropriati e poi li usiamo. Per noi un contratto di dati è molto diverso da un modello. Non vi è alcuna logica aziendale nel contratto di dati, è puramente un contenitore per ottenere dati da una parte del sistema a un altro senza strettamente accoppiandoli. Ciò significa che possiamo facilmente passare a un database anziché a un servizio Web e tutte le sue esigenze devono corrispondere all'interfaccia del servizio web. Questo ci consente anche di modificare i nostri modelli che possono includere anche i risultati di più servizi Web senza doversi preoccupare di limitare o modificare il formato dei contratti dati.
Quindi, quando penso in questi termini, avere i contratti di dati suddivisi in classi WOHeader o WOWarranty non ha alcun senso. Non sarà mai usato in quel modo, nemmeno da loro. È proprio lì per un bel gruppo logico di proprietà che non significano nulla da sole. Un blocco di regione attorno a tali proprietà avrebbe lo stesso effetto netto. I passaggi di lavoro ei dettagli delle attrezzature, tuttavia, hanno molto senso essere in classi separate in quanto entità separate e non solo proprietà degli ordini di lavoro.