Entwicklungsansatz: User Interface In oder Domain Model Out?

Obwohl ich mit Smalltalk noch nie etwas geliefert habe, hat meine kurze Spielzeit definitiv Spuren hinterlassen. Die einzige Möglichkeit, die Erfahrung zu beschreiben, ist MVC, wie es sein sollte. Im Wesentlichen erfolgt das Heben von Lasten für Ihre Anwendung in den Geschäftsobjekten (oder im Domänenmodell, wenn Sie dazu geneigt sind). Die Standardsteuerelemente sind in irgendeiner Weise an die Geschäftsobjekte gebunden. Beispielsweise wird ein Textfeld dem Feld eines Objekts zugeordnet (das Feld selbst ist ein Objekt, so dass dies einfach ist). Eine Schaltfläche würde einer Methode zugeordnet. Dies geschieht alles mit einer sehr einfachen und natürlichen API. Wir müssen nicht über das Binden von Objekten usw. nachdenken. Es funktioniert einfach.

In vielen neueren Sprachen und APIs sind Sie jedoch gezwungen, von außen nach innen zu denken. Zuerst mit C ++ und MFC und jetzt mit C # und WPF hat Microsoft seine Entwicklerwelt an GUI-Builder gebunden, in denen Sie Ihre Anwendung durch die Implementierung von Ereignishandlern erstellen . Java Swing-Entwicklung ist nicht so unterschiedlich, nur Sie schreiben den Code, um die Steuerelemente auf dem Formular selbst zu instanziieren. Für einige Projekte gibt es möglicherweise nicht einmal ein Domain-Modell - nur Event-Handler. Ich habe in und um dieses Modell für die meisten meiner Karriere gewesen.

Jeder Weg zwingt dich, anders zu denken. Mit dem Smalltalk-Ansatz ist Ihre Domain intelligent, während Ihre GUI dumm ist. Bei der Standardmethode von VisualStudio ist Ihre GUI intelligent, während Ihr Domänenmodell (sofern vorhanden) eher anämisch ist.

Viele Entwickler, mit denen ich arbeite, sehen Wert im Smalltalk-Ansatz und versuchen, diesen Ansatz in die VisualStudio-Umgebung zu integrieren. WPF verfügt über einige dynamische Bindungsfunktionen, die dies ermöglichen. aber es gibt Einschränkungen. Zwangsläufig gelangt Code, der zum Domänenmodell gehört, in die GUI-Klassen.

Wie entwerfen / entwickeln Sie Ihren Code? Warum?

• GUI zuerst. Benutzerinteraktion ist von größter Bedeutung.
• Domain zuerst. Ich muss sicherstellen, dass das System korrekt ist, bevor wir eine Benutzeroberfläche darauf setzen.

Für beide Ansätze gibt es Vor- und Nachteile. Das Domain-Modell passt dort mit Kristallkathedralen und Pie in the Sky hinein. GUI passt da schnell rein und versaut (manchmal richtig versaut).

Und für einen zusätzlichen Bonus: Wie stellen Sie sicher, dass der Code wartbar ist?

Weder

Im Laufe der Jahre, in denen ich Software entwickelt habe, musste ich zunächst beide Methoden anwenden, da es immer einen "Mittelweg" gibt, der berücksichtigt werden muss. Stellen Sie eine Schnittstelle zwischen dem Benutzeroberflächencode und dem Geschäftscode her und vereinbaren Sie, was die Benutzeroberfläche im Moment von der Domäne benötigt.

Lassen Sie mich eine Zahl machen, um dieses Konzept kristallklar zu machen:

  +------+
  |  UI  | <- Think about how to make an effective user interface
  +------+
      |
      |
 +----------+
 | Contract | <--- This part over here is really REALLY important, man!
 +----------+
      |
      |
+--------------+
| Domain model | <- Think about what the user needs
+--------------+ 

Auf diese Weise können Sie die Benutzeroberfläche und das Domänenmodell iterativ separat bearbeiten, wenn der Mittelweg klar macht, welche Daten die Benutzeroberfläche empfangen kann.

Der Grund, warum ich sehe, warum einige Projekte nicht mehr verwaltet werden können, ist, dass die Schnittstelle zwischen Daten und Präsentation überstürzt wurde oder nicht vorhanden ist (mit direktem Datenhandhabungscode in der Benutzeroberfläche). Ich habe so viele Projekte gesehen, in denen sich Datenbankcode im Formularcode befand, dass ich das Vertrauen in die Menschheit verloren habe. Nur die wenigen Projekte, die ich gesehen habe, haben diesen starren Mittelweg, um diesen verlorenen Glauben wiederherzustellen.

Es ist eigentlich egal, von welchem Ende aus Sie zuerst beginnen ... was zählt, ist, dass Sie eine klare Trennung der Bedenken haben. Dieser Vertrag in der Mitte definiert so ziemlich die Anwendung oder das System. Denken Sie zuerst daran, bevor Sie von unten nach oben oder von oben nach unten gehen .

Domain zuerst. Ich muss sicherstellen, dass das System korrekt ist, bevor wir eine Benutzeroberfläche darauf setzen.

Nichts anderes kann zum Laufen gebracht werden - außer in einfachen Fällen.

Das Starten über die Benutzeroberfläche führt häufig zu fragiler, fehlerhafter Software, die zwar Spaß macht, jedoch häufig schwerwiegende Probleme im Modell aufweist.

Es ist nicht selbstverständlich, dass die Benutzeroberfläche zum Scheitern verurteilt ist. Wenn das Modell einfach genug ist, kann die Benutzeroberfläche zuerst mit der Gewissheit erstellt werden, dass das Modell am Ende einwandfrei funktioniert.

In jedem Fall, in dem das Modell nicht leicht vorstellbar ist, muss es zuerst erstellt werden.

Der schlimmste Fall ist, wenn ein Programmierer glaubt, sich das Modell vorstellen zu können. Sie haben möglicherweise wichtige Details, Sonderfälle, Ausnahmen oder Leistungsüberlegungen ausgelassen. Da die GUI bereits erstellt wurde und viele Überlegungen weggelassen wurden, ist das Modell fürchterlich.

Dies hängt wirklich von der jeweiligen Anwendung ab.

Wenn Sie eine geschlossene Client / Server-Anwendung erstellen, ist eine der beiden Methoden ausreichend. Wenn Sie das Back-End so manipulieren, dass es den Front-End-Anforderungen entspricht, ist dies unumgänglich.

Wenn Sie eine offene Client / Server-Anwendung erstellen, in der ein potenzieller Webdienst zur Verwendung durch Ihre Kunden verfügbar gemacht wird, ist es wichtig, zu wissen, wie dieser Dienst von einem Kunden zum Entwickeln eines Frontends verwendet werden kann.

Häufig werden in letzter Zeit im Hinblick auf einen Schub kleiner iterativer Entwicklungszyklen (Scrum, Kanban usw.) das Front-End und das Back-End parallel ausgeführt. Es geht darum, das bereitzustellen, was Sie für diese gegebene Iteration benötigen. Ignorieren Sie den Build, falls Sie ihn benötigen . In einem parallelen Ansatz bleiben beide Enden während der gesamten Entwicklung viel enger beieinander, was die Notwendigkeit einer kontinuierlichen Änderung verringern kann, wenn das vordere Ende und das hintere Ende verschmelzen. Dies ist mein bevorzugter Ansatz, wenn dies machbar ist.

Du erwähntest...

... WPF verfügt über einige dynamische Bindungsfunktionen, die dies ermöglichen. aber es gibt Einschränkungen. Zwangsläufig gelangt Code, der zum Domain-Modell gehört, in die GUI-Klassen ...

Nicht sicher, was Sie mit einigen meinen ? WPF und SL sind beide für ihre Bindungsfunktionalität bekannt. Es ist unendlich. Wenn Sie gezwungen sind, Code in Ihre Ansicht in einer MVVM-basierten WPF-Anwendung einzufügen, muss etwas behoben werden. Angehängte Verhaltensweisen sind eine Möglichkeit, Verhaltensweisen zu implementieren, ohne an Ereignisse in der Ansicht gebunden zu sein, sowie viele andere Methoden, um sicherzustellen, dass Ihre Ansicht sauber bleibt.

Das Front-End einer Benutzerinteraktionshaltung sollte nichts mit der Back-End-Implementierung zu tun haben . Die einzige Aufgabe des Backends an ein Frontend besteht darin, Daten über Verarbeitungsdaten oder andere Mittel bereitzustellen. Dies knüpft an die Art der zu entwickelnden Anwendung an.

Es ist eine ganz andere Frage an sich, sicherzustellen, dass der Quellcode wartbar ist. Auf hohem Niveau handelt es sich um bewährte Codierungsmethoden sowie um bewährte Muster, Architekturen und Technologien.

Ich ziehe es vor, zuerst die grundlegende Benutzeroberfläche zu entwerfen (auch wenn es sich nur um eine Papieroberfläche handelt), und zwar unter Mithilfe des Kunden. Der Kunde weiß vielleicht erst, was er will, wenn er es sieht. Sie können nicht immer vertrauen, was der Kunde Ihnen sagt. Sie könnten Wochen damit verbringen, ein robustes Domain-Modell zu schreiben, nur um herauszufinden, dass es nicht in das passt, was der Kunde erwartet, nachdem er anfängt, UI-Prototypen zu sehen.

Wir versuchen, unsere Software mit automatisierten Tests zu betreiben. Automatisierte UI-Tests sind verdammt zeitaufwändig. Skripte zum Überprüfen einiger Werte auf einer Konsole sind einfacher.

Aus diesem Grund achten wir sehr darauf, die Geschäftslogik von der Benutzeroberfläche zu trennen.

Ich erinnere mich, dass mich einmal sogar ein leitender Entwickler angeschrien hat, dass die Document / View-Architektur als veraltet galt, als ich vorschlug, wir müssten unseren gesamten Geschäftscode nicht mehr mit der Benutzeroberfläche verknüpfen (und wir verwendeten zu dieser Zeit win32 in C ++, also diese Drag & Drop-Programmierung das war noch nicht mal unser problem). Ich war einfach verblüfft.

IMNSHO, es gibt einfach keine Entschuldigung dafür, dass es nicht mindestens eine Ebene für Business vs. UI gibt. Wenn Ihr Produkt etwas leicht Interessantes tut, ist es unbedingt erforderlich, dass diese Trennung die Wiederverwendung von Code ermöglicht.

Als C # -Entwickler glaube ich definitiv nicht, dass Sie dazu verpflichtet sind, von außen nach innen zu arbeiten. Eigentlich bevorzuge ich das Domain-Modell.

Für WPF ist der einzige Nachteil des von mir beschriebenen Modells, dass Sie manchmal zwischen Ihrer Benutzeroberfläche und Ihrem Domain-Modell vermitteln müssen. Das bedeutet zwar manchmal mehr Arbeit, aber auch saubereren Code.

Sicher, Domain zuerst!

Das Schöne an Smalltalk war, dass Sie ein Domain-Modell auf vielfältige Weise "fahren" konnten, einschließlich "Drucken" von einem Arbeitsbereich oder Inspektor aus. Nur wenn Sie sicher waren, dass Ihre Domain die gewünschte Leistung erbringt, haben Sie es gewagt, sich auf die Erstellung der perfekten GUI zu konzentrieren.

Das soll nicht heißen, dass Smalltalker nicht gleichzeitig mit beiden gearbeitet haben. Wenn Ihre GUI die Geschäftslogik jedoch nicht implementieren konnte, haben Sie im Allgemeinen zuerst das Domänenmodell repariert, anstatt Sonderfälle in Ihre GUI einzufügen.