Entity Framework nella confusione dell'applicazione n-tier

Question

Entity Framework nella confusione dell'applicazione n-tier

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)
#4 da (0 voti)

6

Sto costruendo un'applicazione piuttosto grande (web) in cui sto utilizzando Entity Framework per comunicare con il database.

La mia soluzione è impostata a strati in questo modo:

Client
- Sito web (applicazione Web MVC)
Server
- BusinessLogic (contiene, beh, business logic. C'è un lotto di regole aziendali coinvolte in questo progetto)
- Repository (contiene classi di repository per interrogare il database usando EF)
- Interfacce (interfacce per la definizione delle classi di repository, ovvero IFirmRepository )
- Modello (contiene il mio file edmx, visualizza modelli, enumerazioni ecc.)

Quindi, il client / UI conosce il livello della business logic in cui le classi di business necessarie per una determinata vista vengono iniettate nei controller MVC. Il livello della logica aziendale conosce le interfacce e il modello e il repository implementa le interfacce.

In sviluppo da un'ultima settimana con questo approccio, ho la sensazione che non sia del tutto "corretto" poiché:

Le classi di repository diventano ingombranti con molti metodi in cui ho bisogno di utilizzare il metodo Include() per poter lavorare con le entità disconnesse nel mio livello di logica aziendale
Per ogni query, sto utilizzando un nuovo contesto: using(var ctx = new MyContext()) e un singolo metodo di business logic potrebbe chiamare più di un metodo di repository che rende N numero di nuovo MyContext () che non è l'ideale, immagino ?
In relazione a quanto sopra: ho letto di avere un contesto per ogni richiesta http è la strada da percorrere quando si tratta di siti web, che il mio approccio sembra "violare"?
A parte la curiosità, ho provato a utilizzare semplicemente MyContext direttamente in una classe di business logic, rendendo necessaria la query per gli oggetti e quindi eseguendo la logica di business. Facendo ciò è stato molto semplice e facile e il repository sembra molto più utile del necessario e quasi ridondante.

Quindi, suppongo che diversi progetti abbiano bisogno di approcci diversi per quanto riguarda l'architettura, ma prima di cancellare completamente il mio repository e utilizzare il contesto della struttura dell'entità direttamente nelle mie classi di business logic, mi piacerebbe la tua opinione su questo. Sembra piuttosto sbagliato (nel senso che sto violando qualcosa) per graffiare il repository, ma d'altra parte, è così semplice fare semplicemente la magia senza prima definire il metodo in un'interfaccia, quindi implementarlo come repository e quindi fai uso di esso in una classe di business logic.

Quindi, qual è la tua opinione su questo? :-) Sono completamente fuori registro qui, o?

Grazie in anticipo.

.net asp.net-mvc entity-framework n-tier

posta Bo Mortensen 20.10.2015 - 09:15

fonte

4 risposte

Leggi altre domande sui tag .net asp.net-mvc entity-framework n-tier

Compila esplicitamente request.txt per i nostri progetti Python? Modular Filter Architecture per WPF

score 1 · Answer 1

Continua e gratta il repository. Se stai utilizzando Entity Framework, non ne hai bisogno. È solo un inutile strato di astrazione. Consiglierei di andare con un modello di servizio / fornitore. Creare un'interfaccia che esponga un'API che l'applicazione può utilizzare. L'interfaccia sarà l'unica cosa con cui lavori direttamente nella tua applicazione web. Utilizzerai l'integrazione delle dipendenze in sub in un'implementazione concreta.

Per quanto possibile, ti consigliamo di creare una o più classi che implementano questa interfaccia, ma solo una per metodo di accesso discreto, ad esempio Entity Framework. Potresti avere un altro se vuoi lavorare con un Web Api, per esempio. Questa implementazione dovrebbe essere generica , ma piuttosto che avere l'intera classe con un parametro di tipo, invece, vorrai che le implementazioni dei singoli metodi siano generiche. Ciò ti consente di istanziare un'istanza che può funzionare con l'intero contesto e qualsiasi entità che essa contiene.

Anche le tue entità dovrebbero implementare interfacce, in modo che l'implementazione del servizio possa riutilizzare il codice. Ad esempio, invece di avere GetPublishedFoos e GetPublishedBars , puoi semplicemente avere GetPublished<TEntity> , dove TEntity : IPublishable . Se sei intelligente su come imposti le tue interfacce, il tuo servizio non avrà bisogno di un sacco di metodi.

score 0 · Answer 2

Sembra che tu abbia troppi repository.

Come regola generale, proverei a seguirne uno per Database. Tutto questo è il tuo repository sottostante e le Tabelle (oggetti) in esso dovrebbero essere tutti correlati. Quindi posso aspettarmi query / metodi lile getFirmsWithCustomer ecc.

Penso che tu stia adottando l'approccio corretto per separare EF dalla logica di business quando hai un'applicazione di grandi dimensioni.

Vorrei andare oltre e dire non usare EF con questo modello. EF funziona meglio per piccoli progetti in cui si desidera saltare la scrittura del livello dati. Se vai per tutto il tempo con Sproc e repository usando il client SQL, sarà meno facile scrivere codice.

score 0 · Answer 3

Penso che la tua domanda sia qualcosa di simile a se usare il pattern di repository su Entity framework che stavo anche facendo ricerche di recente. Ecco un link che ho trovato con buone risposte.

La classe DBContext di Entity Framework implementa già il pattern Repository. Ora, se dovessimo astrarre lo stesso Entity Framework, se questo provider (EF) stesso cambierà in qualcosa come servizio web, xml ecc. In altri casi meglio andare senza classi di repository personalizzate.

score 0 · Answer 4

Direi di avere il tuo livello di servizio, usa DI per ottenere il contesto EF db (potresti mantenere questo contesto in vita se lo desideri). Crea metodi sul tuo livello di servizio che ottengono e fanno ciò di cui hai bisogno. Questi metodi interrogano i tuoi dati tramite EF DbContext. Questo livello di servizio deve essere utilizzato dalla tua WebAPI e quindi l'app chiama WebAPI. Ora la tua roba di back-end sotto il service cap può essere cambiata come vuoi ma fino a quando non è valida per il contratto, nessun altro deve cambiare downstream.

Una nota che puoi avere anche più livelli di servizio. Raggruppa i livelli di servizio per dominio.