Ich versuche herauszufinden, wie ich dieses Problem angehen kann. Ich muss einige Daten in 2 Tabellen einfügen, nennen wir sie Tabelle A und Tabelle B.
%Vor%Nun war meine erste Frage: Sollte ein anderes Repository ein anderes Repository aufrufen? Ich denke nicht, dass dies mein aktuelles Problem lösen wird, aber ich möchte das nur für zukünftige Referenzen wissen.
Nun zu meinem Problem.
wenn ich ein create in meinem Repository-Layer (TableARepository) anrufe, um Tabelle A zu erstellen. Ich erstelle auch gleich die Felder für tableB.
%Vor%Also ich denke, das ist in Ordnung, und ich denke nicht, dass ich myBTable-Repository aufrufen müsste (um tableB zu erstellen) für diese oder eine Service-Schicht.
Jetzt ist hier das Problem. TableB-Tabelle sollte die Informationen nur dann in diese Tabelle einfügen, wenn sie nicht gleich "hi" ist.
%Vor%Das würde bedeuten, dass ich meinen TableB so verpacken müsste
%Vor%Jetzt bin ich mir nicht sicher, ob ich das hier machen sollte, da dies fast wie Geschäftslogik aussieht. Zur gleichen Zeit bin ich mir nicht sicher, wie ich diese Geschäftslogik machen soll, da ich den Wert immer noch in die create-Methode einfügen muss, auch wenn er null ist (A1 ist ein Nullable-Feld).
Also sollte ich den TableB Service Layer in der TableA.Id, A1 aufrufen und prüfen, was A1 ist. Wenn gut, dann gehen Sie zum TableB-Repository und fügen Sie es so ein?
Also TabelleARepostiory - & gt; TableB-Dienstschicht - & gt; TableBRepository (wenn dieser Wert gefunden wurde!="Hi").
Ich bin mir also nicht sicher, was ich tun soll.
Nein - ich kann mir keinen Grund vorstellen, warum ein Repository ein anderes Repository oder einen anderen Dienst aufrufen soll. Sie sollten nur Ihre Entitäten beibehalten und Entitäten aus einem Datenspeicher abrufen. Sie sollten die meisten Aspekte Ihrer Anwendung außer der zugrunde liegenden Domäne ignorieren.
Es scheint, als ob Sie davon ausgehen, dass es sich um ein Repository pro Tabelle handeln sollte, was inkorrekt ist. Es sollte ein Repository pro Gesamtstammverzeichnis vorhanden sein, und dieses Repository sollte darauf achten, Daten in allen zugrunde liegenden verwandten Tabellen zu speichern. Es ist in Ordnung für das Repository, eine Logik zu haben, die sich darauf bezieht, wo oder wie die Daten gespeichert werden, aber es wäre am besten, wenn dies in einem gemeinsamen Bereich gekapselt wäre.
Wenn Sie z. B. Personenobjekte haben und in verschiedenen Tabellen nach Geschlecht speichern müssen, können Sie dies mit Vererbung tun (wenn (Person ist Frau) hier speichern ...) oder Eigenschaften für das Objekt (wenn ( person.Gender == Gender.Female) hier speichern ...) oder Spezifikationen (if (FemaleSpecification.IsSatisfiedBy (person)) hier speichern ...).
Die Wächterklausel (param1!="hi") sollte sich in einer höheren Schicht befinden, z. B. in einer Anwendungsdienstschicht.
Die Service-Schicht sollte die beiden Repositories koordinieren.
Tags und Links asp.net-mvc asp.net linq-to-sql repository-pattern