Laden...

Entity Framework in verteilter Anwendung

Erstellt von Paschulke vor 10 Jahren Letzter Beitrag vor 10 Jahren 2.366 Views
P
Paschulke Themenstarter:in
69 Beiträge seit 2011
vor 10 Jahren
Entity Framework in verteilter Anwendung

verwendetes Datenbanksystem: SQL Server 2012

Hallo,
ich möchte eine Client-Server-Anwendung mit Entity Framework als OR-Mapper erstellen. Der Client soll eine Click-Once-Applikation werden. Die Kommunikation soll über WCF erfolgen. So der derzeitige Stand der Planung.

Ich habe wegen einer Empfehlung zur besten Vorgehensweise hinsichtlich der Change-Tracking-Problematik in verteilten Anwendungen nun schon einige Zeit gegoogelt und bin verwirrt:
Spontan dachte ich mir, dass eine Lösung mit Self Tracking Entities (z. B. Trackable Entities) sicher sinnvoll ist. Bei der Recherche stoße ich aber immer wieder auf Hinweise, dass die Anwendung von Self Tracking Entities die Arbeit verkomplizieren kann. Ich verstehe aber die i. d. R. sehr knappen Begründungen nicht (ich muss dazu sagen, dass mein Englisch nicht das allerbeste ist 😉). Microsoft selbst empfiehlt seinen eigenen Ansatz ja auch schon nicht mehr, was mich ebenfalls misstrauisch macht...
Ab und zu taucht ODATA als Lösungsidee auf. Aber auch ODATA scheint seine Nachteile zu besitzen...

Ich frage mich:*Welche Alternativen gibt es zu diesen beiden Lösungsideen? *Kann mir jemand möglichst kurz und verständlich die Probleme hinsichtlich Self Tracking bzw. ODATA erläutern? *Kann man Kriterien definieren, die mir den Weg zur "für mich besten" Lösung zeigen können?

6.911 Beiträge seit 2009
vor 10 Jahren

Hallo Paschulke,

Kann man Kriterien definieren, die mir den Weg zur "für mich besten" Lösung zeigen können?

Die Kriterien werden wohl sein, dass es einfach und zuverlässig funktioniert.
Wenns dir nur um den Datenzugriff per WCF geht, so würde ich zu oData bzw. zu den WCF DataServices raten.

Welche Alternativen gibt es zu diesen beiden Lösungsideen?

Indem du selbst den WCF-Service erstellst, der die Datenzugriffe handhabt. Wegen der Trennung vom EF-Context müssen die Entitäten dem EF-Context wieder per Attach bekannt gemacht werden.
Je nachdem wie generisch du das halten willst, wirst du im weitesten Sinne den WCF DataService nachbauen. Daher würde ich eben gleich diesen verwenden.

Kann mir jemand möglichst kurz und verständlich die Probleme hinsichtlich Self Tracking bzw. ODATA erläutern?

ad Self Tracking Entities: ist eher sowie das DataSet und kein reines POCO. Du hast dabei (versteckte) Abhängigkeiten die du eigentlich nicht haben willst.

ad oData: afaik erfolgt die Kommunikation nur über HTTP, d.h. andere Bindungen wie z.B. sind ausgeschlossen. Da es ein Framework ist, sind bestimmte "Dinge" vorgegeben, ob das ein Problem ist kann nicht pauschal beantwortet werden. Recht viel mehr Nachteile fallen mir dazu nicht ein.

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!"

P
Paschulke Themenstarter:in
69 Beiträge seit 2011
vor 10 Jahren

Vielen Dank für die schnelle Antwort 😃
Dann werde mich mal man intensiv mit dem Thema WCF DataServices und OData befassen.

Viele Grüße
Paschulke

P
Paschulke Themenstarter:in
69 Beiträge seit 2011
vor 10 Jahren

So, ich habe mich jetzt mal intensiver mit OData befasst.

Die Technik ist sehr interessant. Aber ich denke, dass ich nicht auf eine Business-Schicht auf dem Server verzichten kann. Vielleicht werde ich für bestimmte Anwendungsfälle OData nutzen aber in der Regel werde ich "normale" Services bauen.

Somit bin ich wieder beim alten Problem. Ich habe mich dann noch einmal intensiver mit der Frage beschäftigt, wo das Problem der STEs liegt. Wenn ich es richtig verstehe, wird der Overhead und die fehlende Interoperabilität kritisiert. Wenn ich nun aber eine Lösung wie im oben beschriebenen Link wähle (hier ein weiterer: Trackable Entities: N-Tier Support for Entity Framework), würden m. E. diese Probleme nicht entstehen: Ich hätte Entitäten mit nur sehr geringem Overhead und eine für andere Clients relativ leicht zu implementierende Schnittstelle. Die Interoperabilität zu anderen Sprachen spielt bei mir ohnehin eher eine theoretische Rolle. Verbauen möchte ich sie mir aber dennoch nicht, wenn möglich.

Denke ich "richtig"? Oder verstehe ich etwas falsch?

Ansonsten: Wie würde man den Service schreiben, wenn man reine POCO-Klassen benutzt. Gibt es dazu ein Entwurfsmuster o. ä.?

211 Beiträge seit 2008
vor 10 Jahren

Hi,

die Frage ist wie viel Aufwand willst du hineinstecken. Auch WCF Data Services bieten dir an Custom Operations zu bauen wenn auch m.M.n etwas "frickelig".
Per WCF kannst du das natürlich alles selber stricken und dann musst du auch die CRUD Operationen für deine Klassen selber programmieren.

Für gewöhnlich sendet man ungern die Entitäten aus dem Entity Framework direkt per WCF an den Client. Hier setzt man gern das Konzept der POCOs ein - das heißt klar definierte kleinere Klassen die nur aus den Daten bestehen. Das kann erheblichen Tippaufwand mit sich bringen den man aber auch per T4 Template minimieren kann wenn man will.

Die Frage ist auch, bzgl. Interop ob du noch mit WCF arbeiten willst oder das ganze per WebAPI und REST Service bauen willst - ist ja momentan "Trendig".

Kontakt & Blog: www.giesswein-apps.at

P
Paschulke Themenstarter:in
69 Beiträge seit 2011
vor 10 Jahren

Für gewöhnlich sendet man ungern die Entitäten aus dem Entity Framework direkt per WCF an den Client. Hier setzt man gern das Konzept der POCOs ein - das heißt klar definierte kleinere Klassen die nur aus den Daten bestehen.

Hier stoße ich wieder auf eine meiner grundlegenden Fragen: Warum sendet man ungern die Entitäten aus dem Entity Framework direkt per WCF an den Client?
Ich lese meistens nur "Das macht man nicht!" Aber warum genau, das habe ich noch nicht herausgefunden.
Ich sehe nicht den Grund, warum man sich nicht seine eigene Änderungsnachverfolgung (siehe o. g. Links) bauen sollte.
Der Service ist dann davon abhängig, dass der Client ihm die angefallenen Änderungen mitteilt. Diese Abhängigkeit des Services vom Client ist sicherlich nicht gut. Wäre das der Hauptgrund, der gegen diese Lösung spricht? Damit könnte ich leben...

16.806 Beiträge seit 2008
vor 10 Jahren

Es werden nur die Informationen verschickt, die wichtig sind - und das sind in 99% aller Fälle nicht die komplette Entität. Desto kleiner und leistungsschwächer das Gerät / die Übertragungsmedien, desto unperformanter wird das ganze.
Ein weiterer Grund ist die Schichtentrennung; es werden reine Transferobjekte übertragen und eben nicht ein DAL Objekt unendlich rauf..

P
Paschulke Themenstarter:in
69 Beiträge seit 2011
vor 10 Jahren

Da hatte ich offensichtlich ein Brett vor dem Kopf.
Für mich war es selbstverständlich, dass ich immer alle Daten einer Entität hin- und her schicke. Mit verteilten Anwendungen hatte ich bisher nicht gearbeitet und deshalb die Probleme noch nicht so richtig "gefühlt".
Ich hatte offensichtlich zu kompliziert gedacht. Das Argument leuchtet mir jedenfalls endlich ein 🙂