Utilizzando entity framework Entity Framework come oggetti business?

Sto utilizzando il mapper O / R di Entity Framework di Microsoft e utilizzo di classi di quadro (classi generate associate a oggetti DB) come oggetti di business. Va bene? Si prega di indicare i vostri contro o professionisti. Che cosa fare in caso di comunicazione WCF tra livello aziendale e presentazione, come inviare tali oggetti come membri dati?

Sto usando EF in questo modo e una caratteristica interessante è che le quadro generate sono classi parziali, che consentono di estenderle in modo abbastanza protetto dai problemi di rigenerazione.

Date anche un’occhiata a questo link su MSDN che descrive alcuni scenari di utilizzo comuni con EF in relazione a Business Logic.

Prima di tutto, con 11k punti di vista al momento della stesura di questo articolo, sono un po ‘sorpreso dalla mancanza di risposte e con il dovuto rispetto, la qualità delle risposte, data una domanda abbastanza semplice.

Quindi, ora che mi sono sfogato un po ‘, vorrei rispondere a questa domanda perché penso che si applichi ancora di più oggi con la recente versione di Entity Framework Code-First.

“Utilizzare quadro Entity Framework come oggetti business?”

Un paio di punti di chiarimento prima di iniziare:

  • Quando si dicono “oggetti business”, ho l’impressione che questi oggetti a cui si fa riferimento contengano regole o logiche che vanno, ad esempio, dalla semplice convalida (cioè campi obbligatori) a una logica più complessa (es. Tassa di elaborazione alla cassa).

  • Non penso di poter rispondere alla tua domanda successiva riguardante WCF. La ragione di ciò è semplicemente perché risponderò oggettivamente alle vostre domande su EF come oggetti di business che poi mi obbligherebbero soggettivamente a prendere una posizione dimostrando contraddittorio del mio tentativo di rispondere in modo genuino e oggettivo alla prima domanda.

Detto questo, sul tuo EF come domande su oggetti business …

“Sto utilizzando il mapper O / R di Entity Framework di Microsoft e utilizzo di classi di quadro (classi generate che sono mappate su oggetti DB) come oggetti di business. È OK?”

Scusa, semplicemente non c’è una risposta giusta o sbagliata qui. Dipende da quale sia il tuo objective e da ciò che ritieni essere il design più ragionevole, pur comprendendo pienamente i vantaggi e gli svantaggi di farlo.

“Si prega di indicare i tuoi contro o professionisti”

Sono contento che tu abbia chiesto! Sarò felice di rispondere e la mia speranza è che, dati i pro e i contro, sei in grado di prendere una decisione informata sul fatto che tu creda o meno che usare EF per i tuoi oggetti aziendali sia “OK”. Tipicamente, scoverei i pro ei contro rendendo facile “digerire”, tuttavia, non penso che sia appropriato qui perché penso che faremmo un’ingiustizia a un argomento così interessante che è anche vicino e caro al mio cuore.

Prima di tutto, lasciami parlare tecnicamente per un momento … Sei in grado di utilizzare gli oggetti EF come oggetti di business, non c’è nulla che tecnicamente ti impedisca di farlo. Infatti, EF Code-First (CF) semplifica enormemente ciò che consente di creare POCO e di applicare le annotazioni di dati per la semplice convalida e l’implementazione di IValidatableObject per convalide più complesse. Molto carino, eh?

Qui sta il cuore della discussione.

EF, o qualsiasi ORM, è progettato per supportare la gestione dei dati. La sua responsabilità principale sono i dati e quindi gli oggetti che crei sono incentrati sui dati. Quindi, se stai cercando di progettare i tuoi oggetti in base al loro comportamento, allora hai un po ‘di enigma a portata di mano. In breve questo enigma è chiamato disadattamento di impedenza. Immaginare questo; hai due casi d’uso richiesti nella tua domanda:

  1. Una schermata per modificare un utente
  2. Un controllo per visualizzare un sottoinsieme di sola lettura delle informazioni dell’utente

Se si utilizza EF (qualsiasi sapore) o qualsiasi ORM per quella materia, si potrebbe gravitare sull’utilizzo dello stesso object “Utente” per gestire la possibilità di salvare un utente e di recuperare un sottoinsieme di campi di sola lettura. Probabilmente lo fai per uno dei seguenti motivi:

  1. Come molti sviluppatori, abbiamo questo seme piantato nel nostro cervello durante l’educazione “il codice di consolidamento” è della massima importanza o forse meglio noto come DRY – Non ripetere te stesso, e quindi si può guardare la duplicazione del codice, come proprietà, in un contesto negativo.
  2. Gli ORM, come EF 4.1, hanno limitazioni tecniche (e aggiramenti di tipo hacker) come mappare più POCO / oggetti sulla stessa tabella di database, forzandoti così a prescindere dalle tue convinzioni.
  3. È un modo semplice e veloce per avviare un’applicazione funzionante
  4. “Sente” come la cosa giusta da fare

Ci sono vantaggi e svantaggi nel fare ciò e potresti considerare che questo è positivo o negativo a seconda della tua opinione.

Suppongo che se credi nella normalizzazione del codice sul comportamento di quanto tu sia riuscito molto. Sei stato in grado di limitare la quantità di codice, potenzialmente risparmiando tempo, scrivendo un singolo object per gestire i tuoi dati e casi d’uso aziendali per quell’ quadro.

E suppongo che se credi nella normalizzazione del comportamento sul codice di quanto tu abbia fallito miseramente. Risparmiando sul codice, hai sacrificato la progettazione di oggetti in base alle loro responsabilità, rendendo potenzialmente difficile la gestione e aumentando successivamente i costi di manutenzione.

A prescindere dalla tua opinione, probabilmente siamo tutti d’accordo sul fatto che questo object di business ha assunto molteplici responsabilità e il comportamento (non i dati!) Dell’object è secondario nella migliore delle ipotesi. La sua responsabilità principale è la gestione dei dati e le sue responsabilità secondarie sono l’elaborazione delle regole aziendali, sia semplici che complesse, coinvolte nella modifica di un utente e nella visualizzazione di informazioni utente di sola lettura. Nella progettazione orientata agli oggetti (OOD), se il design di un object è caratterizzato dalla sua id quadro e dal suo comportamento, questo object potrebbe essere un individuo confuso in quanto non aderisce alla stessa definizione di OOD.

Qualcosa da considerare da un punto di vista tecnico, ogni volta che si richiede l’object utente si eredita una quantità significativa di sovraccarico. Ciò potrebbe includere cose come tutte le proprietà e le regole aziendali quando si visualizza solo un sottoinsieme di informazioni di sola lettura.

Quindi cosa c’entra tutto questo con se dovrei usare o meno EF per rappresentare i miei oggetti di business?

Bene … Mentre è tecnicamente ansible, ci sono diverse filosofie (alcune buone, altre cattive) sull’opportunità o meno di usare EF, o qualsiasi ORM, per rappresentare i tuoi oggetti di business. Ho dato una sinossi rivolta al cuore di queste filosofie sopra, ma sono documentate in modo molto più dettagliato da individui come Rocky Lhotka e Martin Fowler.

La direzione che prenderai dipenderà molto probabilmente dall’applicazione e da una visione filosofica, potrebbe dipendere da quanto idealista o pragmatico tu sia. Detto questo, non sto insinuando che uno sia un idealista o un pragmatico correlato all’utilizzo di EF per oggetti di business o no – avrà semplicemente un impatto su questo.

Al momento della stesura di questo documento, le indicazioni di Microsoft indicano che gli EF sono costruiti per gestire la logica aziendale e, nel bene o nel male, sembrano muoversi maggiormente in quella direzione. EF è in continua evoluzione e alcune limitazioni tecniche vengono eliminate in modo tale che EF possa eventualmente essere utilizzato per soddisfare il meglio dei due mondi. In altre parole, alla fine potresti essere in grado di avere la tua torta e mangiarla anche tu.

Spero che questo ti aiuti.

Off per rispondere a una domanda sull’opportunità o meno di ignoranza della persistenza con un ORM è ridicolo considerando lo scopo dietro di esso è quello di gestire i dati. 🙂 Scusa, non ho potuto resistere!

Il framework Entity è stato progettato per gli oggetti entity framework da utilizzare come oggetti business, ma è necessario tenere presente che gli oggetti business saranno legati alla tecnologia O / R e al modello EDM. In EF 1.0, non esisteva alcun supporto per gli scenari di persistenza-ignoranza , ma il supporto è stato aggiunto in 4.0. È ansible implementare interfacce , se non si desidera utilizzare alcuna delle loro classi di base.

A partire da .NET 3.5 SP1, dovrebbero essere utilizzabili anche come parametri e tipi restituiti nei metodi di servizio WCF senza alcun codice aggiuntivo.

Nella mia esperienza, abbiamo utilizzato oggetti EF all’interno del livello aziendale della nostra applicazione, ma quando effettuiamo la transizione nel livello di presentazione tramite il nostro livello di servizio WCF, creeremo oggetti di visualizzazione dagli oggetti EF.

Nel nostro caso, solo la vista viene passata al livello di presentazione. Lo facciamo per controllare come vengono presentati i dati e applicare la validazione difensiva per i dati provenienti dal livello di presentazione.

Nel caso di ueing di oggetti EF nella transazione WCF, perderai il contesto dell’object a cui è stato associato l’object EF. Ci sono alcuni sforzi in CodePlex che cercano di aiutare con questo, ma non ho tenuto il passo con i loro sforzi.

Due limitazioni per essere a conoscenza di ciò che ho incontrato sono:

  1. Gli oggetti ereditati non possono avere proprietà di navigazione – cioè se si dispone di una class “persona” e quindi di un “cliente” e “fornitore”, tali clienti e fornitori non hanno proprietà di navigazione.

  2. Metodi e campi calcolati (qualsiasi cosa nelle classi parziali) non vengono trasmessi su ADO.Net Data Services – se si utilizza anche ADO.Net Data Services qualsiasi cosa che si espande gli oggetti Entity Framework in classi parziali non saranno trasmessi su ADO.Net Servizi dati.

Generalmente questi non sono elementi di tipo show-stopper (per le proprietà di navigazione non usiamo l’ereditarietà sul framework di quadro, per ora), ma potrebbero essere di tuo interesse. Spero che una futura versione abiliti entrambi questi elementi.

Non puoi semplicemente ricolbind gli oggetti se perdono il loro contesto object originale? Avresti comunque bisogno di gestire i problemi di concorrenza.

Non suggerirei di utilizzare oggetti EF come oggetti DataContract per WCF, poiché legherebbe molto fortemente l’implementazione degli oggetti quadro ai client del servizio Web, in futuro sarà difficile apportare modifiche, più il numero di clienti che si intende avere sarà più difficile.

L’applicazione di esempio BookLibrary di WPF Application Framework (WAF) mostra come il pattern Model-View-ViewModel (MVVM) può essere utilizzato in combinazione con Entity Framework.