Architettura a strati usando Entity Framework con diverse librerie di classi

2

Requisiti aziendali richiesti per creare un'architettura a strati e modulare. Così ho progettato un'architettura per renderla disaccoppiata e modulare possibile. Elencherò i miei livelli di seguito

  • ASP .NET MVC Application (UI)
  • Business Logic Layer (BLL)
  • Data Access Layer (DAL)

Ho utilizzato ulteriormente IOC in cui ogni modulo BLL definisce i requisiti di accesso ai dati in termini di interfacce. Quindi DAL deve ora implementare queste interfacce.

È importante notare che

  • Sia l'interfaccia utente sia DAL dipendono dalla BLL
  • BLL non dipende da nessuna altra soluzione. Usando le interfacce ho fatto IOC quindi ora DAL dipende da BLL e non viceversa.
  • BLL non è solo un progetto, ma una serie di progetti di librerie di classi - una libreria di classi ciascuna per ciascun modulo aziendale.
  • DAL è un progetto di libreria a una sola classe "condiviso" da tutti i progetti BLL (poiché il Database è lo stesso e non aveva senso dividere il DAL in progetti separati).

Non entrerò nei dettagli qui, ma diciamo che c'era una decisione di usare EDMX. Comunque ora non vedo come EDMX si inserirà in questo mix. Credo di non essere l'unica persona che abbia mai diviso il BLL in diverse librerie di classi, ma che abbia un unico progetto DAL. Ma l'EDMX o l'ORM supportano tale architettura "distribuita"?

    
posta devanalyst 23.01.2013 - 14:27
fonte

1 risposta

1

Suppongo che per EDMX si intenda Database First o Model First piuttosto che Code First (POCO). Puoi ancora fare il codice prima con POCO con un database esistente se questa è la ragione per usare EDMX.

Tuttavia, se sei assolutamente bloccato con un EDMX, puoi utilizzare gli oggetti di trasferimento dati POCO come wrapper attorno all'EDMX per isolarlo dal tuo BLL e dall'interfaccia utente superiore. Questa discussione sullo stesso argomento su Stack Overflow discute questa alternativa.

    
risposta data 23.01.2013 - 14:57
fonte