Confusione tra DTO (linq2sql) e oggetti di class!

Ho lavorato con successo con linq2sql e con il linq DTO (le classi create da linq2sql) ….

Sono confuso, ho il compito di aggiornare una vecchia applicazione e posso vedere che i miei DTO saranno usati come dovrebbero essere …. per trasportare la data

Sto usando il modello di repository così sto passando i dati dal repository al servizio tramite il dtos linq2sql … una volta che sono nel livello di servizio (questa è fondamentalmente la mia logica di business), allora ho bisogno di passare oggetti di class ..

questi oggetti di class sono fondamentalmente un’immagine speculare (più o meno) del dtos – ci sono alcuni cambiamenti in qualche luogo ma generalmente lo stesso ..

Quindi tornando alla domanda in mano! – questa buona pratica è quella di usare dtos solo per trasportare dati dal repository al livello di servizio … e una volta nel livello di servizio (business logic) dovrei ma MAPPING tutti i miei dtos alle parti del contatore dell’object class (ovviamente usando automapper! !)

La mia altra alternativa è continuare ad usare gli oggetti di class come DTOS e passarli da metodo a metodo e come tipi di ritorno, ma ritengo che questa sia una ctriggers pratica e continuo a girarmi in tondo chiedendomi quale metodo dovrei applicare?

Qualsiasi aiuto davvero apprezzato

Grazie

Ecco la mia opinione: quando si tratta di un’applicazione non trival. Usare i tuoi oggetti linq2Sql come modello di dominio è una pessima idea. Vedo linq2Sql come un ORM e nient’altro. I database (su cui linq2Sql ha una corrispondenza diretta) è una normalizzazione dei dati . Le classi (nel senso OOAD) sono una normalizzazione del comportamento (non dei dati).

[questi oggetti di class sono fondamentalmente un’immagine speculare] …

L’ho riscontrato durante la creazione di applicazioni con linq2Sql. Siamo realistici …. la maggior parte delle applicazioni aziendali sono glorificate applicazioni CRUD. Quindi non è fuori discussione che una grande percentuale delle quadro della tua applicazione corrisponderà direttamente alle tabelle del database. Non volevo essere associato direttamente ai DTO che sono stati generati, ma allo stesso tempo non volevo che le classi duplicate fossero disseminate nella mia applicazione.

Quindi ecco la mia soluzione:
I “programmato su un’interfaccia”.

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

Ho creato un’interfaccia IPerson e l’ho implementata con PersonDto.

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

E il mio metodo di repository avrebbe IPerson e recuperato IPerson rispetto alla class Linq2Sql.

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

Questo approccio ha funzionato molto bene per me. Ogni volta che sento di dover deviare dal DTO, posso farlo abbastanza facilmente a causa dell’interfaccia che rappresenta il mio object rispetto al DTO.

Alcuni suggerimenti generali: Costruisci i tuoi DTO a mano … So che sembra pazzesco, ma troverai che funziona molto bene con un approccio di sviluppo guidato dall’alto verso il basso. Gli oggetti del tuo DTO (linq2Sql) saranno estremamente leggeri e saranno aperti alle modifiche al di fuori del designer .dbml.

Mantieni i tuoi DTO e DataContext interni. Non c’è motivo per cui i tuoi dto vengano esposti pubblicamente (dato che hai interfacce pubbliche per i tuoi repository e oggetti di dominio). Ciò comporterà una separazione logica tra il modello di dominio e l’accesso ai dati.

Metti tutto il tuo livello di accesso ai dati in un progetto separato (di nuovo per rafforzare questa separazione).

Metti le tue dichiarazioni di interfaccia in un progetto separato (questo ti garantirà di non imbatterti in riferimenti circolari).

Spero che questo ti aiuti…

In realtà avevo una domanda simile su questo argomento, anche se il mio intento era leggermente diverso. La raccomandazione era di usare le classi Linq2SQL come oggetti di dominio e di sfruttare le classi parziali come altri hanno menzionato. La mia preoccupazione principale è stata la forma di quegli oggetti (cioè i nomi di proprietà) e l’accessibilità dei membri della class (ad esempio, privato vs protetto per esempio).

La forma degli oggetti e persino l’accessibilità possono essere risolti usando i modelli t4 in cui Damien Guard ha messo insieme un modello T4 per consentire di controllare la forma delle classi che Linq2Sql genererebbe per te. Questo può essere visto qui template T4 per Linq2SQL .

Questo è l’approccio che esaminerò per vedere se risponde alle mie preoccupazioni. Inoltre, se il tuo livello di servizio può accettare interfacce con gli argomenti del metodo, puoi anche controllare a cosa ha accesso il livello di servizio tramite i wrapper di interfaccia attorno ai tuoi DTO Linq2SQL.

Spero che questo ti aiuti.

Questa è una delle migliori discussioni sull’argomento che ho visto:

http://blog.wekeroad.com/blog/linqtosql-momma-said-knock-you-out/

Alla fine, le decisioni di accoppiamento e coesione sono situazionali e devi decidere cosa è meglio per la tua situazione.

Quando la tua applicazione supera LinqToSql, quanto sarà facile strappare LinqToSql e inserire un altro ORM nella sua posizione? Questo è qualcosa su cui devi riflettere seriamente.

In generale, ridurre al minimo le conoscenze del livello aziendale relative a LinqToSql. LinqToSql dovrebbe essere completamente nascosto dal tuo livello di interfaccia utente (il tuo livello aziendale costituisce una buona parte di questo scudo). Con LinqToSql è molto semplice seguire il percorso architetturale sbagliato e può essere molto difficile tornare sulla giusta strada dopo il fatto.

Le classi generate dal designer linq2sql sono classi parziali, quindi è ansible estenderle e inserire la logica aziendale direttamente in esse. L’idea è che linq sia usato per persistere / ribuild queste quadro in modo da poter evitare il tipo di mapping di cui stai parlando.