Ich erstelle eine Lösung von Grund auf mit ASP.NET Web Forms C #.
Ich mache mir Sorgen um die Modellobjekte, da ich keine doppelten Sätze von Modellobjekten in jeder Ebene erstellen möchte. Was ist die beste Vorgehensweise für die Verwendung von Model-Objekten in der 3-Layer-Architektur in Web Forms ?
Die Struktur, die ich mir vorstelle, ist wie folgt:
Das Modell enthält alle Modell Klassen , die in jedem Abschnitt der Ebenen verwendet werden können. Ich dachte, das wäre nützlich, da jede Ebene Zugriff auf die Modellobjekte benötigt. Zum Beispiel:
Danke
schau dir meine Antwort hier an: Ссылка Dies ist die übliche Art, wie ich Dinge mache und gut funktioniert, nicht nur für MVC und Entity Framework ... tatsächlich könnte das Modell in MVC ein Entitätstyp sein, der nur einige der Felder enthält, die von den realen Geschäftsentitäten enthalten sind, die in unteren Schichten definiert sind, es hängt davon ab, ob Sie wirklich alle Felder auch auf der Ebene der Benutzeroberfläche benötigen oder nur einige, um Daten zu rendern und einzugeben ...
Modelle können eine Querschnittsaufgabe mit Ihren Layern sein, was ein schneller Weg ist, dies zu tun. Oder Sie können Schnittstellen für Ihre Modelle erstellen, so dass Sie einfach die Oberfläche in etwas wie dem BLL ausstatten können - das verhindert zumindest, dass es übergreifend ist.
Es hängt außerdem davon ab, ob es sich bei Ihren Modellen um einfache Datencontainer ( anämisches Domänenmodell ) oder um Verhaltensweisen handelt, wie z die Möglichkeit, sich selbst zu validieren oder Änderungen selbst zu verfolgen ( Rich-Domain-Modell ).
Sie können feststellen, dass Ihre DAL tatsächlich aus zwei Teilen besteht: dem Vorlagenteil - nie spezifisch für einen App-Code, um mit der Datenbank zu sprechen, und dem App-spezifischen Populate-the-Model-Code. Wir haben diese Situation. Wir teilen Schnittstellen unserer Modelle herum, der App-spezifische DAL-Code kann diese Schnittstelle verwenden, um Daten vom Modell zu pushen und zu ziehen, aber der "wahre" DAL-Code arbeitet mit rohen Sachen.
In einer relativ kleinen Anwendung können Sie Ihre Domain Entities bis zu Ihrer Presentation layer teilen, beachten Sie jedoch die damit verbundene Kopplung.
Wenn Sie in Ihrer Datenbindung eine Entität vom Typ Customer mit einer Eigenschaft Address mit einer StreetLine1 und StreetLine2 Eigenschaft haben, sind alle Ihre Layer eng miteinander verbunden und eine Änderung in einer Ebene wird wahrscheinlich Änderungen verursachen in anderen Schichten.
Daher sollte Ihre Entscheidung auf dem Umfang Ihres Projekts und dem Umfang der Kopplung basieren, die Sie haben können.
Wenn Sie sich für ein niedriges gekoppeltes Design entscheiden, verwendet Ihr BLL Ihr DAL , um Entitäten abzurufen und diese Entitäten zu verwenden, um das Verhalten auszuführen. Das BLL verwendet dann Data Transfer Objects , um es an Ihr Presentation layer zu übergeben, so dass es keine Kopplung zwischen Ihrem presentation layer und Ihrem Domain Model gibt.
Als verwandtes Thema finden Sie in diesem Verwandte antworte , die ich vor Kurzem veröffentlicht habe, um Doppelungen von Code zu vermeiden und die Architektur in einem plattformübergreifenden Client / Server-System zu korrigieren.
Ich habe die anderen Poster in diesem Thread +1 gegeben, da dies keine vollständige Antwort sein soll, sondern nur nützliche Informationen zu dieser Frage.
Mit freundlichen Grüßen
Tags und Links .net c# architecture n-layer