Architektur für eine Business-Objekte / Datenbankzugriffsschicht

StackOverflow https://stackoverflow.com/questions/118955

  •  02-07-2019
  •  | 
  •  

Frage

Aus verschiedenen Gründen schreiben wir eine neue Business-Objekte / Datenspeicherbibliothek. Eine der Anforderungen dieser Schicht ist die Logik der Geschäftsregeln zu trennen, und die Speicherschicht tatsächlichen Daten.

Es ist möglich, mehrere Datenspeicherschichten zu haben, die den Zugriff auf das gleiche Objekt implementieren - zum Beispiel eine Haupt „Datenbank“ Datenspeicherquelle, die meisten Objekte implementiert, und eine andere „ldap“ Quelle, die ein User-Objekt implementiert. In diesem Szenario können Benutzer optional aus einer LDAP-Quelle kommen, vielleicht mit etwas anderen Funktionen (zB nicht möglich, das Benutzerobjekt speichern / aktualisieren), aber ansonsten ist es durch die Anwendung der gleiche Art und Weise verwendet. Ein weiterer Datenspeichertyp könnte ein Web-Service oder eine externe Datenbank sein.

Es gibt zwei Möglichkeiten, wie wir dies bei der Umsetzung suchen, und ich und ein Mitarbeiter nicht einverstanden ist auf einer grundlegenden Ebene, die korrekt ist. Ich würde eine Beratung auf das man am besten zu verwenden. Ich werde versuchen, meine Beschreibungen der einzelnen so neutral wie möglich zu halten, da ich für einige objektive Sicht Punkte hier suchen.

  • Business-Objekte sind Basisklassen und Datenspeicherobjekte erben Business-Objekte. Client-Code befasst sich mit Datenspeicherobjekten.

    In diesem Fall gemeinsame Geschäftsregeln werden von den einzelnen Datenspeicherobjekt geerbt, und es ist die Datenspeicherobjekte, die vom Client-Code direkt verwendet werden.

    Dies hat die Implikation, dass Client-Code bestimmt, für ein bestimmtes Objekt, das Datenspeicherverfahrens zu verwenden, da es eine Instanz auf diese Art von Objekt ausdrücklich erklären muss. Client-Code muss explizit Verbindungsinformationen für jeden Datenspeichertyp weiß, dass es verwendet wird.

    Wenn eine Datenspeicherschicht unterschiedliche Funktionalität für ein bestimmtes Objekt implementiert, Client-Code kennt explizit darüber bei der Kompilierung, weil das Objekt anders aussieht. Wenn die Datenspeichermethode geändert wird, Client-Code aktualisiert werden muss.

  • Business-Objekte kapseln Datenspeicherobjekte.

    In diesem Fall werden Geschäftsobjekte direkt von Client-Anwendung verwendet. Client-Anwendung läuft entlang Basisverbindungsinformationen zu Business-Schicht. Entscheidung darüber, welche Datenspeicherverfahren ein bestimmtes Objekt verwendet von Business-Objekt-Code gemacht wird. Verbindungsinformationen wären ein Teil der Daten aus einer Konfigurationsdatei (Client-Anwendung über Details davon nicht wirklich wissen / Pflege) genommen werden, die eine einzelne Verbindungszeichenfolge für eine Datenbank sein kann, oder mehrere Stücke Verbindungszeichenfolgen für verschiedene Datenspeichertypen. Zusätzliche Datenspeicherverbindungstypen könnten auch von einer anderen Stelle gelesen werden - zB eine Konfigurationstabelle in einer Datenbank, die URLs zu verschiedenen Web-Services gibt.

    Der Vorteil hierbei ist, dass, wenn ein neues Datenspeicherverfahren zu einem bestehenden Objekt hinzugefügt wird, kann eine Konfigurationseinstellung zur Laufzeit festgelegt werden, um zu bestimmen, welche Methode zu verwenden, und es ist völlig transparent für die Client-Anwendungen. Client-Anwendungen müssen nicht, ob Datenspeicherverfahren für ein bestimmtes Objekt Änderungen modifiziert werden.

  • Business-Objekte sind Basisklassen, Datenquellenobjekte von Business-Objekten erben. Client-Code befasst sich in erster Linie mit Basisklassen.

    Dies ist ähnlich dem ersten Verfahren, aber Client-Code deklariert Variablen der Basis Business-Objekttypen und Load () / Create () / etc statische Methoden auf den Business-Objekten die entsprechenden Datenquelle typisierte Objekte zurück.

    Die Architektur dieser Lösung ist ähnlich das erste Verfahren, aber der Hauptunterschied ist die Entscheidung über Objekt, das die Datenspeicherung für ein bestimmtes Business-Objekt zu verwenden, wird von der Business-Schicht, soweit sie nicht der Client-Code.

Ich weiß, es ist bereits bestehende ORM-Bibliotheken, die einen Teil dieser Funktionalität bieten, aber bitte die für jetzt (es besteht die Möglichkeit, dass eine Datenspeicherschicht mit einem dieser ORM-Bibliotheken implementiert) diskontieren - auch zur Kenntnis, ich bin bewusst sagen Sie nicht, welche Sprache uns zu seined hier, außer, dass es stark typisiert wird.

Ich interessiere mich für einige allgemeine Ratschläge hier, welche Methode besser zu nutzen (oder fühlen sich frei, etwas anderes vorzuschlagen), und warum.

War es hilfreich?

Lösung

könnte darauf hindeuten, ich eine andere Alternative, mit der Sie möglicherweise besseren Entkopplung: Business-Objekte Verwendung Datenobjekte und Datenobjekte implementieren Speicherobjekte. Dies sollte die Geschäftsregeln in die Business-Objekte halten, aber ohne Abhängigkeit von der Speicherquelle oder Format, während die Datenobjekte erlaubt, was Manipulationen zu unterstützen erforderlich sind, einschließlich der Speicherobjekte dynamisch (zB für Online- / Offline-Manipulation) zu ändern

Dies fällt in die zweite Kategorie oben (Business-Objekte Datenspeicherobjekte kapseln), sondern trennt Datensemantik von Speichermechanismen deutlicher

Andere Tipps

Sie können auch eine Fassade müssen von Ihrem Client zu halten direkt um das Geschäft zu nennen. Auch schafft es gemeinsame Einstiegspunkte für Ihr Unternehmen.

Wie gesagt, Ihr Unternehmen nicht auf alles andere als Ihre DTO und Fassade ausgesetzt werden sollte.

Ja. Ihr Kunde kann mit DTOs beschäftigen. Es ist der ideale Weg, um Daten durch Ihre Anwendung zu übergeben.

Ich ziehe es im Allgemeinen die beste „Business-Objektdaten Objekt / Speicher kapselt“. Doch in der kurzen können Sie hohe Redundanz mit Ihren Datenobjekten und Ihre Business-Objekte finden, die nicht sinnvoll erscheinen mag. Dies gilt insbesondere, wenn Sie für eine ORM als Grundlage Ihrer Daten-Access-Layer (DAL) entscheiden. Aber auf lange Sicht ist, wo die wirklichen auszuzahlen: Applikations-Lebenszyklus. Wie dargestellt ist, ist es nicht ungewöhnlich, „Daten“, die von einem oder mehreren Speichersubsystemen kommen (nicht beschränkt RDBMS), insbesondere mit dem Aufkommen von Cloud Computing, und wie es üblicherweise der Fall ist in verteilten Systemen. Zum Beispiel können Sie einige Daten, die von einem RDBMS, eine andere aus einer XML-Datei, LDAP, und so weiter von einem Restful Service, einem anderen Brocken oder Objekt kommt. Mit dieser Erkenntnis impliziert dies die Bedeutung der sehr guter Kapselung des Datenzugriff aus dem Geschäft. Achten Sie darauf, welche Abhängigkeiten Sie belichten (DI) durch Ihre c-toren und Eigenschaften auch.

Das sei gesagt, ein Ansatz, den ich liebäugelt habe mit ist das „Fleisch“ der Architektur in einem Business-Controller zu setzen. Das Denken der zeitgenössischen Datenzugriff mehr als eine Ressource als herkömmliche Denken, übernimmt die Steuerung dann in einer URI oder eine andere Form von Metadaten, die verwendet werden können, zu wissen, welche Datenressourcen für die Business-Objekte verwalten muss. Führen Sie dann die Business-Objekte selbst nicht den Datenzugriff kapseln; vielmehr der Controller funktioniert. Das hält Ihre Business-Objekte leicht und spezifisch und ermöglicht es dem Controller Optimierung zu bieten, composability, Transaktions Ambiente, und so weiter. Beachten Sie, dass Ihr Controller würde dann „Host“ Ihr Unternehmen Objektsammlungen, ähnlich wie der Controller Stück vieler ORMs tun.

Darüber hinaus auch Business Rule Management berücksichtigen. Wenn Sie hart an Ihrem UML (oder das Modell im Kopf, wie ich: D) schielen, werden Sie feststellen, dass Ihre Geschäftsregeln Modelle sind eigentlich ein anderes Modell, manchmal sogar persistent (wenn Sie eine Business Rules Engine verwenden, zum Beispiel) . Ich würde nach Ansicht der Business-Controller lassen auch tatsächlich zu Ihren Regeln Subsystem steuern, und lassen Sie Ihr Business-Objekt die Regeln über den Controller verweisen. Der Grund ist, weil zwangsläufig Regel Implementierungen müssen oft Lookups durchführen und Gegenprüfung, um Gültigkeit zu bestimmen. Oft kann es sowohl hydratisierte als Business-Objekt-Lookups erfordert, sowie Back-End-Datenbankabfragen. Betrachten Erkennung doppelte Einheiten, zum Beispiel, wo nur die „neue“ ein hydratisiert wird. Verlassen Sie Ihre Regeln durch Ihr Unternehmen Controller verwaltet werden, können Sie fast alles tun, müssen Sie ohne Ihr dass schöne saubere Abstraktion zu opfern „Domain-Modell.“

In Pseudo-Code: 

using(MyConcreteBusinessContext ctx = new MyConcreteBusinessContext("datares://model1?DataSource=myserver;Catalog=mydatabase;Trusted_Connection=True ruleres://someruleresource?type=StaticRules&handler=My.Org.Business.Model.RuleManager")) {

User user = ctx.GetUserById("SZE543");
user.IsLogonActive = false;
ctx.Save();
}

//a business object
class User : BusinessBase {
  public User(BusinessContext ctx) : base(ctx) {}

  public bool Validate() {
    IValidator v = ctx.GetValidator(this);
    return v.Validate();
  }
}

// a validator
class UserValidator : BaseValidator, IValidator {
 User userInstance;
 public UserValidator(User user) {
  userInstance = user;
 }

 public bool Validate() {
   // actual validation code here
   return true;
 }
}

Die Kunden sollten nie direkt mit Speicherobjekten beschäftigen. Sie können mit DTO befassen sich direkt, aber jedes Objekt, das jede Logik für die Lagerung hat, die nicht in Ihrem Business-Objekt gewickelt wird, soll nicht durch den Client auch direkt aufgerufen werden.

Überprüfen Sie heraus CSLA.net von Rocky Lhotka.

Nun, hier bin ich, die Mitarbeiter Greg erwähnt.

Greg beschrieb die Alternativen, die wir mit großer Genauigkeit in Erwägung gezogen haben. Ich möchte nur einige zusätzliche Überlegungen zur Situation Beschreibung hinzuzufügen.

Client-Code kann über Datenspeicherung nicht bewusst, wo Business-Objekte gespeichert sind, aber es ist möglich, entweder im Fall, wenn es nur eine Datenspeicherung ist, oder es gibt mehrere datastorages für den gleichen Business-Objekttyp (Benutzer in der lokalen Datenbank gespeichert und in externen LDAP), aber der Kunde nicht schaffen, diese Geschäftsobjekte. Im Hinblick auf die Systemanalyse, bedeutet dies, dass es keine Anwendungsfälle geben, in denen Existenz von zwei datastorages von Objekten des gleichen Typs Use-Case-Flow beeinflussen können.

Sobald die Notwendigkeit, bei der Unterscheidung zwischen Objekten in verschiedenen Daten erstellt Speicher entstehen, muss der Client-Komponente über Vielzahl von Datenspeichern in seinem Universum bewusst geworden, und es wird unweigerlich die Verantwortung für die Entscheidung, welche Datenspeicher werden auf den Moment zu nutzen die Objekterstellung (und, wie ich denke, Objekt Laden von einem Datenspeicher). Business-Schicht kann so tun, als es ist, diese Entscheidungen zu treffen, aber der Algorithmus der Entscheidungsfindung auf Art und Inhalt der Informationen basieren von der Komponente-Client kommen, so dass der Kunde direkt verantwortlich für die Entscheidung.

Diese Verantwortung kann auf vielfältige Weise umgesetzt werden: Es ist ein Verbindungsobjekt von bestimmtem Typ für jeden Datenspeicher sein kann; es kann neue BO-Instanzen segregared Methoden werden nennen usw. erstellen

Grüße,

Michael

CLSA hat schon eine lange Zeit gewesen. Allerdings Ich mag den Ansatz, der in Eric Evans Buch diskutiert http://dddcommunity.org/

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top