Ich benutze einen Mikro-Orm (Dapper) und versuche, eine Unit of Work (UoW) Implementierung für meine Repositories zu finden. Ich bin ein bisschen ratlos, wie man am besten mit Eltern-Kind-Beziehungen (Fremdschlüssel) in meiner UoW umgehen kann. Also zum Beispiel, wenn ich die folgenden zwei Entitäten habe, die direkt zu Datenbanktabellen gehören:
%Vor%Wo ein Benutzer eine Eltern-Kind-Beziehung mit einer ClientDatenbank über den Fremdschlüssel User.ClientDatabaseId hat. Die Id-Eigenschaft in der Benutzer- und der Clientdatenbank sind Identitätsspalten. Meine UoW-Schnittstelle ist wie folgt definiert:
%Vor%Irgendwann möchte ich innerhalb desselben IUnitOfWork MarkNew () für eine ClientDatabase und einen Benutzer aufrufen und dann Commit (). Jetzt möchte ich, dass die ClientDatenbank zuerst gespeichert wird (untergeordnete Entität) und dann die ID, die in ClientDatabase als Ergebnis ihrer Datenbankeinfügung festgelegt wurde, als Fremdschlüsseleigenschaft ClientDatabaseId für den Benutzer davor festgelegt wird wird dann ebenfalls in die Datenbank eingefügt. Ich habe mich nur gefragt, ob jemand dieses Problem auf eine nette generische Art gelöst hat?
Warum verwenden Sie Ihre Benutzerklasse nicht einfach als Gesamtsystemstamm . Bevor Sie also eine Einfügung in die Datenbank für den Code durchführen, prüfen Sie, ob die ClientDatenbank nicht null ist. Wenn nicht null, können Sie die ID-Eigenschaft überprüfen, um festzustellen, ob es sich um eine neue ClientDatabase oder eine vorhandene handelt (um zu entscheiden, ob Sie eine Einfügung oder ein Update durchführen müssen). Sie könnten dann die ClientDatabaseId-Eigenschaft auffüllen.
Tags und Links c# design-patterns orm dapper unit-of-work