warum ich durch die Trennung der Bereiche Datenbank/Geschäftsobjekte/Webdienst mehr Code schreiben muss?

Question

Ich habe viele Bücher über Softwaredesign gelesen, und ich frage mich immer mehr, ob das, was ich über die Trennung von Geschäftsobjekt und Serialisierung gelernt habe, mich produktiver macht.

Ich bin vom Domain Driven Design beeinflusst, daher denke ich bei der Entwicklung meiner Business-Klassen nicht an Persistenz. Die einzigen Objekte, die mit meiner Datenbank/Web-Service-Technologie/Caching-Technologie gekoppelt sind, sind hinter einem Repository mit einer schönen Domänenschnittstelle gekapselt.

Zur Veranschaulichung: Für eine herkömmliche Anwendung Datenbank<->Webdienst<->RIA entwerfe ich meine Geschäftsklassen Konto und Mitarbeiter. Wenn ich dann Konten aus einer Datenquelle abrufen möchte, erstelle ich ein IAccountRepository und implementiere Methoden zur Abfrage oder zum Hinzufügen von Konten zu meiner Datenquelle.

Um meiner Anwendung Caching-Fähigkeit hinzuzufügen, muss ich nur eine Proxy-Klasse erstellen, die IAccountRepository implementiert und das echte Repository umhüllt, und sie dann in meinen IOC-Container einfügen.

Um ein Datenbank-Repository zu implementieren, verwende ich ein ORM, das Klassen aus meinem Datenbankschema erstellt, dann verwende ich einen Übersetzer, um Datenbankklassen in/aus Geschäftsklassen umzuwandeln, auf diese Weise sind meine Geschäftsklassen von meinem Datenbankschema entkoppelt.

Ich erstelle auch dedizierte Datenvertragsklassen für meine Webdienste, und dann verwenden die Webdienste Übersetzer, um eine Aggregation von Geschäftsobjekten in ihre Datendarstellung aus der Webdienstperspektive zu transformieren.

Wenn ich meine RIA-Anwendung erstelle, entwerfe ich wieder ein eigenes Domänenmodell, aber dieses Mal verwendet die Repository-Implementierung einen Webservice anstelle der Datenbank (und wieder Übersetzer).

Für WPF-Entwickler erstelle ich dann mein ViewModel und meine View.

Früher habe ich so programmiert.

ABER, wenn mein Chef kommt und sagt: Können Sie diesem Formular ein Feld hinzufügen, um... blah blah blah Ich muss:

1. Meine Datenbank aktualisieren
2. Meine Datenbank aktualisieren Übersetzer
3. Mein Geschäftsobjekt aktualisieren
4. Aktualisieren Sie meinen Webdienst-Übersetzer (Server)
5. Meinen Webdienst-Übersetzer aktualisieren (Client)
6. Mein Geschäftsobjekt aktualisieren (Mandant)
7. Meine Ansicht aktualisieren
8. Für WPF-Kenner: Aktualisieren Sie mein ViewModel

Ich denke mehr und mehr darüber nach, mein Geschäftsobjekt mit Datenbankzugriffstechnologie und Webservice-Technologie oder Serialisierungstechnologie zu verbinden.

Auf diese Weise brauche ich meine Übersetzer nicht mehr zu pflegen. Warum zum Beispiel keine Attribute/Anmerkungen dieser Technologien für die Geschäftsobjekte verwenden? Ja, es bringt einige Einschränkungen mit sich, ja, ich brauche ein get/set für meine Felder, auch wenn ich möchte, dass meine Eigenschaft schreibgeschützt ist, ja, mein Geschäftsmodul wird externe Abhängigkeiten haben. Aber ich denke, es wird zu weniger Code und einem wartungsfreundlicheren System führen.

Die Implementierung meiner Repositories wird trivial sein und sich nicht auf Übersetzer stützen.

Obwohl ich die Vorteile dieser Vorgehensweise sehe, habe ich immer ein schlechtes Gewissen, wenn ich auf diese Weise kodiere. Ich fühle mich wirklich schuldig, wenn ich 5 Attribute/Anmerkungen in Verbindung mit meiner Datenzugriffstechnologie/Webdiensttechnologie/Serialisierungstechnologie zu meinen Geschäftsobjekten hinzufüge, und ich habe das Gefühl, dass es nicht richtig ist.

Warum führt die Trennung der Bereiche Datenbank/Geschäftsobjekte/Webdienst dazu, dass ich mehr Code schreibe?

Haben Sie einige Alternativen?

Answer 1

Ihre persönliche Produktivität ist nicht das Ziel.

Der Sinn der Trennung von Belangen ist es, die Wert der von Ihnen erstellten Software, indem Sie sie benutzbar, wartbar und anpassbar machen.

Es tut mir leid, wenn Sie dadurch mehr Code schreiben müssen, aber Ihre Zeit ist in der Regel nur ein winziger Bruchteil der Lebenszeitkosten für die Nutzung, Wartung und Anpassung dessen, was Sie schreiben.

Die Trennung der Bereiche dient im Wesentlichen dazu, die lebenslangen Gesamtbetriebskosten niedrig zu halten. Mit Ihrer persönlichen Produktivität hat sie wenig zu tun.

Wenn Ihr Chef Sie um eine tiefgreifende Veränderung bittet... nun ja... sie ist tiefgreifend. Es tut mir leid, dass es allgegenwärtig ist.

---

Bearbeiten 1

El Wert Ihrer Software ist der Wert, der von Menschen geschaffen wird mit es.

"Ist es die Reinheit/Schönheit des Codes? Für mich liegt der Wert in der Einfachheit und Lesbarkeit." Weder noch. Es ist der Wert, der durch die Anwendung des Codes auf reale Probleme entsteht.

Wenn der Code schwer zu pflegen, anzupassen oder zu verwenden ist, wird er dadurch entwertet. Wenn der Code leicht zu pflegen, anzupassen oder zu verwenden ist, dann gibt es weniger Hindernisse, um den vollen Wert des Codes zu nutzen.

Die Zeit, die Sie für die Entwicklung des Codes aufwenden, ist ein winziger Betrag im Vergleich zum Wert der Nutzung des Codes. Außerdem ist Ihre Entwicklungszeit ein geringerer Kostenfaktor als die Wartung oder Anpassung.

Bearbeiten 2

Allgegenwärtige Veränderungen sind eine unvermeidliche Folge der Softwareentwicklung. Nichts - kein Verfahren - kann Ihren Chef daran hindern, eine Änderung vorzunehmen, die Ihre Architektur zerstört.

Wenn Sie nur eine Ebene haben, wird diese bei fast jeder Änderung zerstört.

Wenn Sie 3 Ebenen, 7 Ebenen oder n+1 Ebenen haben, ist es immer möglich, dass Ihr Chef eine Änderung verlangt, die mehr als eine Ebene betrifft.

Die Idee ist, dass die meisten Änderungen isoliert sind. Nichts kann gewährleisten, dass ALLE Änderungen isoliert sind.

Answer 2

Bei der Entwicklung einer Anwendung sollten die Abstraktionsebenen einen Mehrwert bieten. Sie sollten nicht nur deshalb vorhanden sein, weil es sich um eine "Best Practice" handelt. Einige Anwendungen haben ein umfangreiches Domänenmodell und profitieren von den Abstraktionsebenen. Eine Anwendung, die sehr datenzentriert ist und nur wenig Logik enthält, braucht jedoch möglicherweise nicht so viele Ebenen.

Ich habe einige Anwendungen gesehen, die mehrere Ebenen für jedes Objekt definieren, wobei die Namen pflichtgemäß der Ebene EmployeeDL, EmployeeBL, EmployeeUL entsprechen. Keines der Objekte hatte einen Mehrwert, sondern es wurden lediglich Werte zwischen den Ebenen von der Benutzeroberfläche an die Datenbank weitergegeben. Das war sinnlos.

Bei der Arbeit mit Anwendungen mit einem umfangreicheren Domänenmodell kann es vorkommen, dass sich Änderungen auf mehrere Ebenen auswirken, aber selten so einfach sind wie die Weitergabe eines Wertes von der Benutzeroberfläche durch mehrere Ebenen an die Datenbank. In der Mitte befindet sich Geschäftslogik, die ohne die Abstraktionsebenen viel schwieriger zu implementieren wäre.

Letztendlich ist es wichtig, eine Architektur zu wählen, die den Anforderungen Ihrer Anwendung in Bezug auf Komplexität und Wartbarkeit entspricht.

Answer 3

Eine wartbare Anwendung ist eine Anwendung, die geringe Wartungskosten verursacht. Wenn häufige Änderungen viel Zeit in Anspruch nehmen, handelt es sich nicht um eine wartbare Anwendung.

Die wichtigste Frage, die man sich stellen muss, ist die nach der Häufigkeit von Funktionsanfragen im Vergleich zu technologischen Änderungen.

Wenn Sie Ihre bevorzugte Technologie alle 3 Monate oder so ändern, werden Sie nie Zeit haben, neue Funktionen zu implementieren, so dass Ihre Architektur optimal ist...

Answer 4

Ich habe dieselbe Erfahrung gemacht: Vieles von dem, was ich in der Schule über Abstraktion und Trennung von "Dingen" gelernt habe, macht meinen Code tatsächlich immer komplizierter.

Ich bin zu der Erkenntnis gelangt, dass man, wenn man einen hohen Zusammenhalt hat (die Klassen sind sehr klein und sehr auf den Punkt gebracht) wird haben eine hohe Kopplung. Indem jede einzelne Klasse immer weiter vereinfacht wird, wird jede Komponente für sich genommen immer nutzloser; um eine einfache Funktionalität zu erhalten, müssen Sie komplexe Interaktionen zwischen diesen einfachen "zusammenhängenden" Objekten verwalten.

Dann werden einfache Aufgaben kompliziert!! Denken Sie an das Lesen einer Datei in Java, ich weiß nicht mehr, wie man das macht (ich musste es schon oft machen), und ich will es nie wieder tun.

In Python ist es ganz einfach:

for line in open("filename"):
    # do something with line

Ich sage nicht, dass die Trennung von Belangen und Abstraktionen schlecht ist, nur sollte man sie vernünftig durchführen.

IMO ist es immer besser, etwas zu haben, das "einfach funktioniert", auch wenn es Spaghetti sind, da man tun überarbeiten.

Answer 5

Sie schreiben definitiv zu viel Code. Das Hinzufügen eines einzelnen Feldes sollte nicht in 8 Schritten erfolgen.

1. Warum nicht NHibernate verwenden? Sie können bis zu Ihrem echten Domänenmodell und der "Datenbank-Übersetzer" ist (jetzt) eine einfache Übung mit FluentNHibernate.

2. Es gibt einige sehr robuste Rahmenwerke für die Kombination der Schritte 4-6 auf relativ transparente Weise. WCF (der Horror!) zum Beispiel.