Quali sono i vantaggi dell'utilizzo degli uni sugli altri? So che le lezioni di POCO sono più ottimali, ma valgono la pena di esagerare? E dovremmo sempre usare POCO o c'è un momento in cui preferisci le classi di entità?Classi basate su Entity Framework POCO Vs?
Le classi EF predefinite ereditano tutte dalla classe base EF, mentre POCO non lo fa (da cui il nome). Mentre si eredita dalla classe base EF, la logica alla base del rilevamento delle modifiche è nascosta e tutta la logica è archiviata nel contesto che contiene riferimenti ai propri oggetti. Questo è preferibile se stai lavorando in uno stato connesso, cioè hai un contesto nello stesso momento in cui hai delle entità. Questo è solitamente il caso in cui si costruisce il client "grasso", quindi il client e il database sono gli unici due livelli.
D'altra parte, se stai lavorando con web services/web form, le entità che passi in giro non hanno un contesto e devono monitorare lo stato stesso - quindi il POCO è l'opzione migliore, dal momento che avere un oggetto di rilevamento delle modifiche come proprietà che può essere trasferito fino a quando non si decide di applicare le modifiche al contesto e salvare. Un altro vantaggio sarebbe che i tuoi clienti non devono essere .NET e non devono avere la DLL di EF per deserializzare i tuoi oggetti.
La ragione per cui utilizzo POCO è la separazione delle preoccupazioni, ovvero non voglio che il mio front end debba sapere come funziona il mio back-end. Quindi, se voglio passare da Linq a Sql a EF o N Hibernate, non devo modificare il mio codice di front end.
Utilizzare POCO se si desidera un'architettura pulita, un accoppiamento lento e una testabilità eccellente.
Se non ti importa di quelle cose, allora non usarle.
Personalmente per me quelle sono le cose più importanti in qualsiasi applicazione (specialmente quella che deve essere mantenuta per un lungo periodo di tempo), quindi uso sempre POCO.
Con questo in mente, POCO richiede di implementare una sorta di meccanismo di rilevamento delle modifiche, che può essere complicato. Ma è una cosa di installazione di una volta, e vale la pena.
Ho questa logica in una DLL personalizzata che condivido tra progetti - quindi non devo continuare a farlo ancora e ancora.
Per ulteriori informazioni sul motivo per cui i POCO sono importanti nel senso generale (non specifico per EF/.NET), consultare la risposta here.
Guardate seguenti articoli:
Perché non semplicemente rappresentare il vostro "POCO" con un'interfaccia che le vostre classi EF generato possono implementare? Quindi l'interfaccia utente (o il servizio di livello superiore) può ottenere un accoppiamento e una testabilità allentati, invece di risolvere solo le definizioni dell'interfaccia ... E non sarà necessario scrivere/eseguire funzioni di conversione. – Reddog
@Reddog - Beh, il mio assembly POCO non ha riferimenti a 'System.Data.Entity', non fa affidamento su EF. Se si utilizzano classi generate da EF, la libreria di classi diventa "vincolata" a EF. Se voglio passare a un altro ORM (o DAL), posso riutilizzare le mie classi POCO. Lo stesso non si può dire con le classi generate da EF. Non si tratta solo di un accoppiamento libero da altri progetti *, si tratta di un accoppiamento lento tra POCO e Entity Framework stesso. Permette un vero "modello di dominio". – RPM1984