Est-ce que les aspects remplacent les référentiels?

Question

J'ai commencé à expérimenter avec Spring Roo récemment. Il fait un très bon travail en aidant à construire un modèle de domaine avec une persistance intégrée plutôt rapidement. Comme il ajoute la fonctionnalité de persistance dans les aspects, j'ai commencé à penser à la question suivante:

Roo ajoute finders (charge une instance d'une classe de la base de données qui répond aux critères variables) dans un aspect de la classe/entité réelle. En DDD c'est à mon humble avis la responsabilité des dépôts. Les référentiels sont des classes explicites qui apparaissent dans la conception. Bien sûr, en tant qu'aspect, la fonctionnalité du référentiel est cachée dans une entité et est quasiment invisible.

Voici donc la question: un aspect est-il un réel substitut à une classe de référentiel explicite? Y a-t-il des inconvénients à l'approche Roo AOP?

Answer 1

L'ajout de finders à vos classes de domaine semble plus naturel du point de vue de l'utilisateur, mais il mélange vos couches. Grails utilise la même approche en ajoutant static finder *() save(), ... méthodes. En dehors de l'esthétique, il peut présenter des inconvénients pratiques lorsqu'il n'est pas utilisé dans le paramétrage de l'application Web: Vos classes de domaine sont maintenant liées à votre base de données. Si vous transférez ces objets à des clients enrichis via RMI ou HttpInvoker, le client ne peut pas et souvent ne peut pas utiliser les méthodes find * car aucune connexion de session/base de données n'est disponible sur le client. Je préfère généralement permettre aux classes de domaine de référencer des interfaces de couche de service pour empêcher un modèle de domaine anémique (http://martinfowler.com/bliki/AnemicDomainModel.html). Cela a son propre ensemble d'inconvénients, mais au moins fournit une limite claire. Sur le client, l'implémentation concrète derrière une interface de service peut alors simplement utiliser tous les appels de méthode au serveur proxy (ou simplement utiliser un proxy synami- que avec un remoting de printemps ou sth similaire). Donc, pour répondre à votre question: Il pourrait être un substitut, mais vous devez être conscient des conséquences négatives possibles qui rendent vos classes de domaine (c'est-à-dire votre logique métier) moins portables entre les systèmes.

Answer 2

Cela dépend de la complexité de la couche de persistance de vos applications et de la quantité de contrôle que vous avez sur celle-ci. Si votre application est assez simple pour être implémentée via JPA, alors tout pourrait être géré via les aspects Roo. Toutefois, si vous mappez des tables héritées ou si vous avez besoin de données DB avancées, vous pouvez vous trouver dans une situation où Spring-JDBC est le seul moyen de sortir et dans ces cas, un modèle repository/dao peut toujours être utile. Je considère qu'il est logique et incohérent (et une rupture de la responsabilité des couches) de mélanger deux modèles de persistance et que la plupart de mes applications nécessitent des constructions DB avancées. Je m'en tiens strictement à un modèle de référentiel.

Answer 3

Je pense que l'ajout de méthodes de référentiel aux objets de domaine est une mauvaise conception. Le bon endroit serait des méthodes statiques dans la classe de domaine. Mais les objets de domaine et leur gestion sont deux choses différentes qui doivent être séparées. Je préférerais les objets de domaine et les dépôts.

Je suppose que la motivation était de réaliser quelque chose comme Rails/Grails avec Java.