Laden...

Repository & Service: Was gehört wo rein?

Erstellt von pinki vor 5 Jahren Letzter Beitrag vor 5 Jahren 1.393 Views
pinki Themenstarter:in
709 Beiträge seit 2008
vor 5 Jahren
Repository & Service: Was gehört wo rein?

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

16.807 Beiträge seit 2008
vor 5 Jahren

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.

pinki Themenstarter:in
709 Beiträge seit 2008
vor 5 Jahren

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?

16.807 Beiträge seit 2008
vor 5 Jahren

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.

pinki Themenstarter:in
709 Beiträge seit 2008
vor 5 Jahren

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?

16.807 Beiträge seit 2008
vor 5 Jahren

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.

  • "Gibt mir alle Artikel einer Liste"
  • "Gib mir alle Listen, auf denen dieser Artikel ist"

Und schon hast Du ne Circular Dependency 😉
Da läufst relativ schnell in Szenarien, wo Du dann Workarounds brauchst.

pinki Themenstarter:in
709 Beiträge seit 2008
vor 5 Jahren

Ja, das macht Sinn.

Danke! =)

P
1.090 Beiträge seit 2011
vor 5 Jahren

Schau dir hier mal die Unit Of Work an.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern