Quick Q für Sie Musterexperten da draußen.Einheit der Arbeit und L2S DataContext
Ich möchte ein Repository-Muster, das von der eigentlichen Datenzugriffs-Technologie entkoppelt ist, da ich mich noch nicht entschieden habe und ich möchte, dass es flexibel ist. Also, das könnte L2S, L2E, NHibernate, Lightspeed oder so etwas sein.
Aber ich bin verwirrt über diese UnitOfWork Sache.
In der L2S-Welt scheint dies Ihr DataContext zu sein.
Aber was ist mit einer Nicht-L2S-Welt, stellen Sie sich vor, ich benutze zum Beispiel handgeschriebene SQL.
Meine Frage ist, wer was macht? Rufen Sie in meiner Repo.Save() - Methode das UnitOfWork.Commit auf, das dann das erforderliche INSERT/UPDATE SQL generiert?
Keine definitive Antwort erwarten, aber einige Diskussion wäre gut, nur um sicherzustellen, dass ich auf dem richtigen Weg bin!
Dank
mit diesem Ansatz sind einige Dinge nicht in Ordnung. 1) Die Persistenz-Technologie ist mit dem DataContext (L2S) in die Domäne gelaufen. 2) Da der DataContext außerhalb des Repository-Kontexts verwendet werden kann, können Clients den DataContext einfach dazu verwenden, eigene Abfragen zu generieren, sodass kein Repository benötigt wird. –
Ein IoC-Container kann beide Probleme lösen. IUnitOfWork benötigt nur eine SubmitChanges-Methode, was bedeutet, dass Clients, die sie verwenden, keinen Zugriff auf den Datenkontext haben. Sie können IUnitOfWork in einer DataContext-Teilklasse implementieren. Für die Repositories sollten sie stattdessen vom IoC-Container über Schnittstellen aufgelöst werden. In den konkreten Implementierungen dieser Repositorys kann die konkrete DataContext-Klasse über ihre Konstruktoren eingefügt werden. – mvr