Confusione tra DTOs (linq2sql) e oggetti di classe!

Question

Ho lavorato con successo con linq2sql ei DTOs LINQ (le classi che vengono creati da linq2sql) ....

Sono confuso, ho il compito di aggiornare una vecchia applicazione e posso vedere che i miei DTOs saranno utilizzati come dovrebbero essere .... fino ad oggi il trasporto

Sto usando il modello repository in modo che io sto passando i dati dal repository al servizio tramite i DTOs Linq2SQL ... una volta che sono nel livello di servizio (questo è fondamentalmente la mia logica di business), poi ho bisogno di passare intorno agli oggetti di classe ..

questi oggetti di classe sono basicaly immagine speculare (più o meno) dei DTOs - ci sono alcuni cambiamenti in un certo posto, ma in generale lo stesso ..

Quindi, tornando alla domanda in mano! - è questa buona pratica di utilizzare DTOS solo ai dati di trasporto dal repository al livello di servizio ... e una volta nel livello di servizio (business logic) dovrei, ma tutti i miei MAPPATURA DTOs di là oggetto classe contro parti (ovviamente usando automapper! !)

La mia altra alternativa è quella di continuare a utilizzare gli DTOS come oggetti di classe e passarli in giro da metodo a metodo e come tipi di ritorno, ecc, ma sento che questo è cattiva pratica e continuo girare in tondo chiedendo quale metodo che intendo?

Qualsiasi aiuto molto apprezzato

grazie

Answer 1

Ecco la mia opinione: Quando si tratta di tutte le applicazioni non-banale. Utilizzando gli oggetti Linq2Sql come modello di dominio è davvero una cattiva idea. Vedo Linq2Sql come un ORM e nulla più. Basi di dati (che Linq2Sql ha una corrispondenza diretta a) è una normalizzazione dei dati . Le classi (nel senso OOAD) sono una normalizzazione dei comportamento (non dati).

  

[questi oggetti di classe sono basicaly immagine speculare] ...

ho incontrato questo quando la creazione di applicazioni con Linq2Sql. Consente di essere realistici .... più linea di applicazioni aziendali sono applicazioni CRUD glorificati. Quindi non è fuori questione che una grande percentuale di soggetti della vostra applicazione corrisponderà direttamente a tabelle di database. non volevo essere legati direttamente al DTO che sono stati generati, ma allo stesso tempo non volevo classi duplicate disseminati in tutta la mia domanda.

Quindi, ecco la mia soluzione:
I "programmato per l'interfaccia".

Diciamo che ho un PersonDto (Dto in piedi per Data Transfer Object) con le proprietà di FirstName, LastName, Age (che si riferiscono direttamente alle colonne del database).

Ho creato un'interfaccia IPerson e aveva la mia PersonDto implementarlo.

  [Table(Name="Persons")]
  internal class PersonDto : IPerson
  {
      ....
  }

E il mio metodo repository avrebbe preso in e recuperare IPerson in contrapposizione alla classe Linq2Sql.

    IPerson somePerson = _repository.Get(someGuid);
    somePerson.FirstName = "SomeName";
    _repository.Save(somePerson);

Questo approccio ha funzionato molto bene per me. Ogni volta che sento il bisogno di deviare dalla DTO, posso farlo abbastanza facilmente grazie ad un'interfaccia che rappresenta il mio oggetto in contrasto con il DTO.

Alcune indicazioni generali: Costruisci il tuo DTO di mano ... So che sembra pazzesco, ma vi accorgerete che funziona davvero bene con un top-down, test driven approccio di sviluppo. (Linq2Sql) gli oggetti del tuo DTO sarà estremamente leggero e saranno aperti ai cambiamenti di fuori del designer .dbml.

Mantenere interna del DTO e DataContext di. Non v'è alcun motivo per di essere esposti al pubblico (dato che si dispone di interfacce pubbliche per voi repository e oggetti di dominio) la tua dto. In questo modo si forza una separazione logica tra il modello di dominio e l'accesso ai dati.

Mettere tutto il vostro livello di accesso ai dati in un progetto separato (ancora una volta a far rispettare questa separazione).

Metti le dichiarazioni di interfaccia in un progetto separato (questo farà in modo di non incorrere in eventuali riferimenti circolari).

Spero che questo aiuti ...

Answer 2

In realtà ho avuto una domanda simile su questo argomento, anche se il mio intento era leggermente diverso. La raccomandazione è stato quello di utilizzare le classi Linq2SQL come gli oggetti di dominio e di approfittare di classi parziali come altri hanno detto. La mia preoccupazione principale è venuto con la forma di quegli oggetti (ad esempio nomi di proprietà), e l'accessibilità dei membri della classe (cioè V.S. privata protetta, ad esempio).

La forma degli oggetti e anche l'accessibilità possono essere affrontate utilizzando modelli T4 dove Damien Guardia ha messo insieme un modello T4 per consentire di controllare la forma delle classi che Linq2Sql genererebbe per voi. Questo può essere visto qui T4 modello per Linq2SQL .

Questo è l'approccio che ho intenzione di guardare in e vedere se affronta le mie preoccupazioni. Inoltre se il vostro livello di servizio può accettare interfacce verso argomenti del metodo è anche possibile controllare ciò che il livello di servizio ha accesso attraverso i wrapper di interfaccia intorno alla vostra Linq2SQL DTOs.

Spero che questo aiuti.

Answer 3

Questa è una delle migliori discussioni del tema che ho visto:

http://blog.wekeroad.com/ blog / LinqToSql-Momma-ha detto-knock-you-out /

Alla fine, le decisioni di accoppiamento e di coesione sono situazionale e si deve decidere cosa è meglio per la vostra situazione.

Quando l'applicazione diventa troppo grande per LinqToSql, quanto facile sarà per tirare fuori LinqToSql e inserire un altro ORM al suo posto? Questo è qualcosa che si deve riflettere seriamente.

In generale, ridurre al minimo la conoscenza vostro livello di business ha circa LinqToSql. LinqToSql dovrebbe essere completamente nascosto dal vostro livello di interfaccia utente (il vostro livello di business costituisce una buona fetta di questo scudo). E 'molto facile andare giù il percorso architettonico sbagliato con LinqToSql e può essere molto difficile tornare sulla strada giusta dopo il fatto.

Answer 4

Le classi generate dal progettista linq2sql sono classi parziali, in modo da poter estendere queste e mettere la logica di business direttamente in loro. L'idea è che LINQ è usato per persistere / ricostruire queste entità in modo da poter evitare il tipo di mappatura si sta parlando.