C# Data Layer e Dto's

Question

Mi sono unito a una società che utilizza set di dati digitati come "Dto". Penso che siano davvero spazzatura e vogliano cambiarla in qualcosa di un po 'più moderno e user friendly. Quindi, sto cercando di aggiornare il codice in modo che il livello dati sia più generico, cioè utilizzando interfacce, ecc., L'altro ragazzo non sa cosa sia un Dto e stiamo avendo un leggero disaccordo su come dovrebbe essere fatto.

Senza tentare di influenzare le persone al mio modo di pensare, vorrei ottenere risposte imparziali da voi persone su quali livelli Dto può essere presente. Tutti gli strati; DAL, BL e Presentation o un piccolo sottoinsieme solo all'interno di questi livelli.

Inoltre, se gli oggetti IList dovrebbero o non dovrebbero essere presenti nel DAL.

Grazie.

Answer 1

Dipende davvero dalla tua architettura.

Per la maggior parte del punto, dovresti provare a codificare le interfacce, quindi non importa quale sia la tua implementazione. Se si restituisce ISomething potrebbe essere il tuo SomethingEntity o il tuo SomethingDTO ma il tuo codice consumante non importa meno finché implementa l'interfaccia.

si dovrebbe essere di restituire un IList/ICollection/IEnumerable su un insieme o una matrice di cemento.

• Properties should not return arrays
• Do not expose generic lists

Che cosa si dovrebbe cercare di fare prima è separata il codice e renderlo debolmente accoppiati con l'inserimento di alcune interfacce tra i livelli, come un repository per il vostro livello DataAccess. Il tuo repository restituisce quindi le tue entità incapsulate da un'interfaccia. Ciò renderà il tuo codice più testabile e ti permetterà di deridere più facilmente. Una volta effettuati i test, è possibile iniziare a modificare le implementazioni con meno rischi.

Se si inizia ad utilizzare interfacce vorrei suggerire l'integrazione di un CIO come Windsor il più presto possibile. Se lo fai fin dall'inizio, renderà le cose più facili in seguito.

Answer 2

Una cosa è che i DataSet sono scarsi per raggiungere l'interoperabilità. Anche i set di dati digitati non sono altrettanto compatibili quando si tratta di consumare set di dati digitati da un client non .net. Fare riferimento a this link. Se devi raggiungere l'interoperabilità, combatti duro per DTO, altrimenti cerca di far capire al tuo team i DTO per un periodo di tempo, perché i set di dati non sono poi così male.

Su una parte delle interfacce, si dovrebbe esporre le interfacce. Ad esempio: se si restituisce List<T> da DAL, è necessario restituire IList<T>. Alcune persone vanno fino al punto di restituire solo IEnumerable<T> perché tutto ciò che serve è la capacità di enumerare. Ma poi mentre lo fai non diventa astronaut architect.

Nelle mie applicazioni che ho capito che il ritorno IList<T> invece di List<T> inquina la mia base di codice con i codici di questo tipo:

//consider personCollection as IList<Person> 
(personCollection as List<Person>).ForEach(//Do Something) 

Quindi io personalmente cerco di mantenere un equilibrio tra l'interfaccia di ritorno o di un oggetto concreto. Se mi chiedi cosa sto facendo in questo momento, ti dirò che sto restituendo List<T>. Sono influenzato dal fatto di non diventare astronaut architect.

Answer 3

Uso sempre DTO, mai DataTable. Ma li uso solo per il trasferimento da BL a DL e viceversa. I miei livelli di presentazione sono spesso solo a conoscenza dei livelli di business e di servizio in caso di orientamento al servizio.

I vantaggi posso vedere da usare DTOS piuttosto che DataTables:

• facile refactoring
• produzione semplice diagramma
• codice più pulito più leggibile, soprattutto in unit test del DAL

Answer 4

Per definizione, un DTO è un oggetto di trasferimento dati, utilizzato per (attendere) il trasferimento dei dati da un livello all'altro.

I DTO possono essere utilizzati su tutti i livelli e li ho utilizzati bene con i servizi Web.