Manuell geschriebene Business-Objekte oder DAL-Objekte?

Question

Angenommen, Sie drei Ebenen haben (mit Namespaces):

• Benutzeroberfläche (App.UI) - ruft Prozesse Business-Schicht und kommuniziert Objekte mit
• Business-Schicht (App.Core) - orchestriert verarbeitet und nutzt DAL Schicht Objekte mit
• DAL (App.Data) - manipuliert direkt speichern und weiterhin besteht Objekte

Lassen Sie uns sagen, dass Sie Benutzertabelle und somit reflektiert haben in Ihrem DAL-Schicht in App.Data.User und wahrscheinlich auch App.Data.Users.

In Ihrer Benutzeroberfläche gibt es eine Ansicht, in der Anwendungsbenutzer angezeigt werden.

Um wirklich eine getrennte (geschichtete) Anwendung zu haben, sollten Sie auch App.Core.User und App.Core.Users haben, die Sie wahrscheinlich manuell erstellen müssen.

Die beste Lösung (nach meiner Meinung) wäre natürlich: Es sollte App.Objects.User und App.Objects.Users eine vierte Schicht Business Objects (App.Objects) mit Klassen sein. Diese POCOs würden von allen Schichten geteilt werden. Business-Schicht würde nur erlaubt, DAL zu verwenden, UI wird nur BL verwenden dürfen, aber alle von ihnen würden App.Objects für gemeinsames Objektmodell verwenden.

Asp.net MVC-Vorlagen implizieren zur Verwendung von DAL Objekte direkt auf Views, LINQ 2 Entities auch schaffen keine POCOs per se ...

Also, wenn jede automatisierte Codegenerierung verwenden, sind wir angeblich DAL-Objekte zu verwenden oder unsere freigegebenen POCOs manuell hart zu codieren? Der erste Teil scheint als einfacher Ausweg aber trennt DAL nicht von UI (und kann Bedenken hinsichtlich Sicherheit und Skalierbarkeit später haben), der zweite ist anfällig für Fehler und sehr mühsam mit mittelgroßen Datenbank.

Was würden Sie vorschlagen?

Answer 1

Was Sie App.Objects nennen, ist im Grunde Ihr Domänenmodell und es ist logisch, dass alle Ebenen die Daten weitergeben, aber Sie müssen entscheiden, ob dieses Modell anämisch oder aktiv ist.