Freigeben über

Architekturaufbau einer Multi-Layer-Anwendung, die mit dem Persistence Ignorance (POCO) Adapter for Entity Framework V1 = EfPocoAdapter geschrieben wurde

  • Artikel

In meinem letzten Eintrag habe ich kurz vorgestellt, dass man mit dem Entity Framework und POCOs mit effektiv auf relationale Daten zugreifen kann. Zusammenfassend kann man sagen, dass ich in diesem Eintrag https://blogs.msdn.com/mtcmuc/archive/2008/10/24/mehr-poco-plain-old-clr-objects-und-entity-framework-der-persistence-ignorance-poco-adapter-for-entity-framework-v1.aspx, die Vorteile von POCOs und deren Nutzung mit dem EfPocoAdapter und Entity Framework dargestellt.

In diesem Eintrag möchte ich kurz auf die architekturellen Aspekte der Nutzung dieses Adapters in einer mehrschichtigen Architektur eingehen.

Damit man den EfPocoAdapter erfolgreich in einer mehrschichtigen Architektur einsetzen, kann sollte man die generierten Klassen auf verschiedene Assemblies aufteilen.

Der Grund dafür ist, dass man zwar sehr wohl alle EfPocoAdapter generierten Klassen in einem Assembly belassen kann, aber wenn anderen Architekturschichten die POCOs nutzen will, gibt man immer die gesamte "Datenzugriffs"-Schicht frei. Damit wäre zum Beispiel aus der Benutzeroberfläche dann direkt auf Funktionen des Datalayers zugreifbar. Mit dieser Vorgehensweisen untergräbt man die Idee, die hinter dem Konzept des Schichtenaufbaus einer Architektur steht.

Die Ursache für dieses Szenario ist folgende --> Die POCO Klassen werden in allen Schichten der Architektur gebraucht:

  1. Im Datalayer, um Daten aus der Datenbank in eigenen Properties aufzunehmen oder die eigenen Properties als Daten in die Daten zu speichern - via Entity Framework.
  2. Im Businesslayer werden die POCO Klassen Prüfungen unterworfen, sind Bestandteil von Geschäftsabläufen etc.
  3. Im UI - oder Service Interface - Layer werden die POCOs zu Anzeige oder zum Bearbeiten von Service-Requests benötigt.

Deswegen empfiehlt es sich die generierten POCO Objekte in ein eigenes Assembly zu isolieren.

Die Anwendungsarchitektur für einen mehrschichtigen/multilayer Service sähe dann so aus.

Untitled

Die vom EfPocoAdapter generierten Klassen sind in 2 Assemblies aufgeteilt.

Das Assembly BENorthwindPoco.csproj enthält die eigentlichen POCOs und wird von der Datenzugriffsschicht, Businesslogikschicht und vom Service referenziert und benutzt.

image

Die vom EfPocoAdapter generierten Datenzugriffsmethoden sind in dem NorthwindPoco.csproj Assembly gekapselt und nur die direkt darüber liegende Architekturschicht - der Businesslayer - hat Zugriff auf diese Funktionen.

image

 

Die POCO Klassen sind wie gesagt überall verfügbar und können sogar im Interface des WCF Dienstes verwendet werden. Zum Beispiel so ...

 using BE = NorthwindPoco;

namespace SvcNorthwindPoco

{    

    [ServiceContract]

    public interface INorthwindSvc

    {

        [OperationContract]

        BE.Customers GetCustomerByName(string searchString);

    }

}

Die im oben Architekturschaubild dargestellte Lösungsstruktur sieht also als Visual Studio 2008 Solution folgendermassen aus.

image

Viel Spass beim Ausprobieren ... GunnarD

Comments