Entity Framework 4 / POCO - Da dove iniziare? [chiuso]


183

Ho programmato per un po 'di tempo e ho usato LINQ-To-SQL e LINQ-To-Entities in precedenza (anche se durante l'utilizzo di entità è stato su una relazione Entity / Table 1-1 - cioè non molto diverso da L2SQL)

Ho letto molte cose su Inversion of Control, Unit of Work, POCO e modelli di repository e vorrei utilizzare questa metodologia nelle mie nuove applicazioni.

Dove sto lottando è trovare una guida per principianti chiara e concisa per EF4 che non presuppone la conoscenza di EF1.

Le domande specifiche a cui devo rispondere sono:

Prima il codice / il modello? Pro / contro rispetto a EF4 (ovvero cosa succede se eseguo prima il codice, cambio il codice in un secondo momento e devo rigenerare il mio modello DB - I dati vengono conservati, trasformati o eliminati?)

Supponendo che vado prima al codice (mi piacerebbe vedere come EF4 lo converte in uno schema DB) come posso iniziare? Molto spesso ho visto articoli con diagrammi di entità che affermavano "Quindi questo è il mio modello di entità, ora vado a ..." - Sfortunatamente, non sono chiaro se hanno creato il modello nel designer, salvato in generare codice quindi interrompere qualsiasi ulteriore generazione di codice automatico -o-- Hanno codificato (POCO)? classi e in qualche modo le hanno importate nella vista deisgner?

Suppongo che ciò di cui ho veramente bisogno sia capire da dove provenga la "magia" e come aggiungerla se non sto solo generando un modello EF direttamente da un DB.

Sono consapevole che la domanda è un po 'vaga ma non so cosa non conosco - Quindi ogni input / correzione / chiarimento è stato apprezzato.

Inutile dire che non mi aspetto che nessuno si sieda qui e mi insegni EF - Vorrei solo dei buoni tutorial / forum / blog / ecc. per i neofiti dell'entità completa


3
stai davvero DAVVERO attento alla durata delle tue connessioni: bit.ly/fi83NV È qualcosa di cui dovresti davvero essere consapevole quando astratti i contesti in repository. Potrebbe sembrare che
funzioni,

@BRitishDeveloper - Ottimo consiglio. Questo in realtà ci ha colto di sorpresa ma in modo opposto: stavamo usando un contenitore IoC per recuperare i repository e abbiamo riscontrato un problema in cui il contesto assegnato al repository avrebbe chiuso la connessione dopo un certo periodo di tempo ma non sarebbe stato contrassegnato come eliminato / simile. Alla fine abbiamo esteso il contesto noi stessi con un IsDisposed () che ha verificato il solito stato di smaltimento e lo stato di connessione che ci consente di crearne un altro, se necessario.
Basic

Un altro consiglio utile è che quando si ottiene un nuovo contesto, gli oggetti associati al vecchio contesto non avranno il rilevamento delle modifiche appropriato e causeranno problemi di mancata corrispondenza del contesto. Quindi, se si dispone di un'app di lunga durata e si cambia contesto a metà esecuzione, è necessario recuperare nuovamente tutte le entità. Per renderlo più interessante, in realtà abbiamo dovuto avere 2 in esecuzione fianco a fianco a volte e abbiamo finito per scrivere un po 'di codice da mappare tra i 2 ...
Basic

1
@Basiclife Mi sono imbattuto in quello stesso problema :) Ho intenzione di scrivere i miei pensieri sull'aggiornamento di entità distaccate per un po 'e mi hai appena incoraggiato a fare proprio questo: britishdeveloper.co.uk/2011/03/…
British Devevoper

Risposte:


56

Questi articoli potrebbero essere di interesse ... la serie affronta davvero i vantaggi e gli svantaggi di un approccio POCO.

http://blogs.msdn.com/b/adonet/archive/2009/05/21/poco-in-the-entity-framework-part-1-the-experience.aspx

http://blogs.msdn.com/b/adonet/archive/2009/05/28/poco-in-the-entity-framework-part-2-complex-types-deferred-loading-and-explicit-loading. aspx

http://blogs.msdn.com/b/adonet/archive/2009/06/10/poco-in-the-entity-framework-part-3-change-tracking-with-poco.aspx

In questi articoli l'autore cita articoli futuri che descrivono le migliori pratiche nell'implementazione di modelli di repository e unità di lavoro, ma non riesco a trovarli. Questi articoli sono ben scritti e mi piacerebbe leggere di più da questo autore.


2
Come qualcuno già a proprio agio con Entity Framework utilizzando il designer, questa è stata un'ottima introduzione a POCO.
nathanchere,

1
Se stai cercando il follow-up dell'Unità di lavoro si trova su blogs.msdn.com/b/adonet/archive/2009/06/16/…
Mike


7

Ti consiglio di impiegare circa mezz'ora e generare un modello EF1.0 stabile nel tuo VS attuale. Ciò ti consentirà di fare molta strada per comprendere le metafore e i concetti di EF 4.0. Basta montare un semplice cliente, prodotti e ordini db ... Consiglio di fare il tuo e non usare Northwind.


4

Questa è una grande domanda, ma difficile da aggiornare mentre Entity Framework continua a maturare. Probabilmente il miglior punto di partenza che rimarrà aggiornato nel futuro è la pagina EF di Microsoft .

Alcuni altri link che ho trovato utili mentre cercavo su Google (incentrato prima sul codice):


3

Puoi prendere il libro di Lerman o qualcosa di più semplice come "Mappatura relazionale di oggetti Pro Linq". Tutti i concetti sono sempre gli stessi con POCO, tranne per il fatto che ora dovresti disabilitare la generazione del codice e mappare direttamente il tuo modello in edmx csdl (o creare il tuo generatore POCO). Tutti i principi di mappatura sono uguali. In ogni caso, in fase di esecuzione si sta lavorando con un proxy derivato dall'oggetto POCO, pertanto è necessario preoccuparsi del supporto dell'intercettazione (virtualizzazione delle proprietà POCO).



2

Ecco una procedura dettagliata sul modello POCO per Entity Framework che sembrava piuttosto buono. Potresti anche voler consultare il blog del team ADO.NET . Se vuoi iniziare dall'inizio (EF v1.0) come base per le tue conoscenze EF, ho trovato il libro del Framework Entity Programming di Julia Lerman molto completo.


Grazie - non avevo visto il libro ma ho letto entrambi i link forniti. La procedura dettagliata del modello è utile per spiegare come una funzionalità aggiuntiva può essere aggiunta agli oggetti POCO una volta definiti (ad es. Caricamento pigro) ma (e potrei mancare qualcosa di ovvio qui) in realtà non spiega come iniziare (cioè semplicemente la creazione di una classe come specificato non la rende un'entità né la associa a un modello) Ho avuto un'esperienza simile con il blog. Prenderò in considerazione l'idea di ottenere il libro - Sembra promettente - Grazie.
Base

2
Per quanto riguarda il libro di Julia Lerman, vale la pena ricordare che sta lavorando ad una seconda edizione riguardante EF4: learnentityframework.com/LearnEntityFramework/book/… . Ricordo di aver letto da qualche parte che la data di pubblicazione prevista è a maggio di quest'anno, ma non riesco più a trovare la fonte. Inoltre ho appena trovato questo sito: nakedobjects.net/home/index2.shtml
Slauma

Slauma, il link che hai fornito sembrava esattamente quello di cui ho bisogno - tranne per il fatto che sta usando una libreria di "Naked Obects" di terze parti che sembra in qualche modo offuscare la complessità - Per un minuto, ho pensato che l'avresti rotto
Basic


1

Julia Lerman ha una bella serie di video introduttivi , circa 10 minuti ciascuno. Sono introduttivi, ma ci sono molti consigli pratici che impediscono ad alcuni potenziali blocchi stradali di apprendimento. Mi è piaciuta in particolare la sua dimostrazione di guardare l'effettivo SQL usando SQL Server Profiler.


1

Se hai intenzione di utilizzare cenari disconnessi, ti consiglio di leggere il libro di Julie Lerman: "Programmazione di DbContext", in uno speciale capitolo 4.

Ho trovato molti esempi nei blog, ecc., Ma quasi tutti riguardano i cenari collegati.

Sto iniziando anche io. e questi libri mi hanno aiutato molto. A proposito, le ho comprato tre libri.



0

Wow, molte risposte. Che ne dite di un esempio che contiene una versione ottimizzata dei modelli T4 che generano complessivamente interfacce + repository POCO +?

https://entityinterfacegenerator.codeplex.com


Interessante e utile per testare repository / contesti, ma perché dovresti astrarre le entità stesse? Per definizione non dovrebbero avere alcun codice funzionale al loro interno.
Basic

Hai ragione. Per lo più, le persone non dovranno avere interfacce separate. Ma aiuta le persone che vogliono risolvere riferimenti circolari e vogliono condividere le interfacce, non le classi reali, con una terza parte. Ciò sarà di grande aiuto se la tua azienda deve superare un audit con integrazione di terze parti che non richiede un'implementazione dettagliata nella condivisione.
Believe2014,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.