Allg. Entwurfsmuster im .NET

Dekoratoren

Im Detail offenbart ein zu modellierender Ausschnitt einer Geschäftswelt eine große Vielfalt an Objekten, die allgeneiner betrachtet ein und derselben Klasse angehören. Beispielsweise können die Benutzer einer Webanwendung genauer betrachtet zu folgenden Unterklassen gehören:

1. Nutzer ohne Sonderrechte
2. Autoren, welche die Inhalte der Anwendung liefern und pflegen
3. Administratoren, welche die Verwaltung von Benutzern und Rechten verantworten

Das Single responsibillity princip (SRP) würde die Erstellung einer allgemeinen Benutzerklasse, welche alle möglichen Rollen wie Autoren und Admins erfüllen kann, verbieten.

SRP mittels Vererbung implementieren

Ein naheliegender Ansatz wäre eine Klassenbibliothek, welche über Vererbung die Mengen möglicher Benutzer und ihrer Rollen implementiert:

Nachteil dieses Entwurfes ist jedoch, das ein Benutzer entweder Autor oder Admin ist. Admins, die auch Autoren sind, wären hier nicht abbildbar.

SRP mittels Dekoratoren implementieren

Eine allgemeine Benutzerklasse, die bei Bedarf um Admin- oder Autor- Methoden erweitert werden kann, bietet das Dekorator- Pattern ( Details hier).

 var Anton = new User();
 Anton.Name = "Anton";
 // Anton als Admin
 var AntonAsAdmin = new AdminDeco(Anton);
 AntonAsAdmin.CreateNewUser("Berta");
            
 // Anton als Author
 var AntonAsAuthor = new AuthorDeco(Anton);
 AntonAsAuthor.CreateNewDoc("X99", "Designpatterns- Leitfaden");           

Dekoratoren durch Erweiterungsmethoden

C# ermöglicht durch Erweiterungsmethoden die Dekoration von Klassen. So können z.B. versiegelte Klassen für eine Anwendung um Eigenaschften und Methoden erweitert werden. Die Erweitrung von IEnumerable im .NET Framework ist ein Beispiel.

public static class UserExt
{
   public static System.Collections.ObjectModel.ObservableCollection Logfile = new System.Collections.ObjectModel.ObservableCollection();
   public static void Log(this User user, string LogMessage)
   {
      UserExt.Logfile.Add(string.Format("{0,8:s}: ({1}) {2}", DateTime.Now, user, LogMessage));       
   }
}
// ... Anwendung im Code
var Anton = new User();
Anton.Name = "Anton";
// Erweiterungmethode (C# dekoriert Klassen !)
Anton.Log("frisch angelegt");

Cross Cutting Concerns = Querschnittsmethoden

Cross Cutting Concerns beschreiben Funktionen, die nicht zur Kernfunktionalität einer einzelnen Klasse gehören, bei Bedarf aber dieser zugeornet werden sollen (Typische Auflistung hier). Beispiele sind das Logging von Methodenaufrufen, oder die Prüfung von Zugriffsberechtigungen beim Methodenaufruf.

Implementierung von Cross Cutting Concerns mittels Dekoratoren

Eine mögliche Implementierung von Cross Cutting Concerns sind Dekoratoren. Dies wurde oben schon mittels der Erweiterungsmethode Log implementiert.

Algorithmen über Querschnittsmethoden mittels dynamic Parameter

Implementierung von Cross Cutting Concerns mittels Unity- Interception (Proxies)

Von Unity ausgelieferte Klassen können in Proxies eingepackt werden. Diese fangen Aufrufe an die Methoden ab, und erlauben so die vereinfachte Implementierung von Cross Cutting Concerns, indem sie unabhängig von bestimmten Klassen implementiert werden können. Implementirung der Interception

Detallierte Informationen hier

Net- Implementierung spezieller Entwurfsmuster für BL und DAL

Abstraktion der Filter- und Sortieroperationen

Mittels des Builder- Desingpatterns können Filter- und Sortieroperationen der Repositories im Business- Layer erfolgreich von den Implemnetierungen abstrahiert werden.

Unit of Work

Implementing the Repository and Unit of Work Patterns in an ASP.NET MVC Application

Geschäftsobjekte modellieren mittels EF Code First

Eine Einführung ins ADO.NET Entity- Framework gibt es Eine hier

Entwurfsmuster zur Implementierung von graphischen Oberflächen

MV- Pattern

Typisch für für den Einstieg in viele GUI- Baukästen wie Windows Forms, WPF oder ASP.NET Webforms ist die Gestaltung einer kleinen grafischen Benutzeroberfläche (Dialog), und anschließend die Implementierung der Geschäftslogik in den Event- Handlern der Steuerelemente der GUI (z.B. button_click(...)).
Die View (= grafische Oberfläche) wird hierbei dierekt an das Model durch Berechnungen in den Event- Handlern gebunden. Das Muster wird als MV-Pattern bezeichnet.

MVP- Muster

MVP-Muster allgemein, Beispielimplementierung für Login- View

Das MV- Muster ist für größere Projekte ungenügend: Große Teile der Geschäftslogik, die insbesondere Workflows beschreiben, müssen in den Eventhandlern der View implementiert werden. Dieser Teil der Geschäftslogik kann damit kaum getestet werden.

Abhilfe schafft das MVP Muster (= Model View Presenter). Der Presenter wird gegen die Schnittstellen des Models und der View programmiert: class Presenter{ Pesenter(IView view, IModel model){...}}. Die Workflows aus den Eventhandlern werden in Methoden des Presenters ausgelagert, wie folgendes Bild zeigt

→ Besispielanwendung "SucheSmileys" in Projektmappe ASP_NET.Basics

MVVM- Muster

Eine Weitere Möglichkeit, Teile der Geschäftslogik aus dem den Eventhandlern des Page- Controllers einer Webform zu "verbannen", bietet das Architekturmuster MVVM (=Model View ViewModel).

→ Beispielanwendung "_06_Datenbindung\Modelbindung.aspx" in der Projektmappe ASP_NET.Basics

MVC- Muster

---