Beste Architektur für die ASP.NET WebForms-Anwendung

Ich habe ein ASP.NET WebForms-Portal für einen Client geschrieben. Das Projekt hat sich eher entwickelt als von Anfang an richtig geplant und strukturiert. Folglich wird der gesamte Code innerhalb desselben Projekts und ohne Ebenen zusammengefügt. Der Client ist jetzt mit der Funktionalität zufrieden, daher möchte ich den Code so umgestalten, dass ich zuversichtlich bin, das Projekt freizugeben. Da es viele verschiedene Möglichkeiten zu geben scheint, die Architektur zu entwerfen, möchte ich einige Meinungen über den besten Ansatz haben.

FUNKTIONALITÄT

Über das Portal können Administratoren HTML-Vorlagen konfigurieren. Andere zugeordnete "Partner" können diese Vorlagen anzeigen, indem sie ihrer Site IFrame-Code hinzufügen. Innerhalb dieser Vorlagen können Kunden Produkte registrieren und kaufen. Mit WCF wurde eine API implementiert, mit der auch externe Unternehmen eine Schnittstelle zum System herstellen können. In einem Admin-Bereich können Administratoren verschiedene Funktionen konfigurieren und Berichte für jeden Partner anzeigen. Das System sendet Rechnungen und E-Mail-Benachrichtigungen an Kunden.

AKTUELLE ARCHITEKTUR

Derzeit wird EF4 zum Lesen / Schreiben in die Datenbank verwendet. Die EF-Objekte werden direkt in den Aspx-Dateien verwendet. Dies hat eine schnelle Entwicklung ermöglicht, während ich die Site geschrieben habe, aber es ist wahrscheinlich nicht akzeptabel, sie so zu halten, da sie die Datenbank eng mit der Benutzeroberfläche verbindet. Teilklassen der EF-Objekte wurden mit einer spezifischen Geschäftslogik versehen.

FRAGEN

Das Ziel des Refactorings besteht darin, die Site skalierbar, leicht zu warten und sicher zu machen.

1. Welche Art von Architektur wäre dafür am besten geeignet? Bitte beschreiben Sie, was in jeder Ebene sein sollte, ob ich das DTO / POCO / Active Record-Muster usw. verwenden soll.

2. Gibt es eine robuste Möglichkeit, DTOs / BOs automatisch zu generieren, sodass zukünftige Verbesserungen trotz der zusätzlichen Ebenen einfach zu implementieren sind?

3. Wäre es vorteilhaft, das Projekt von WebForms in MVC zu konvertieren?

Das ASP.NET MVP-Muster ist die beste Architektur für eine langfristige ASP.NET-Webforms-Anwendung. Es kommt mit dem Konzept der "Trennung von Bedenken" ins Spiel, das de facto ein Trend hinter den MV * -Mustern ist.

Die Frage, warum man es benutzt? - ausführlich in diesem Beitrag behandelt - ASP.NET MVP

• Erste Schritte mit dem Testen einer ASP.NET-Webforms-Anwendung
• Kompromisse zwischen MVP und MVC
• Ende der Verwirrung: MVP gegen MVC

1. Verwenden Sie das MVP-Muster für separate und logische und UI, sodass Sie in Zukunft zu einer anderen UI-Technologie wechseln können, die vorhandene Logik wiederverwendet
2. Verwenden Sie das Repository-Muster zwischen BL und DAL, damit Sie zu jedem RDBS wechseln können, der die Geschäftslogik wiederverwendet
3. Bringen Sie separate Ebenen (DLLs) für BO und DAL mit, um die Wartung zu minimieren.

Wie ElYusubov erwähnte, kann das MVP-Muster großartig sein.

Das Schlüsselkonzept besteht darin, den größten Teil oder die gesamte Logik aus dem Code-Behind zu entfernen. Die Logik sollte nicht an eine Seite gebunden sein. Was ist, wenn Sie die Logik von einer Seite auf einer anderen wiederverwenden müssen? Sie werden versucht sein, zu kopieren und einzufügen. Wenn Sie dies tun, wird Ihr Projekt wartbar.

Beginnen Sie also zunächst damit, Ihre Logik aus dem Code-Behind heraus zu überarbeiten und sie in eine Business-Ebene zu integrieren. Wenn Sie es geschafft haben, die gesamte Logik aus dem Code-Behind herauszuholen, können Sie die erforderlichen Schnittstellen implementieren, um ein echtes MVP zu sein.

Stellen Sie außerdem sicher, dass Ihr Datenzugriff von Ihrer Geschäftslogik getrennt ist. Erstellen Sie eine Datenschicht und beginnen Sie auch an diesem Ende mit dem Refactoring. Da Sie EF4 verwenden, ist dies weniger problematisch, da EF dieses Ende bereits separat haben sollte. Sie sollten in der Lage sein, alle Ihre EF-Dateien einfach in ein anderes Projekt zu verschieben und einfach einen Verweis auf die Projekte hinzuzufügen, die es benötigen. Der zusätzliche Vorteil besteht darin, dass Sie möglicherweise in anderen Projekten auf Ihr Datenmodell verweisen müssen.

Um nicht überfordert zu werden, müssen Sie jeweils ein wenig umgestalten. Wenn Sie einen Code berühren, sollten Sie den Code um ihn herum neu gestalten. Wenn Sie dies tun, kann Ihr Projekt im Laufe der Zeit wartbarer werden.

Bearbeiten

Sie haben gefragt, ob der Code dahinter eine Geschäftslogikklasse erben soll. Dies ist nicht möglich, da der Code hinter der Seite "is-a" ist. C # erlaubt keine Mehrfachvererbung, daher kann die CodeBehind-Klasse nicht sowohl eine Seite als auch ein benutzerdefiniertes Objekt sein. Sie müssen die Logik konzeptionell trennen. Es ist wahrscheinlich der Fall, dass der Code in Ihrem Code-Behind viele verschiedene Dinge tut. Eine Klasse sollte nur eins und eins tun. Überlegen Sie, wie Sie vorhandene Funktionen konzeptionell nutzen können. Angenommen, Sie haben eine Registrierungsseite und sammeln Benutzerinformationen. Sie haben wahrscheinlich eine Schaltfläche namens register und ein Klickereignis, das dieser Schaltfläche zugeordnet ist. In diesem Fall speichern Sie Benutzerinformationen und führen die erforderliche Verarbeitung durch. Sie können ein Registrierungsobjekt erstellen, um die gesamte Logik zu verarbeiten.

Dies ist nicht nur eine sauberere Trennung, sondern kann auch eine Möglichkeit sein, Ihren Code selbst zu dokumentieren. Wenn jemand Ihren Code liest, sieht er, dass Sie ein Registrierungsobjekt aufrufen, damit Sie genau wissen, was los ist.

Wenn Sie das MVP-Muster genau befolgen möchten, implementiert der CodeBehind eine Schnittstelle, anstatt die Parameter an das Registrierungsobjekt zu übergeben. Die Implementierung der Schnittstelle würde im Wesentlichen alle Ansichtsobjekte (Textfeld usw.) der Schnittstelle zuordnen. zB öffentlicher String Vorname {get {return txtFirstName.Text; }}

Sobald dies erledigt ist, können Sie die Seite an das Registrierungsobjekt übergeben

Registration.RegisterUser (this);

Und diese RegisterUser-Methode würde die Schnittstelle als Parameter verwenden

public bool RegisterUser (IUser-Benutzer) {user.FirstName ...}

öffentliche Schnittstelle IUser {public string FirstName; }}

Wenn dieses MVP verwirrend klingt, konzentrieren Sie sich einfach auf das Refactoring und wissen Sie, dass der Sinn all dessen darin besteht, die Wiederverwendung von Code zu maximieren. Es gibt kein seitdem, sich zu wiederholen. Das ist das DRY-Prinzip .