Laden...

Aufbau eines Data Service

Erstellt von Urbain vor 11 Jahren Letzter Beitrag vor 11 Jahren 1.684 Views
Urbain Themenstarter:in
77 Beiträge seit 2010
vor 11 Jahren
Aufbau eines Data Service

Hallo,

ich plane gerade einen datenzentrierten Service. Über sollen lediglich Create, Read, Update und Delete-Operationen auf eine Datenbank möglich sein. Es ist mein erstes Projekt in diese Richtung und deswegen wollte ich fragen, was ihr vom bisherigen Aufbau hält und ob es irgendwo Stellen gibt die ich ändern könnte.

Die Anwendung unterteilt sich in drei Schichten.

> Service
> Business Layer
> Data Layer

Ich erkläre die Schichten nochmal anhand eines Beispiels, dem Inserten eines Buchs in die Datenbank über den Service.
In einem separaten Library sind die Entities definiert. Hierbei handelt es sich um die Datenstrukturen, die vom Business und vom Data Layer verwendet werden. Die Entities sind nur Datenspeicher und besitzen keine Methoden.

Service
Der Service ist die Schnittstelle nach außen. Er definiert Service und Data Contracts. Er mappt den Book DataContract zu einem BookEntity-Objekt. Mit dem gemappten Objekt wird die InsertBook-Methode vom Business Layer aufgerufen.

Business Layer
Der Business Layer ist primär für die Validierung der Entities verantwortlich die er entgegennimmt. Ist die Validierung erfolgreich, wird der Data Layer aufgerufen. Es wird dann die InsertBook-Methode des Data Layers aufgerufen.

Data Layer
Der Data Layer ist für alle Datenbankoperationen verantwortlich. Hier validiere ich nicht mehr. Durch die Methode InsertBook wird letzlich eine Connection zur Datenbank aufgebaut und eine Procedure aufgerufen, um einen neuen Datensatz anzulegen.

Ich wollte das alles eben so simpel wie möglich gestalten. Ich bin nur unsicher weil es oft der Fall war, dass später Anforderungen dazu kommen, die ich nicht mehr abbilden kann. Was mich ein bisschen wurmt ist das Mapping. Ich hab gelesen, dass man auf keinen Fall mit den DataContracts innerhalb der Business oder Data Logic arbeiten soll. Deswegen eben die Transformierung der Entities. Nur was ist der Grund dafür das nicht zu machen?
Auch wenn ich im Data Layer später vielleicht einen Object Relational Mapper für den Datenzugriff verwenden möchte, müsste ich in meinem Fall wieder zu mappen anfangen. Einmal vom DataContract zur Entity und diese dann in weiterer Folge dann zur Entity, die zum Beispiel vom Entity Framework generiert wurde. Voll umständlich auf den ersten Blick.

Welche anderen Möglichkeiten gibt es hier noch und passt mein Design? Ich finds nicht übel, aber weil ich da noch nicht soviel Erfahrung habe bin ich unsicher.

Vielen Dank für eure Zeit.

6.911 Beiträge seit 2009
vor 11 Jahren

Hallo Urbain,

grundsätzlich passt dein Aufbau, aber kennst du WCF Data Services? Diese sind genau für so etwas entworfen worden und ich empfehle dir diese zu verwenden anstatt selbst dessen Funktion nachzubilden.

Für das Design schau dir sonst auch patterns & practices: App Arch Guide 2.0 Knowledge Base - Home an, für deinen Fall v.a. Service Architecture Pocket Guide.pdf

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

Urbain Themenstarter:in
77 Beiträge seit 2010
vor 11 Jahren

Danke für die hilfreichen Links. WCF Data Services kannte ich noch nicht.