Ich habe vor kurzem eine Code-Basis bekommen, die ein paar Dinge tut, ich bin ein wenig anders als ich es normalerweise mache.
Der Hauptunterschied besteht darin, dass Elemente (z. B. ein Dropdown-Listensteuerelement) auf die Geschäftslogikebene (in diesem Fall ein separates Projekt, aber immer noch in derselben Lösung) übertragen werden, wo die Bindung an Geschäftsdaten stattfindet Ort.
Meine natürliche Herangehensweise besteht immer darin, die Informationen, die für die UI erforderlich sind, auf die Oberfläche zu bringen und dort zu binden.
Ich bemühe mich, die erste Technik mit einem der Standardmuster zu verbinden, aber das mag weniger auf die tatsächliche Umsetzung zurückzuführen sein als auf die Idee, was es tut.
Hat jemals jemand diese Art von Architektur kennengelernt? Wenn ja, können Sie die Vorteile erklären?
Die Lösung ist eine ASP.Net-Website. Danke.
Danke,
Ich würde behaupten, dass dies eine schlechte Architektur ist, da der ursprüngliche Entwickler die Geschäftslogik eng an die Präsentationsebene gekoppelt hat. Wenn Sie von Webformularen zu MVC wechseln möchten, müssen Sie Teile Ihrer Business-Schicht umgestalten, was nicht der Fall sein sollte!
Wenn es überhaupt möglich ist, sollten Sie in Betracht ziehen, die Entwicklung der Website auf diese Weise zu verlassen. In der Zwischenzeit können Sie den Entkopplungsprozess zumindest starten, indem Sie die Logik ein wenig weiter aufspalten. Wenn Sie beispielsweise eine BindDropDown(DropDownList ddl) -Methode haben, teilen Sie die Methode auf, so dass Sie eine GetDropDownData() -Methode haben, die Ihr tatsächliches Geschäftsobjekt zurückgibt, und BindDropDown nur die Werte der DropDownList . Auf diese Weise können Sie sich in Zukunft leichter von der engen Kopplung zwischen Präsentations- und Business-Schicht entfernen.
Wenn die Site bereits so gestaltet ist (mit einer klaren Abgrenzung zwischen der Präsentationsschicht, der Zwischenebene für die "Präsentationsbindung" und der Business-Schicht), könnte ich natürlich feststellen, dass dies akzeptabel ist. Es klingt jedoch nicht so.
Nein, Sie sollten nicht UI-Elemente an das Domänenmodell zum Binden / Auffüllen übergeben.
Ihr Domänenmodell sollte idealerweise mit Windows Forms / WPF / Silverlight / ASP.NET / MVC verwendet werden können.
Nun verstehe ich die Idee, dass Ihre Geschäftsobjekte wissen sollten, wie sie sich selbst speichern und rendern usw. Es ist der heilige Heilige Gral, aber in der Praxis funktioniert das nicht gut, da es oft Abhängigkeiten gibt (Datenbank-Middleware, UI-Komponenten) usw.) mit den Funktionen, die Sie nicht in Ihrer BO-Assembly haben wollen, wird Ihre Wiederverwendbarkeit stark eingeschränkt.
Etwas, das Sie tun können, das Ihren Benutzern die Illusion gibt, dass Ihr BO weiß, wie es sich selbst rendert, verwendet Erweiterungsklassen (in einer separaten Assembly, um die Abhängigkeiten zu enthalten) so etwas wie ...
%Vor%Dann kann der API-Benutzer einfach
tun %Vor%aber Sie haben immer noch physische Trennung.
Hat jemals jemand diese Art von Architektur kennengelernt? Wenn ja, können Sie die Vorteile erklären?
Der einzige Vorteil ist die Geschwindigkeit der Entwicklung - auf kurze Sicht; Daher eignet es sich gut für einfache Apps, Proof-of-Concepts (PoC) usw.
Die richtige Abstraktion erfordert normalerweise Zeit und bringt Komplexität mit sich. Die meiste Zeit ist das, was Sie wirklich wollen, aber manchmal könnte eine App als einfaches Wegwerf-PoC gebaut werden.
In solchen Fällen ist es nicht so sehr, dass ein Raum voller Menschen sich für ein paar Stunden hinsetzt und über Architekturen debattiert und zu der Entscheidung gelangt, dass das Binden in der BL sinnvoll ist - es ist normalerweise ein "was auch immer-es-geht" "Schnellster" Anruf von den Entwicklern basierend auf Geschwindigkeit.
Zugegeben, diese einfache Faulheit oder Ignoranz wird wahrscheinlich der Grund sein, warum sie in anderen Fällen verwendet wird.
Ihre Business-Schicht sollte ein Model-View-Modell zurückgeben, das die UI-Ebene wiederum verwendet, um den benötigten Zeitraum zu füllen. Es sollte nichts an die Business-Schicht in Bezug auf ui Komponenten - Zeitraum gesendet werden. Es ist so einfach und so hart und schnell von einer Regel.
Tags und Links c# asp.net architecture