Entity Framework in geschichteten Architektur

Question

Ich verwende eine geschichtete Architektur mit dem Entity Framework. Hier ist, was ich kam mit bisher (Alle Projekte Außer UI sind Klassenbibliothek):

• Entities: Die POCO Entities. Völlig beharrlich ignorant. Nein Verweis auf andere Projekte. Erstellt von ADO.Net POCO Entity Generator von Microsoft.

• DAL: Die EDMX-Datei (Entity Model) mit der Kontextklasse. (t4 erzeugt). Referenzen: Entities

• BLL: Geschäftslogikschicht. Implementiert Repository-Muster auf dieser Ebene. Referenzen: Entities, DAL. Hier wird die Object bevölkert wird: var ctx=new DAL.MyDBEntities();

• UI: Die Präsentationsschicht: ASP.NET-Website. Referenzen: Entities, BLL + eine Verbindungszeichenfolge Eintrag zu Entitäten in der Konfigurationsdatei (Frage # 2).

Nun meine drei Fragen:

1. Ist meine Schicht discintion Ansatz richtig?

2. In meinem UI, greife ich auf BLL wie folgt:
   var customerRep = new BLL.CustomerRepository();
var Customer = customerRep.GetByID(myCustomerID);

   Das Problem ist, dass ich die Entitäten Verbindungszeichenfolge in meinem UI web.config definieren/app.config sonst bekomme ich eine Laufzeitausnahme. IS definiert die Entitäten Connectionstring in UI verdirbt die Unterscheidung der Ebenen? Oder ist es in einer Multilayer-Architektur akzessorisch?

3. Sollte ich zusätzliche Schritte ausführen, um Chage-Tracking, Lazy Loading usw. durchzuführen (mit usw. meine ich die Funktionen, die Entity Framework in einer konventionellen, 1-Projekt, nicht POCO-Code-Generation umfasst)?

Vielen Dank und Entschuldigung für die lange Frage.

Answer 1

BLL lesen: Business-Logik-Schicht. Implementiert Repository-Muster auf dieser Ebene

Ich stimme nicht wirklich damit überein. Das Repository soll den zugrunde liegenden Datenspeicher (SQL-Server, XML usw.) abstrahieren. Es handelt sich um eine Datenschicht, nicht um eine geschäftliche Angelegenheit - warum sollte es also in der BLL sein?

Ist meine Layer-Diskontinuität korrekt?

Art von. :) Es ist ein bisschen subjektiv, aber in der Regel haben Sie:

• Daten
  • Repository geht hier.
• Geschäft
  • Geschäftsregeln, Geschäftslogik und Entitäten.
• Präsentation
  • UI/Web-Anwendung. Jetzt

, in der Regel diejenigen, drei sind weiter aufgebrochen. Also in Ihrem Fall würde ich habe:

1. MyCompany.MyProject.Data (Repository)
2. MyCompany.MyProject.Business.Services (Call-Repository, gilt Geschäftsregeln usw.)
3. MyCompany.MyProject.Business .DomainModel (Entities)
4. MyCompany.MyProject.UI (Web App)

Sollte ich irgendwelche zusätzlichen Schritte chage Tracking, verzögertes Laden auszuführen, usw. (durch etc I m Welche Funktionen bietet Entity Framework in einer herkömmlichen 1-Projekt-Generierung ohne POCO-Code?

Wenn Sie keine POCOs verwenden (z. B. verwenden Sie die Standardcode-Generierung). Dann müssen Sie sich keine Sorgen über Änderungsverfolgung machen.

Wie zum Lazy Loading - das ist eine Entscheidung, die Sie treffen müssen. Ich persönlich deaktivieren Lazy Loading, weil ich nicht faule Entwickler eine Reihe von Aufzeichnungen zurückgeben wollen, wenn sie nicht danach gefragt haben.

Stattdessen zwingen Sie den aufrufenden Code (z. B. das Geschäft/Service) eifrig Last, was es benötigt.

Wenn Sie eine ASP.NET MVC-Anwendung verwenden, wenn Sie Lazy Loading aktiviert haben, kann Ihre Ansicht die Datenbank zum Rendern aufrufen, wodurch das MVC-Muster zerstört wird.

Answer 2

1) Ebene scheinen gut zu mir

2) sehen Sie nicht ein Problem mit der Verbindungszeichenfolge in Ihrem UI app.config zu sein. Muss irgendwo definiert werden. Du könntest deine DAL.config in den BIN-Ordner deiner Anwendung kopieren, in dem wahrscheinlich die Verbindungszeichenfolge erstellt wurde, als du das Projekt erstellt hast, aber das scheint mir nicht richtig zu sein. Ich persönlich würde es in der UI-Ebene verwalten app.config

Answer 3

Das Problem ist, dass ich die Entitäten Verbindungszeichenfolge in meinem UI web.config/app.config anders zu definieren, habe ich eine Laufzeitausnahme erhalten.

Die Verbindungszeichenfolge wird immer aus der app.config/web.config der ausführenden appDomain abgerufen (hier Ihre asp.net App und nicht die DAL). So wat Sie tun können, ist für die Speicherung von Einstellungen in Ihrem DAL-Projekt eine XML-Datei erstellen und diese Einstellungen unter Verwendung von XML classses provided by dot net framework