Hallo zusammen,
ich habe mal eine Frage bzgl. der Zuständigkeit.
Zuerst möchte ich aber mal die (sehr einfach gehaltenen) Klassen vorstellen:
Artikel
-- ID
-- Name
-- Einzelkomponentenliste
Einzelkomponente
-- ID
-- Name
-- Bauelementliste
Bauelement
-- ID
-- Name
Repositories sind ja nur fürs Lesen, Hinzufügen, Aktualisieren und Löschen zuständig.
Nun möchte ich einen Artikel hinzufügen, der zwei Einzelkomponenten mit jeweils 2 Bauelementen hat und übergebe diesen an meinen Artikel-Service, womit ich zu meiner eigentlichen Frage komme:
Übergibt der Service den Artikel ans Artikel-Repository und darin ist die Logik, dass die Einzelkomponenten über das entsprechende Repository gespeichert werden (und das reicht wiederum die Bauelemente weiter) - oder steckt die Logik dafür im Service, der die einzelnen Objekte dann auf die Repositories verteilt?
Für beide Varianten sehe ich sowohl Vor- als auch Nachteile, bin mir aber nicht zu 100% sicher, wie man es nun machen sollte.
Gruß
pinki
Ich baue hier i.d.R. einen hierarchischen Aufbau.
Das bedeutet, dass der Artikel - wird er als gesamtes hinzugefügt - über dessen Repository auch die Navigation Properties hinzufügt.
Nur dann kannst Du auch die Transaktionen sauber schneiden.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Also würde das Artikelrepository auch die Einzelkomponenten selbst hinzufügen?
Wie sähe es aus, wenn diese ans Einzelkomponentenrepository weitergereicht würden und dann ein optionales Transaktionsobjekt mit übergibt? Wäre das auch noch sauber oder geht das eher in Richtung Pfusch?
Kann man prinzipiell machen; bin nur kein großer Fan davon, dass die Repositories sich untereinander kennen.
Alle Repositories sollten ja von Haus aus den gleichen Kontext teilen.
Im Prinzip kannst Du also alles getrennt in den jeweiligen Repositories behandeln und dann im Service das Transaction-Commit machen.
Die Sache ist halt, dass die irgendwie den Zugriff auf die SCOPE_IDENTITY() brauchst, sofern Du mit Int als ID arbeitest, damit Du direkt die Foreign Keys setzen kannst.
Das muss also im gleichen Command stattfinden.
Einfacher ist es hier natürlich dann mit einer Client Side ID via Guid.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
bin nur kein großer Fan davon, dass die Repositories sich untereinander kennen.
Warum denn nicht?
Mir kommt es sonst so vor als ob das eine zu große Zuständigkeitsverletzung wäre.
Oder ist das hier in Ordnung bzw. kommt mir das nur so vor?
Die Zuständigkeit gibt es ja nur virtuell, weil die Repositories ja einen gemeinsamen Kontext haben (müssen).
Das Problem ist, wenn sich die Repositories untereinander kennen: das geht nur in eine Richtung.
Und schon hast Du ne Circular Dependency 😉
Da läufst relativ schnell in Szenarien, wo Du dann Workarounds brauchst.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code