Quando utilizzare POCO in EF4?

Question

Abbiamo un sito Web ASP.Net MVC2 e utilizziamo EF4 per l'accesso al database, ecc. Essendo nuovo per EF4, abbiamo trovato il concetto P4 di EF4, tuttavia non lo capisco completamente.

In generale, ho sentito POCO definito come oggetti "non dipendenti da un framework esterno". Nel caso di EF4, suppongo che questo significhi che POCO implicherebbe in qualche modo la creazione di entità più leggere? In questo caso, quali impianti idraulici EF4 non dispongono di POCO, quali sono i pro/contro di ciò, quale ulteriore lavoro di sviluppo potrebbe essere necessario con POCO. In sintesi, quando è utile usare POCO in EF4?

Answer 1

"POCO" è un termine vago nello spazio ORM. La gente variamente usano per significare:

• "Pure" pocos, che non fanno rilevamento delle modifiche, lazy loading, hanno proprietà private, ecc Essi può essere difficile con cui lavorare.
• Proxy Psuedo-POCO: i tipi con tutto public virtual e che hanno tipi diversi in fase di esecuzione.
• Entità di tracciamento automatico. Non POCOs, ma non EntityObject neanche.

Trovo che la definizione "non dipendente da un quadro esterno" sia alquanto autonoma. È un modo per ignorare i limiti di un quadro. Ad esempio, i proxy non sono veri POCO nel mio libro, ma soddisfano questa definizione.

Cosa c'è che non va con EntityObject? Non molto. È abbastanza leggero e fa parte di .NET. È anche nel profilo del client .NET 4. Non ti lega nemmeno all'EF. Anche se sarebbe un po 'strano utilizzarlo come un "tipo POCO" con un framework diverso, funzionerebbe perfettamente. Non è in Silverlight, però, IIRC.

Le entità POCO sono più difficili da utilizzare, perché si perdono le cose che EntityObject fornisce gratuitamente. Non è molto, ma qualcosa da considerare prima di scegliere POCO solo perché "sono fantastici", specialmente per chi è nuovo all'EF.

Una cosa che molte persone che si fanno religiose sui POCO tendono a ignorare: la mappatura di tipi non POCO non limita in alcun modo l'esposizione esterna di quei tipi non POCO. I vostri servizi dati in grado di proiettare mappato tipi non-poco sopra non mappati POCO DTOs e si può scegliere di esporre solo i tipi, vale a dire:

public IEnumerable<FooDto> IFooRepository.SelectAll() 
{ 
    return from f in Context.Foos 
      select new FooDto { Id = f.Id, Name = f.Name }; 
} 

Così mappatura tipi e tipi di servizio dati possono essere facilmente diverse preoccupazioni, se lo si vuole .

Quando è necessario assolutamente non- EntityObject tipi di mapping? Bene, se hai bisogno di entità di auto-tracciamento, allora è un caso aperto e chiuso. Se devi esporre i tuoi tipi mappati a Silverlight, chiaramente anche allora.

Oltre a ciò è meno chiaro. Se stai scrivendo un servizio dati per il consumo pubblico, non dovresti fare in modo che i DTO siano sottotipi EntityObject, perché ciò impedirebbe di collegare un altro framework in seguito. Non renderei mai un'interfaccia pubblica immutabile dipendente da alcun framework, nemmeno uno incluso in .NET. D'altra parte, come ho detto sopra, puoi esporre un tipo e mapparne un altro; non è necessario esporre tipi mappati, mai, e spesso ottime ragioni per non esporli (forse contengono dati non pubblici).

Answer 2

Sono assolutamente d'accordo con Craig, POCO è qualcosa con cui è più difficile lavorare.

aggiungerò di più sullo scopo di POCO, spero che capirai quando dovresti usarlo e quando non usarlo.

modello e servizio è il nucleo

modello e servizio è uno dei pezzi più importanti della vostra applicazione, è un no-no-NO per cambiare, non si può evitare di modello e di servizio strettamente paio con qualsiasi parte della vostra applicazione, quindi il piccolo cambio di modello richiede il cambiamento dell'intera applicazione.

Si tratta di flessibilità

POCO è una questione di specifico per la lingua, non-quadro specifico. è una classe semplice, che non ha dipendenze con classi specifiche del framework, è possibile utilizzare POCO in tutte le versioni .net incluso micro framework e framework compatto.

E è di circa Testing

POCO veramente facile da test di unità, perché non ha la dipendenza con una classe non-unit test-friendly.

Si tratta di circa cambia

Upgrade/Downgrade, rendere nuova applicazione client in diversi environtment come MONO? non sarà un problema, puoi continuare a usare il tuo servizio e modello, anche per il peggior upgrade/down grade si verificherà solo su View e Service Cotext Helper.

Si tratta di naturale

creazione e l'utilizzo POCO è facile e naturale, è possibile scrivere i processi aziendali in modo chiaro.

Ma ricordate POCO non è amichevole con quadro

Sono d'accordo con Craig, POCO è TROPPO FREDDO, troppo freddo per fare amico con nuove persone. guarda WPF è necessario un modello che implementa INotifyPropertyChanged, che cosa fai per ottenerlo? puoi creare wrapper o puoi fare proxy dinamico del tuo modello. ma questo richiede una tecnica e un codice più avanzati da mantenere.