data structures update Repository-Muster vs. "intelligente" Business-Objekte




youtube repository pattern (4)

Ich sehe zwei Hauptschulen, wenn es darum geht, größere unternehmensweite Apps auf .NET (Winforms, WPF, ASP.NET) zu erstellen.

Einige Leute verwenden das "Repository-Muster", das ein Repository verwendet, das weiß, wie Objekte abgerufen, eingefügt, aktualisiert und gelöscht werden. Diese Objekte sind eher "dumm", weil sie nicht unbedingt eine ganze Menge Logik enthalten - zB sind sie mehr oder weniger Datenübertragungsobjekte.

Das andere Camp verwendet, was ich "intelligente" Geschäftsobjekte nenne, die wissen, wie man sich selbst lädt, und sie haben typischerweise eine Save () -, möglicherweise Update () - oder sogar Delete () -Methode. Hier brauchen Sie wirklich kein Repository - die Objekte selbst wissen, wie sie sich laden und speichern.

Die große Frage ist : Was nimmst du oder bevorzugst du? Und warum?

Verwenden Sie den gleichen Ansatz in all Ihren Apps oder haben Sie bestimmte Kriterien, wenn Sie einen Ansatz gegenüber dem anderen wählen? Wenn ja - nach welchen Kriterien?

Ich versuche hier nicht, einen Flammenkrieg zu beginnen - ich versuche nur herauszufinden, was alle darüber denken und was deine Meinung ist und warum du ein (oder beide) Muster über dem anderen verwendest.

Danke für jede konstruktive Eingabe!



Ich benutze das Repository-Muster wegen des Prinzips der einfachen Verantwortung. Ich möchte nicht, dass jedes einzelne Objekt wissen muss, wie man es speichert, aktualisiert oder löscht, wenn dies von einem einzigen allgemeinen Repository gehandhabt werden kann


Das Repository-Muster muss nicht zu dummen Objekten führen. Wenn die Objekte außerhalb von Speichern / Aktualisieren keine Logik haben, tun Sie wahrscheinlich zu viel außerhalb des Objekts.

Idealerweise sollten Sie niemals Eigenschaften verwenden, um Daten von Ihrem Objekt zu erhalten, Dinge zu berechnen und Daten zurück in das Objekt zu legen. Dies ist eine Einkapselungspause.

Daher sollten die Objekte nicht anämisch sein, außer wenn Sie einfache DTO-Objekte mit CRUD-Operationen verwenden.

Dann ist es eine gute Möglichkeit, eine Einzelverantwortlichkeit zu haben, wenn Sie die Persistenzbelange von Ihren Objektbedenken trennen.


Es hängt wirklich von den Anforderungen der Anwendung ab, aber wenn ich mit einem komplexen Geschäftsmodell arbeite, bevorzuge ich ActiveRecord. Ich kann die Geschäftslogik an einer Stelle einkapseln (und testen).

Die meisten ORMs (EF, nHibernate usw.) dienen als Ihr Repository. Viele Menschen betrachten eine Schicht oben auf einem ORM, die alle Dateninteraktionen als ein Repository einkapselt, was ich für falsch halte. Laut Martin Fowler kapselt ein Repository den Datenzugriff als Sammlung ein. Wenn Sie also einzelne Methoden für alle Datenabfragen / Mutationen verwenden, können Sie einen Data Mapper oder ein Data Access Object verwenden.

Mit ActiveRecord möchte ich eine Basisklasse "Entity" haben. Normalerweise verwende ich ein ORM (Repository) mit dieser Basisklasse, so dass alle meine Entitäten die Methoden GetById, AsQueryable, Save und Delete haben.

Wenn ich eher eine serviceorientierte Architektur verwende, verwende ich ein Repository (eines, das den direkten Datenzugriff oder ein ORM maskiert) und rufe es direkt in meinen Diensten an.





repository-pattern