Brauchen Sie Rat bezüglich layered Lösung, die Trennung von Bedenken, etc

Question

Wir haben eine mehrschichtige Anwendung, oder zumindest in den Prozess der übergang zu einem, wie folgt aufgeschlüsselt:

• Benutzeroberfläche (user-interface-oder application-Schnittstelle, dh.webservice, etc.)
• Business-Logik
• Data access

Machen Sie den rest dieser Frage zu konkretisieren, werde ich beschreiben eine spezifische Instanz.

Wir haben eine Benutzeroberfläche, die eine controller-Objekt dahinter (die business-Logik-Schicht).Dieser controller Gespräche mit der Datenbank über ein anderes Objekt (data access layer).

In einem gegebenen Kontext, die Benutzeroberfläche erlaubt es dem Benutzer wählen Sie einen Mitarbeiter zu binden, die Bedienung angetan.Da gibt es Regeln für die Mitarbeiter der Nutzer (naja, Welt außerhalb des Controllers wirklich) aufnehmen kann, bietet der controller zwei Dinge dafür:

• eine lesbare Eigenschaft, die eine Liste der verfügbaren Mitarbeiter zu wählen aus
• Lesen/beschreibbare Eigenschaft, die den aktuell gewählten Mitarbeiter

Die Benutzeroberfläche könnte Lesen Sie die Liste und verwenden Sie es zum Auffüllen einer combobox.

In der version 1 der Anwendung, die combobox enthält die id-Nummer des Mitarbeiters, + den Namen des Mitarbeiters.

Alles ist gut...

...bis zu version 1.1, ein bugfix.Ein Benutzer beschwert sich, dass er nicht wählen können zwischen Jimmy Olson und Jimmy Olson da die Anwendung macht es nicht einfach, genug für ihn, zu wissen, welche welche ist.Er weiß, es ist ein Jimmy in die Verkäufe Abteilung, und eine andere, in der Entwicklung, so dass das Update für diese version 1.1 ist einfach tack auf einem Schrägstrich + die Abteilung-Namen in der combobox.In version 2 würde sich für den Austausch des combobox-eine combobox, hat Spalte Unterstützung, entfernen Sie den Schrägstrich, aber in 1.1, das ist, was gewählt wird, um zu minimieren das Risiko von weiteren bugs.

In anderen Worten, die combobox enthält:

• 1 - Jimmy Olson/Vertrieb
• 2 - Jimmy Olson/Entwicklung
• • andere Menschen

Aber der code für die Benutzeroberfläche hat keine SQL-code, oder eine Möglichkeit zu halten, die Abteilung, und so haben wir zu gehen, um die Steuerung und Blick auf den code dort.Der controller muss nicht die Abteilung, und um ehrlich zu sein, es braucht nicht einmal den Namen des Mitarbeiters, die id-Nummer ist genug, so gibt es nichts in die controller, fragt nach oder tut etwas, um die Abteilung.So haben wir zu gehen, um die data-access-layer und ändern Sie die SQL gibt.

Diese Lösung ganz ehrlich riecht.

Wenn es mehrere Schnittstellen für diese controller, mit verschiedenen Anforderungen, wir haben drei mögliche Lösungen:

1. Ändern der data access layer zu bieten für die (zunehmende/diverse) muss von mehreren Schnittstellen (2-Schichten) entfernt, was bedeutet, dass alle Schnittstellen werden möglicherweise alle Daten, die Sie benötigen, aber Sie würde auch erhalten Sie alle erforderlichen Daten für die anderen Schnittstellen
2. Fügen Sie so etwas, mit der die Benutzeroberfläche sagen, der data access layer (noch 2 Schichten) entfernt, was es braucht
3. Irgendwie machen die Benutzer interface layer die Daten ohne änderung entweder der controller oder access-layer-beteiligten, das klingt wie, wir brauchen mehr Daten-Zugriff-code, irgendwo.

Keine der oben genannten Lösungen gut fühlen.

Was ich Frage ist, sind wir völlig vom Kurs?Wie würden Sie dies tun?Gibt es eine vierte und fünfte Lösung unterhalb der 3 oben?

Pro diese Frage: Trennung von Bedenken, die akzeptierte Antwort enthält dieses Zitat:

Die Trennung von Bedenken ist, halten Sie den code für jedes dieser Probleme trennen.Änderung der Schnittstelle sollte nicht erfordern ändern der code für die Geschäftslogik, und Umgekehrt.

Tut dies einfach bedeuten, dass alle controller/data-access-Schicht sollte bieten uns mit dem ist, was es braucht, um seine Aufgabe (dh.die Ermittlung der Mitarbeiteranzahl), und dann die Benutzeroberfläche sollte gehen, sprechen, um die Datenbank und Fragen Sie für mehr Informationen diese bestimmte Mitarbeiter?

Answer 1

Die Art, wie ich es sehe, haben Sie zwei Möglichkeiten:

1. Die unteren Schichten nach oben zu schicken alle die Informationen, die Sie über einen person, möglicherweise als ein XML-Dokument, obwohl viele Verbraucher der diese Informationen brauchen Sie nicht alle.
2. Stellen APIs für die höheren Schichten zu bohren unten und Holen Sie sich die Informationen, die Sie benötigen.So in den Fall Sie geben, haben Sie eine Methode, die die Schnittstelle kann verlangen, dass der business Ebene zu Fragen der Datenbank-layer für die Abteilung gegeben, die Benutzer-id.

Beide haben trade-offs.Der erste macht eine Menge mehr Informationen, die möglicherweise an die Verbraucher, die keinen Anspruch auf diese Informationen.Die zweite geht viel weniger Informationen pro Transaktion, erfordert jedoch mehr Transaktionen.Die erste erfordert keine änderung an der API jedes mal, wenn Sie mehr Informationen haben, aber die änderungen der XML.Der zweite hält die Oberfläche der vorhandenen APIs die gleiche, sondern bietet neue APIs wie sich die Anforderungen ändern.Und so weiter.