Welches Designmuster ist besser, um mit Controllern/Services/DAOs zu arbeiten

Question

Während meiner Karriere sah ich einige verschiedene Designs, wie man mit DAO, Service, Controller-Schichten arbeitet. Ich möchte nach zwei fragen, die ähnlich sind, aber wenige Unterschiede haben. Das erste Design erzeugt eine sichtbare Barriere zwischen den Schichten. Controller verwenden immer Dienste und nur Dienste. Dienste können andere Dienste oder DAOs verwenden. Controller können kein DAO direkt verwenden. Dieses Design ist klar, hat aber große Nachteile für mich: Wir müssen immer Methoden für jede Methode in DAO erstellen. Aber in vielen Fällen rufen Service-Methoden nur DAO-Methoden und alles andere auf.

Zum Beispiel: Wir haben UserDao

class UserDao { 
    public List<User> findByName(String name) { ... } 
    public List<User> findByLastName(String name) { ... } 
    public List<User> findOlderThan(int age) { ... } 

    ...... 
} 

Alle sind über Methoden, die von Steuerungen eingesetzt. Was sollten wir in unserem Fall tun? Erstellen Sie ähnliche Methoden in UserService:

class UserService { 
    public List<User> findByName(String name) { return userDao.findByName(name); } 
    public List<User> findByLastName(String name) { return userDao.findByLastName(name); } 
    public List<User> findOlderThan(int age) { return userDao.findOlderThan(age); } 

    ...... 
} 

Für mich ist das unnötige zusätzliche Schicht für Nur-Lese-Methoden.

Im zweiten Design haben wir kein Problem damit, weil wir DAOs direkt in Controllern verwenden können. In diesem Entwurf haben wir eine Regel: Wenn wir Daten von "Datenspeicher" abrufen möchten, können wir DAO in jedem Layer verwenden, wenn wir einige Änderungen in "Data Store" vornehmen möchten, müssen wir Service-Methoden verwenden.

Was denkst du, Jungs, über diese Designs? Welches ist besser? Was sollte ich in meinen Projekten verwenden und was sollte ich vergessen? Könntest du mit mir deine Erfahrungen in diesem Bereich teilen?

Answer 1

Dienstleistungen, in MVC und MVC-inspirierten Entwurfsmustern sind der "obere Teil" der Modellschicht. So interagiert die Präsentationsschicht mit der Domänengeschäftslogik (der "Leseteil" sollte auch tatsächlich von den Anzeigeinstanzen ausgeführt werden).

In dieser Struktur fungieren die Dienste als Barriere, die die Präsentationsschicht isoliert und Ihnen zusätzliche Freiheit bei der späteren Änderung der internen Modellstruktur gibt.

Eine andere Sache, die Sie beachten müssen, ist, dass es mehr Strukturen gibt als nur DAO s, mit denen Dienste interagieren. Zunächst einmal gibt es domain objects (Geschäftsobjekte, Modellobjekte), die die verschiedenen Geschäftsregeln einkapseln, die sich auf eine bestimmte Entität beziehen. Dann können Sie auch data mappers haben, die die Speicherlogik anstelle von DAOs abstrahieren. Oder DAOs, die Informationen zwischen Mappern und Domänenobjekten übersetzen. In größerem Maßstab hätte die Anwendung auch unit(s) of work. In kleinerem Maßstab würden Sie mit einigen active record Instanzen in Ordnung sein.

Man könnte sagen, dass Modellschicht drei Hauptgruppen von Strukturen enthält, in denen das Gerät verschiedene Aspekte des Modells trennt: Domäne, Speicher und Anwendungslogik.

Die Anwendungslogik ist die Interaktion zwischen Speicherstrukturdomänenobjekten. Dafür sind die Dienste verantwortlich.

Wenn Sie DAO verfügbar machen, beginnt Ihre Modellschicht in der Präsentation zu lecken. Controller sollten keine Ahnung haben, welche Strukturen verwendet werden und wann sie beibehalten werden.