Ho fatto un sacco di questo tipo di conversione e FWIW, direi che ci sono più somiglianze che differenze. Non credo che ci sia alcuna documentazione definitiva che vi farà sentire come un esperto in EF4, al di là della roba che è già là fuori ...
http://msdn.microsoft.com/en-us/library/ex6y04yf(VS.100).aspx
quello che posso dare tu sei il più evidente "trucchi". Nello specifico, Linq2Sql voleva combinare il livello aziendale e il livello dati in modo molto più evidente. Ti ha davvero spinto a creare le tue lezioni parziali. Potrei andare avanti all'infinito, ma il motivo più specifico è il modo in cui il programma di mappatura one-to-one creerà proprietà padre e figlio pubbliche per tutte le relazioni.
Se si tenta di utilizzare qualsiasi tipo di serializzazione contro questo modello, che sarà come incorrere in problemi di riferimento circolare come un serializzatore si sposta da un genitore di un bambino e poi di nuovo al genitore come il comportamento di serializzazione Linq2Sql include automaticamente tutti i bambini nel grafico. Questo può anche essere davvero fastidioso quando si tenta di afferrare un record del cliente per verificare la proprietà "Nome" e ottenere automaticamente tutti i record degli ordini correlati inclusi nel grafico. Puoi impostare queste proprietà di navigazione padre e figlio come "pubbliche" o "interne", il che significa che se vuoi accedervi, ma non vuoi che i serializzatori creino automaticamente riferimenti circolari, devi praticamente accedervi in modo parziale classi.
Una volta avviato il percorso di classe parziale, in genere si continua il modello e alla fine inizieranno ad aggiungere metodi di supporto per l'accesso ai dati nelle singole classi di entità. Inoltre, dato che il DataContext Linq2Sql è più leggero, spesso si trovano persone che usano un tipo di pattern Singleton o pattern di repository per il loro contesto. Non lo vedi per niente con EF 3.5/4.
Quindi supponiamo di avere un ambiente simile a quello descritto e di voler iniziare la conversione. Bene, devi scoprire quando il tuo DataContext verrà creato/distrutto ... alcune persone inizieranno ogni metodo di Business Layer con un'istruzione using() e lasceranno il contesto praticamente vivo per tutta la durata del metodo. Ovviamente questo significa che puoi entrare in alcune situazioni pelose che richiedono l'aggiunta di .ToList() o qualche altro metodo di estensione alla fine delle tue domande puoi avere una collezione completamente in-memory dei tuoi oggetti da passare a un metodo figlio o qualsiasi altra cosa quindi puoi avere problemi con il tentativo di aggiornare entità su un contesto dal quale non sono state originariamente recuperate.
Sarà inoltre necessario capire come gran parte di BusinessLogic incorporato nelle classi parziali di Linq2Sql viene esportato in un altro livello se non si occupa esplicitamente delle operazioni sui dati. Questo non sarà indolore come capisci quando hai bisogno/non hai bisogno del tuo contesto, ma è per il meglio ..
Successivamente, vorrai occuparti della situazione del grafico dell'oggetto. A causa della differenza nel modo in cui funziona il caricamento lazy (hanno reso questo configurabile in EF 4.0 per renderlo più simile a Linq2Sql per coloro che lo volevano) probabilmente dovrai controllare eventuali usi impliciti degli oggetti figlio nel grafico dal tuo Linq2Sql implementazione e verifica che ora non richiede un esplicito .Include() o un .Load() per ottenere gli oggetti figlio nel grafico.
Infine, sarà necessario decidere una soluzione di serializzazione in generale. Per impostazione predefinita, gli attributi DataContracts e DataMember generati come parte di un modello EF funzionano alla perfezione con WCF, ma non del tutto eccezionali con XmlSerializer utilizzato per cose come i vecchi servizi Web .asmx. Anche in questa circostanza potresti riuscire a farla franca se non hai mai bisogno di serializzare oggetti secondari sul filo. Dal momento che di solito non è il caso, vorrete passare a WCF se avete un SOA in più, che aggiungerà un intero nuovo host di opportunie, eppure mal di testa.
Per gestire la situazione delle classi parziali e il pesante DataContext e persino i problemi di serializzazione, con EF 4.0 sono disponibili numerosi nuovi modelli di generazione codice. Il modello POCO-Entity ha un sacco di gente entusiasta mentre crea le classi POCO, proprio come ci si aspetterebbe (il problema è che esclude qualsiasi attributo di classe o membro per WCF ecc. Ecc.). Inoltre, il modello Self-Tracking Entities risolve praticamente il problema del contesto, perché puoi trasmettere le tue entità e far loro ricordare quando e come sono state aggiornate, così puoi creare/disporre i tuoi contesti molto più liberamente (come Linq2Sql). Come altro bonus, questo modello è il modello go-to per WCF o qualsiasi cosa che si basa su WCF come Servizi RIA o Servizi dati WCF, quindi hanno già gli attributi [DataContract], [DataMember] e [KnownType].
Ecco un collegamento al modello POCO (non incluso nella confezione): (MODIFICA: non posso pubblicare due collegamenti ipertestuali, quindi visita il sito Web di visualstudio gallery e cerca "ADO.NET C# POCO Entity Generator")
Assicurarsi di leggere il collegamento sul blog del team di ADO.net sull'implementazione di questo. Potresti apprezzare la suddivisione del contesto e delle entità in progetti/assiemi separati se rientri nella categoria Servizio WebService vs. Servizio WCF. La generazione del proxy "Aggiungi riferimento al servizio ..." non utilizza gli spazi dei nomi allo stesso modo di "Aggiungi riferimento Web ...", pertanto potresti voler fare effettivamente riferimento all'assembly della classe di entità nell'app client in modo da poter "escludere" tipi da biblioteche di riferimento "o qualsiasi altra cosa sui riferimenti di servizio in modo da non ottenere molti riferimenti ambigui da più servizi che utilizzano lo stesso modello EF ed esporre tali entità ...
So che questo è lungo e sconclusionato, ma questi piccoli trucchi erano mooolto più di un problema per me che ricordando di usare context.EntityCollection.AddObject() al posto di context.EntityCollection.InsertOnSubmit() e context.SaveChanges() al posto di context.SubmitChanges() ...
Solo per i futuri lettori, sono stato in grado di farlo con un po 'di dolore seguendo questa risposta. L'unico vero problema è la parte manuale in cui è necessario riscrivere le query, ma anche questo non è male. – joshmcode