WCF EntityFramework und Transaktionen

13/02/2009 - 08:39 von Andreas Bürstner | Report spam
Hallo zusammen,
ich hab mal eine konzeptionelle Frage
Ich habe eine WCF-Service der das EntityFramework als DAL benutzt.
In der Regel sind die Methoden des Service folgendermaßen aufgebaut:

void UpdateEntity(Entity entity)
{
using(EntityContext context = new EntityContext())
{
//Veràndere die Daten
context.SaveChanges();
}
}

Vorausgesetzt der Service ist entsprechend konfiguriert, und die Methoden
mit den entsprechenden Attributen versehen, dann kann ich ja im aufrufenden
Client über TransactionScope eine Transaktion öffnen, die den Aufruf mehrerer
meiner WCF Service Methoden beinhaltet.

using (TransactionScope tran = new TransactionScope())
{
Sevice1.Methode1(entity1);
Sevice1.Methode2(entity2);
.
.
.
tran.Complete();
}

Der DTC übernimmt das Hàndling der Transaktion.
Meine Frage basiert nun auf dem Design meiner WCF-Service Methoden. Wenn die
einzelnen Methoden durchlaufen wurden wird ja jeweils beim Verlassen des
using-Blocks die Verbindung zur Datenbank geschlossen. Die Änderungen in der
Datenbank können ja dann nicht mehr committet werden.
Muß ich da dann wirklich innerhalb des Services eine Instanz des
EntityContextes benutzen? Wenn ich da an die ganzen Objekte denke, die der
dann im Speicher hat, oder fehlt mir da dann irendwas? Kann mir jemand auf
die Sprünge helfen, wie man solche Szenarien designed?

Vieln Dank für eure Hilfe.
 

Lesen sie die antworten

#1 Frank Dzaebel
13/02/2009 - 09:51 | Warnen spam
Hallo Andreas,

Zunàchst beachte, dass Du auch Objekte vom Kontext
temporàr loslösen kannst:

[Entity Update in verteilten Szenarien - Linq to Entities]
http://dzaebel.net/EntityUpdate.htm

Was die Frage nach der stàndigen Neuerstellung des
ObjectContext'es angeht, ist das zweischneidig.
Du kannst durchaus auch langfristige ObjectContexte erstellen,
musst Dir aber über die Nebenwirkungen bewusst sein.
Daniel Simmons [MSFT] formuliert es IMHO recht gut,
auf eine àhnlich gestellte NG-Frage:

"There's nothing fundamentally evil about caching the context, but it is a
significant perf drain on your server. Generally speaking, the reason we
recommend having short-lived contexts is that we want to keep our servers as
stateless as possible. This means they can handle more requests and you can
also more easily move to farms of servers where the postback might arrive at
a different server from the original page rendering, etc.
If you know that you don't have those scalabilities needs than something
like caching the context can work, but if that requirement changes later you
may be in for some major surgery on your app. [...]
One last comment, [...] you could consider using the EntityDataSource
Control which can make all of this attach/detach code and such pretty much
done automatically by the control and much easier to manage.

Rick Strahl [MVP] formuliert es in einem vergleichbaren Szenario so:

[Linq to SQL DataContext Lifetime Management - Rick Strahl's Web Log]
http://www.west-wind.com/weblog/posts/246222.aspx

Hier gibt es weitere Background-Infos dazu:

[Gewusst wie: Verwalten der Verbindung in einem lang andauernden
Objektkontext (Entity Framework)]
http://msdn.microsoft.com/de-de/lib...38701.aspx

[Data Services: Erstellen datenzentrischer Webanwendungen mit Silverlight 2]
https://msdn.microsoft.com/de-de/ma...94279.aspx

[Gewusst wie: Verwalten von Object Services-Transaktionen (Entity
Framework)]
http://msdn.microsoft.com/de-de/lib...38523.aspx

[Gewusst wie: Ausführen von Geschàftslogik beim Speichern von Änderungen
(Entity Framework)]
http://msdn.microsoft.com/de-de/lib...16714.aspx

[Gewusst wie: Hinzufügen und Ändern von Objekten mit 'Tabelle pro
Hierarchie'-Vererbung (Entity Framework)]
http://msdn.microsoft.com/de-de/lib...38570.aspx


ciao Frank
Dipl.Inf. Frank Dzaebel [MCP/MVP C#]
http://Dzaebel.NET

Ähnliche fragen