n-Tier-Architektur benötigt Bewertung

Question

begann ich meine Webseite, wie Stackoverflow, mit einer kleinen technischen Schulden, die ich zu tilgen bin versucht. Als Auftragsentwickler, habe ich an vielen Orten gewesen und sehe viele verschiedene Methoden der dieses Ergebnis zu erreichen, aber die Art und Weise werde ich ist ..

Präsentation (Web)

Business Layer (altmodische Entitätsklassen und BL-Schicht)

Data Layer (DA Klassen zu SQL Server über Stored Proc)

Meine Frage betrifft vor allem die Business-Schicht. Im Moment habe ich ein Entity-Namensraum und ein Businesslogic-Namespace.

Die BL hat einen Verweis auf die DA und der Entity. Die Einrichtung hat einen Verweis auf die DA (Die DA ist "nicht bewusst" des BL oder Entity)

ich meine Buttern wirklich alle wollen Daten in Einheiten des Drehens im BL auftreten - und damit die Business-Logik. Allerdings möchte ich das Unternehmen in der Lage sein, den BL zuzugreifen, wenn es sein muss -. Und damit der Verweis auf die DL Entity entfernen

So ...

Ist es „falsch“, um die BL und Entity-Objekte im gleichen Namensraum, so dass sie zusammenarbeiten können?

Im Grunde versuche ich, hat ein Entitätsobjekt wie Mitarbeiter (klassisches Beispiel, wie?) Und haben die Mitarbeiter eine haben

public Hashtable[] SubordinateEmployees

Eigenschaft, die eine Hashtable anderer Mitarbeiter Objekte zurückgibt, die an diesen Mitarbeiter berichten. Aber ich will nicht, es zu laden, bis es gebraucht wird. Also für die meisten Mitarbeiter würde das Eigentum nie zugegriffen, aber wenn sie es tut, ist es selbst Lasten mit einem Aufruf an die BL, die die DA nennt.

Ist die Frage sinnvoll?

Wenn ja, ist meine Lösung?

Vielen Dank im Voraus!

Answer 1

Die übliche Art und Weise mit der Art der Situation umgeht Ihr Beispiel darstellt, ist mit Fassaden. Anstatt zu versuchen, die untergeordneten Mitarbeiter aus dem Employee-Objekt zu erhalten, können Sie einen Anruf an die Business-Logik verwenden, um es zu bekommen.

hashtable = BL.GetSubordinateEmployees(supervisor);

Auf diese Weise haben Sie einen einzigen Zugangspunkt zu den Untergebenen, und es gibt nur eine Sache (BL), um die Datenschicht Zugriff auf und die Schaffung von Entities.

Answer 2

Lassen Sie mich sehen, wenn ich Ihnen einen besseren Weg zeigen kann, um darüber nachzudenken

Sie haben Ihren Datenzugriff (SQL Server, MySQL, flache XML-Dateien, etc.) all dies nichts anderes in der Anwendung abstrahiert werden sollte sollte weg kümmern oder wissen, wie Sie Ihre Daten erhalten, nur dass es Dosis, wenn alles andere weiß, wie Sie Ihre Daten bekommen Sie eine Schicht Verletzung haben. wenn die DAL Dosis etwas anderes dann Daten erhalten haben Sie eine Schicht Verletzung. Als nächstes Sie eine Datenzugriffsschnittstelle so etwas wie IDAL implementieren, die Ihr Business-Schicht verwendet, ist dies sehr wichtig für die durch Zwingen Sie Ihren Code testbar zu machen Ihre Schichten zu trennen.

Ihre Dateneinheiten können in der DAL-Namensraum platziert werden oder geben sie dort besitzen, so dass sie dort eigene Kräfte Trennung geben. Dateneinheiten sind stumme Objekte und sollte sehr wenig bis gar keine Logik enthalten und sind nur bewusst, sich selbst und die Daten, die sie haben, sie nicht Business-Logik ENTHALTEN !, DATA ACCESS LOCIC ODER UI LOGIC. wenn sie es tun haben Sie eine Schicht Verletzung. Die einzige Funktion einer Dateneinheit ist, Daten zu halten, und von einer Schicht zur nächsten weitergegeben werden.

Biz Schicht implementiert eine Datenzugriffsschnittstelle wie die IDAL wir darüber gesprochen, bevor Sie diese mit einer Fabrik instanziiert können ein IOC-Container, oder alle Stricke konkreten Fehler, aber eine Set-Eigenschaft hinzufügen, so kann dies für die Prüfung geändert werden. Die Biz Schicht verarbeitet nur Geschäftslogik, es nicht wissen oder egal, wo die Daten kamen und wohin es geht, es kümmert sich nur um die Daten zu manipulieren mit Geschäftsregeln zu erfüllen, würde dies Datum Validierung umfasst, Filterung (Teil davon ist, die DAL, welche Daten es braucht zu sagen, lassen sie die DAL herauszufinden, wie es zu bekommen). Grundsätzlich ist die BIZ behandelt alle Logik, die nicht UI verwandt ist oder Datenabruf bezogen. Genau wie die DAL das Biz sollte eine Schnittstelle aus dem gleichen Grunde implementieren.

Die UI-Ebene greift auf die Biz Schicht auf die gleiche Weise die Biz Schicht die DAL aus dem gleichen Grund zugreift. All die UI-Ebene kümmert sich um Daten anzeigt und Abrufen von Daten aus dem Benutzer. Die IU Schicht soll nichts über die Geschäftsregeln kennt, mit der möglichen Ausnahme von Datenvalidierung, die Dateneinheiten füllen erforderlich.

Der Vorteil dieser Architektur ist es Trennung von Sorge zwingt so dass es leichter zu testen, flexibler und leichter zu pflegen. Heute werden Sie bauen eine Website, aber morgen werden Sie wollen, damit andere vi einen Web-Service zu integrieren, alles, was Sie tun müssen, ist eine Web-Service erstellen, der die IBIZ Schnittstelle und Ihre implementiert getan, wenn Sie einen Fehler in der BIZ beheben Schicht, ist es bereits sowohl in Ihrer Website und Web-Service festgelegt.

Wenn man dies auf die nächste Ebene, können sagen, dass Sie eine Menge schwere Anzahl tun Knirschen und Sie müssen leistungsfähigeren Server zu handhaben, so alles, was Sie tun müssen, ist eine IDAI und IBIZ Schnittstelle zu implementieren, die wirklich zu WCF Wrapper, die die Kommunikation zwischen den Servern behandelt, jetzt Ihre Anwendung zwischen mehreren Server verteilt und Sie haben nicht den Code zu ändern, es zu tun.