Quali sono i pro/contro di restituzione degli oggetti POCO da un repository rathen rispetto alle entità EF?

Question

Seguendo il modo in cui Rob lo fa, ho le classi generate dalla procedura guidata Linq a SQL e quindi una copia di quelle classi che sono POCO. Nei miei repository torno questi pocos, piuttosto che il LINQ to SQL modelli:

 
return from c in DataContext.Customer 
     where c.ID == id 
     select new MyPocoModels.Customer { ID = c.ID, Name = c.Name } 

Capisco che il vantaggio di questo è che i modelli POCO possono essere istanziati più facile quindi questo renderà il mio codice più verificabili.

Ora mi sto spostando da Linq a SQL su Entity Framework e sono a circa metà del libro EF. Sembra che ci sia molta bontà che ho intenzione di perdere restituendo POCO dai miei repository piuttosto che dalle entità EF.

Non ho ancora provato i test unitari, quindi mi sento come se stessi sprecando un sacco di tempo a creare questi POCO extra e scrivere il codice per popolarli, quando tutto ciò che guadagno è un codice verificabile, eppure Perderò anche molti dei benefici dell'EF non essendo in grado di tracciare i miei oggetti.

Qualcuno ha qualche consiglio per un newb relativo a tutto questo materiale ORM/Repository?

Anthony

Answer 1

Un'altra ragione per cui gli oggetti generati automaticamente non piacciono (ad esempio in LINQ to SQL) è dovuto alla loro "magia" incorporata.

In genere la magia è invisibile e non si nota mai, ma quando si tenta di eseguire operazioni come serializzare uno di questi oggetti e quindi deserializzarlo (ad esempio quando si utilizzano i servizi Web) la sua connessione interna all'origine dati è interrotta e gli hack speciali devono essere impiegati per "rimettere la magia".

Con POCOs, non devi preoccuparti di questo genere di cose e puoi ottenere una migliore separazione tra i tuoi dati e livelli di servizio. Lo svantaggio naturalmente è che devi scrivere un sacco di noioso POCO -> oggetto magico e oggetto magico -> codice di conversione POCO. Ma alla fine penso che ne valga la pena, specialmente per progetti grandi o complessi.

Answer 2

La ragione principale è che un sacco di gente piace sviluppare il loro modello con una mentalità specifica: come DDD per esempio. Potrebbero voler usare un modello specifico (come Spec o State) per cose come status (invece di enumerazioni) - o potresti voler usare una Factory per l'istanziazione.

OO si interrompe quando si tenta di utilizzare Tabelle come oggetti quando le cose diventano più complesse. I siti semplici funzionano bene, ma quando arrivi a grandi cose, diventa brutto.

Quindi, come sempre, dipende da cosa pensi che si trasformerà il tuo progetto.

Answer 3

La mia esperienza è che quando si avvia scrittura alcune query complesse metodo .include è inutile e vi troverete uno:

a) Scrivendo un sacco di domande per ottenere i dati che si desidera o b) abuso di annonymous tipi di caricare i dati in una singola query e quindi scrivere un sacco di codice solo per passare quei dati alle tue entità.

I POCO sono la strada da percorrere, IMHO.