Was soll ich von der UI-Ebene zur Business-Ebene zurückgeben?

Question

Ich schreibe eine ASP.NET-Anwendung, die ich eine UI-Ebene, Business-Logik-Ebene und Datenzugriffsschicht haben. Von meiner Datenschicht gebe ich Geschäftsobjekte an die Geschäftslogikschicht zurück und übergebe diese an die UI-Schicht. Ich bin mir jedoch nicht sicher, was ich tun soll, wenn ich Daten aus der UI-Ebene speichern oder einfügen möchte.

Sollte ich das Geschäftsobjekt auf der UI-Ebene erstellen und an die Business-Schicht weitergeben oder sollte ich es in der Business-Schicht erstellen?

vielen Dank

Answer 1

Ich stimme crunchdog zu - für alle außer den einfachsten Webanwendungen sollten Sie eine flache Form Ihrer Geschäftsobjekte speziell für Ihre UI/Ansichtsebene haben. Manchmal wird dies als View Model-Klasse bezeichnet und enthält in der Regel nicht mehr als mehrere String-Eigenschaften, von denen der UI-Layer direkt und ohne Berücksichtigung der Validierung abgerufen werden kann. (Siehe asp.net mvc)

Zum einen das hält die UI-Schicht saubere und einfacher, so dass es es Bemühungen setzen zu den Anzeigen von Daten, anstatt Objektstrukturen durchlaufen, die Überprüfung für und nulls Interpretation usw.

Dies auch Gibt der Business-Schicht die Möglichkeit, diese String-Werte zu validieren und die eingegebenen Werte zurückzugeben, wenn sie ungültig sind. Dies kann zu Frustration bei der Codierung führen, wenn beispielsweise Ihr Server ein ungültiges Datum in einem Datumsfeld verarbeiten muss. Die Business-Schicht, die die ungültigen Werte erkennt, kann sie genau wie empfangen mit den richtigen Fehlermeldungen zurückgeben. Wenn Sie sich nur mit Geschäfts-/Domänenobjekten beschäftigt haben, passen einige der eingegebenen Werte möglicherweise nicht immer zu den Objekten, die sie enthalten sollen.

Es kann auch hilfreich sein, eine Klasse zum Zuordnen von Werten zwischen den Geschäfts-/Domänenobjekten und dem UI-Objekt/Ansichtsmodell zu verwenden. Dies trägt dazu bei, dass die Bedenken der Business-Ebene sauber getrennt bleiben.

Answer 2

Ich finde es besser UI Layer-Objekte zu haben, die die „echten“ Business-Objekte modellieren. Diese Modellobjekte müssen nicht alle Informationen (Assoziationen und dergleichen) haben, die die "echten" Geschäftsobjekte haben. Dann muss die Business-Schicht für die Konvertierung von und zu Geschäftsobjekten verantwortlich sein.

Für Web-Anwendungen ist dies besonders praktisch, da Sie keine übermäßigen Daten an den Client senden müssen.

Answer 3

Wenn Sie keine übermäßige Codierung von Geschäftsobjekten wünschen, haben Sie beim Abrufen von Daten (wo Sie das gleiche Geschäftsobjekt von DAL nach BL zur UI zurückgeben) das Richtige getan.

Beim Speichern der Daten können Sie diese Objekte als Parameter auf Ihrer BL- und/oder DAL-Ebene übergeben. Sie können das aktuelle Objekt entweder zurückgeben, wenn Sie es auf Ihrem UI-Steuerelement gebunden haben, oder eine neue Instanz dieses Objekts erstellen und die vorgenommenen Änderungen festlegen.

Dann lesen Sie das Objekt auf Ihrer DAL-Ebene und speichern Sie die Änderungen in der Datenbank.

Answer 4

Ich habe festgestellt, dass die einfachste Lösung darin besteht, ein View Model-Objekt aus mehreren Gründen von der Benutzeroberfläche an die Business-Ebene übergeben zu lassen. Am offensichtlichsten ist, dass die Validierung in der Business-Schicht erfolgen sollte, sodass das Erstellen eines Geschäftsobjekts in der Benutzeroberfläche die Prinzipien von MVC verletzt.

Noch wichtiger, wenn der Benutzer ungültige Daten eingibt, kann ein Geschäftsobjekt (richtig) nicht in der Lage sein, diese Daten zu akzeptieren.Sie möchten jedoch die vom Benutzer eingegebenen Daten nicht löschen. Daher ermöglicht Ihnen ein validierungsfreies View Model-Objekt, die vom Benutzer eingegebenen Daten zu speichern und weiterzugeben, unabhängig davon, ob sie gültig sind oder nicht.