business-Layer mit mehreren Objekten, bei denen alle Eigenschaften aus der Datenbank gefüllt sind, oder einem Objekt, bei dem nur eine Teilmenge gefüllt ist

Question

Ich baue ein mittelgroßes System auf und stehe vor einem Problem, mit dem wahrscheinlich einige von Ihnen schon einmal konfrontiert waren.In meiner Business-Schicht gebe ich Geschäftsobjekte mit einer Teilmenge von Eigenschaften zurück, die für diese Geschäftsmethode wichtig sind. Ich mache mir Sorgen, weil ich am Ende zu viele Objekte mit bedeutungslosen Namen haben kann oder nur eines, bei dem nur eine Teilmenge von Eigenschaften in einem bestimmten Objekt ausgefüllt ist Methode.Lassen Sie mich ein Beispiel geben.

Fall 1

Beispielsweise gehört ein Benutzer zu einer Stadt, die wiederum zu einem Bundesstaat und einem Land gehört, User, City, State und Country befinden sich Tabellen in meiner Datenbank mit vielen Feldern, aber ich möchte eine Liste von Benutzern mit einer Liste von Bestellungen, also erstelle ich ein Geschäftsobjekt mit dem Namen zum Beispiel UserWithOthers mit nur den wichtigen Eigenschaften (UserId, UserName, CityName, StateName, CountryName, List<Order>) und meine DAL ruft nur diese Felder aus der Datenbank ab.

Fall 2

Ich möchte jetzt einen Benutzer mit der Anzahl der Bestellungen zurückgeben, ich beende mit den folgenden Feldern in meinem Geschäftsobjekt (UserId, UserName, CityName, StateName, CountryName, OrdersCount) und die Klasse könnte zum Beispiel heißen UserWithOrderCount

Ich habe an einige Optionen gedacht:

1. Machen Sie diese zwei Geschäftsklassen und füllen Sie sie separat in jeder DAL-Methode aus (diese Objekte sind einfach, aber bedenken Sie, dass die Methode eine komplexe Auswahlabfrage haben kann, die zur Wiederverwendung gekapselt werden muss, damit das Repository-Muster hier zumindest nicht gut passt Ich denke das).
2. Nur ein Objekt erstellen User mit allen Eigenschaften (UserId, UserName, CityName, StateName, CountryName, OrdersCount, List<Order>) und füllen Sie in jeder DAL-Methode nur eine Teilmenge aus, dies impliziert jedoch eine semantische Kopplung, wenn Sie eine Methode verwenden, da Sie wissen müssen, welche Teilmenge von Feldern aus der Datenbank gefüllt wird, und die semantische Kopplung die schlechteste aller Kopplungen ist.
3. Option 1 funktioniert nicht gut, wenn ich später in einer anderen Ansicht beides brauche, List<Order> und OrdersCount Eigenschaft.
4. Bedenken Sie jetzt, dass wenn Sie verwenden ASP.NET Ich dachte, ich würde ViewModels von meiner Geschäftsebene zurückgeben, aber ich denke nicht, dass es eine gute Idee ist, es fühlt sich an, als würde ich etwas verletzen, und es ist auch nicht möglich, weil Meine Geschäftsschicht befindet sich in einer anderen Assembly und nicht in der Webanwendung.
5. Ich möchte nicht immer wieder dieselbe Linq-Abfrage schreiben, aber wenn die Verwendung von NHibernate oder EFCodeFirst "Gefällt mir" Option eins ist, und ich muss Tonnen von kleinen Geschäftsobjekten erstellen.

Wie gehen Sie mit dieser Situation um?Ich denke, das ist eine Designentscheidung auf hoher Ebene.

Answer 1

Zuallererst stimme ich Ihnen definitiv in einigen Dingen zu, die Sie nicht tun:

1. Füllen Sie Geschäftsobjekte nicht teilweise aus, da Sie dann die Verantwortung dafür übernehmen, zu wissen, welche Eigenschaften auf die Clients der Geschäftsschicht aufgefüllt werden, was eine sehr schlechte Vorgehensweise ist.

2. Geben Sie keine Ansichtsmodelle aus Ihrer Business-Ebene zurück;ihre Business-Schicht soll die Geschäftskonzepte der Domäne Ihrer Anwendung darstellen, und ein ViewModel ist ein Datenobjekt, das die Daten enthält, die zum Anzeigen einer bestimmten Ansicht eines Teils dieser Domäne erforderlich sind - die beiden sind sehr unterschiedliche Dinge und die Business-Schicht sollte Sei dir völlig bewusst, dass seine Geschäftsobjekte in irgendeiner Art von GUI verwendet werden.

Ich würde Ihrem ersten Vorschlag folgen - Erstellen Sie ein separates Geschäftsobjekt, um jedes Geschäftskonzept darzustellen.Ich würde dann ein ORM (wie EF oder NHibernate) verwenden, um diese Objekte für mich mit dedizierten Repositorys für jede Objektgruppe zu füllen.Ich würde dann eine Anwendungsschicht verwenden, die die Repositorys aufruft, um die erforderlichen Objekte zurückzugeben.zu diesem Zweck kann Ihr Repository Methoden enthalten, die verbundene Benutzer und Bestellungen für Zeiten zurückgeben, in denen Sie wissen, dass diese beiden Typen zusammen verwendet werden müssen.Auf diese Weise können Sie einen Benutzer mit all seinen Bestellungen in einer Abfrage zurückgeben, während separate, aussagekräftige Entitäten zur Darstellung von Benutzern und Bestellungen beibehalten werden.