Wie eine Datenschicht und Geschäftsobjektschicht zu spalten, was sind die entsprechenden Aufgaben der einzelnen?

Question

Wenn eine Reihe von Business-Anwendung gibt wie diese überlagert, wäre dies eine angemessene Arbeitsteilung sein:

Data Access

• Invokes nur Stored Procedures, Karten Eigenschaften von DTO s auf einen Hash tablse, die verwendet werden, um ADO.NET Befehl Parameter Sammlungen zu füllen.

• Nur Montag mit Bezug auf SqlDataClient.

• Signifikante Logik zu tun, was bedeutet, leer, null, und leer in dem Mapping-Code, aber andere wiesen keine Validierung oder andere domänenspezifische Logik.

So genannte Business Logic

• spaltet mehrere Ergebnismengen in einzelne DataTables- z.B.

  public void ReturnNthRecordSetFromStoredProcFoo ()

• gibt für Datensätze zu dem Datenzugriff durch, z.

  public void ReturnDataSet (string name) {            Rückkehr (neu PersonController) .GetAnotherDataSet (Name);}

• Karten eine Zeile eines Datatable zu einem DTO s

• Signifikante Logik zu tun mit dem, was bedeutet, leer, null, und leer in dem Mapping-Code.
• Hält Transaktionsobjekt, obwohl es ausschließlich verwendet wird, einzelne gespeicherte Prozeduraufrufe zu wickeln.
• verfügt nicht über einen Verweis auf SqlDataClient, so kann es nicht SqlDataReaders verwenden, um DTOs zu füllen
• Kein Hinweis auf System.Web.UI
• Berechtigungsregeln, aber ansonsten keine domänenspezifische Logik.

UI

• 2-Wege-Datenbindung von DTOs zu ASP.NET-Formularen.
• Validierung von Eigenschaften von Controls- im Allgemeinen keine Validierung direkt gegen DTOs
• „Sammlungen“ werden durch die Bindung Datasets Gitter navigiert. In der Tat versucht, etwas mit einer Sammlung zu tun, erfordert die Benutzeroberfläche über DataRows in Tables iterieren und wissen, was die entsprechenden Spaltennamen sind (die in der Regel nur Art-of-ähnlich den DTOs)

So ist die Frage, mit dieser Anwendung finally--, sollte die Datenzugriffsschicht, die die Aufgaben der sogenannten Business-Schicht übernimmt zusammengeführt werden? Ist das nicht bereits eine zweischichtige, ( fast!) Anwendung der Ausnahme für die Unannehmlichkeiten einer zusätzlichen Montage?

Weitere Informationen: Ok, ich weiß schon, dass der Anwendungsserver eine Maschine sein wird, wahrscheinlich für immer, da es sich um eine Low-User-count Intranet app ist. Ich weiß also nicht für physikalisch getrennte Anwendungsebene zu entwerfen. Auch wird es wahrscheinlich nur eine UI unterstützen und vollständig verschrottet werden, wenn sie jemals etwas anderes als ASP.NET-- unterstützen müssen eine weitere oft zitierte Grund für Ebenen / Schichten.

Answer 1

Es klingt für mich, dass die Verantwortung zwischen den Ebenen ein wenig verworren ist. Die Datenschicht klingt ziemlich Standard. Die ( „so genannte“) Business-Schicht ist der Ort, wo die Dinge durcheinander bringen.

Einige Gedanken über die Business Layer:

• Es scheint eine Menge von Datendarstellungen zu sein. Sie erwähnen DataTables- Datasets, Datenübertragung Objekte. Ein Standardansatz über die gesamte Anwendung wäre besser.

• Handelsschichtverfahren mit Namen wie ReturnNthRecordSetFromStoredProcFoo und ReturnDataSet sind nicht sinnvoll und bieten keine angemessene Abstraktionsebene für Business-Services. (Vielleicht nur schlecht ausgewählte Beispiele die waren nicht von der Anwendung?)

• Typischerweise wird eine Business-Schicht würde mehr bieten als ein Datensatz durchlaufen. Statt mit Abbildungen von Umgang, nulls usw. die Business-Schicht auf Validierung, Geschäftsregeln konzentrieren soll, Sicherheit und vielleicht sogar Auditierung (obwohl einige zu tun es vorziehen, dass in der Datenbank).

• Auch wenn die Business-Schicht nur eine einzige gespeicherte Prozedur aufgerufen wird, ich habe kein Problem mit der Transaktionssteuerung in der Business-Schicht. Business-Schicht sollte die Transaktion steuern, so dass mehrere Datenobjekte alle in derselben Transaktion teilnehmen können (es sogar über verschiedene Datenbanken sein könnte). Auch wenn es jetzt nur noch ein Anruf, wenn Sie jemals werden diese müssen mehr Anrufe in der Zukunft hinzuzufügen einfach und führen nicht Transaktionssteuerung in Ihre Anwendung bei der Nachrüstung.

• Ich denke, die Abhängigkeiten in Ordnung sind -. Kein Hinweis auf das Web.UI oder SQLClient aus der Business-Schicht

• Berechtigungsregeln sind auch OK. Ich würde erweitern Sicherheit einzubeziehen und nicht nur Autorisierung. Auch ich sehe keine Business-Logik überall - nur neugierig, ob die Geschäftslogik in den gespeicherten Prozeduren ist? Wenn ich raten würde, würde ich sagen, ja gegeben, dass jeder Business-Methode nur eine gespeicherte Prozedur aufruft. Wenn ja, dann ist das ein großer nein nein für mich.

Ich würde nicht die Geschäfts- und Datenschichten kombinieren. Ich ziehe die Business-Logik-Schicht und die Datenzugriffsschicht getrennt zu halten. Wenn Sie die Wahl zwischen ihnen kombiniert und zu versuchen, die Aufgaben zu trennen, ein wenig mehr ich in Richtung der letzteren anlehnen würde.

Allerdings sehen, als ob es mich um eine bestehende Anwendung mit Fragen würde ich eine pragmatische Sicht. Alles ist zwar mit Kosten und es ist wichtig, um zu bestimmen, welche Änderungen vorgenommen werden, was den Aufwand und das Risiko der Veränderungen, was die real Nutzen der Veränderungen, und wie sich die Änderungen auswirken auf der Testzyklus.

Einige andere Fragen zu denken sind: Was sind die wichtigsten Punkte, die Sie ansprechen wollen? Sind sie funktional (z Fehler, mangelnde Stabilität)? Oder Leistung zu tun? Oder ist es Architektur? Oder vielleicht auf Wartbarkeit in Verbindung stehend - benötigen Sie neue Funktionen hinzufügen, aber finden es schwierig? Haben Sie einen Zeitrahmen oder ein Budget? Wenn Sie einige dieser Fragen beantworten könnte es helfen, Sie führen.

Answer 2

auf der Serverlast Je sollte die Anzahl der physikalischen Schichten bestimmen. Die Anzahl der logischen Schichten ist wirklich eher eine persönliche Wahl.

In unserer Organisation verwenden wir die CSLA Rahmen . Es ist ein Business-Objekt-Framework, das reich, Databound-UIs einfach zu bedienen und zu warten, während geben Flexibilität in der Datenschicht zu machen strebt.

Ich werde nicht in zu viel Tiefe hier, wie es wäre besser für Sie selbst zu bestimmen, ob der Rahmen ist es wert für Sie zu nutzen, aber es ist unnötig zu sagen, es hat seine eigene SafeDataReader Klasse, die für nulls Konten, die Beseitigung die Notwendigkeit, Datensätze zu verwenden.

Die " dataportal " (Artikel ist älter, aber noch relevant) können Sie bequem den Datenzugriff auf eine eigenen Ebene mit sehr wenig Aufwand bewegen, und keine Änderung des Codes.

DNRtv hat ein paar Video-pod, in denen wirft der Designer von CSLA, Rockford Lhotka, zeigt die Funktionsweise die Beispielanwendung. Teil 1 und Teil 2 .

Die Shows sind nur eine Stunde jeden und wahrscheinlich können Sie entscheiden, ob es das Richtige für Sie zu nutzen.

Answer 3

würde ich erwarten, zu sehen, was Sie als Ihre Business-Schicht als Datenschicht Art Material beschreiben. Ich würde hoffen, dass meine Datenschicht mich schützen würde mit etwa nulls und solche Dinge zu kümmern. Ich würde auch hoffen, dass meine Business-Schicht von Geschäftsregeln und Konzepte enthalten würde, die mehr abstrakt sind. Zum Beispiel, wenn eine „Gruppe“ ist eine Sammlung von „User“ s würde Ich mag Business-Typ-Funktionen, um zu sehen, diese Benutzer als Teil einer Gruppe auf einem hohen Niveau zu manipulieren. Zum Beispiel vielleicht eine Funktion, die Berechtigungen für alle Mitglieder dieser Gruppe zuordnen würde oder die UI-Ebene erlauben Richtlinien für diese Benutzer als Mitglieder einer Gruppe zu übernehmen. Ich würde hoffen, dass keine Funktionen, um zu sehen, die versuchen, die Tatsache zu verbergen, dass sie alle aus einer Datenbank kamen. Ich hoffe, dass dies hilfreich ist.