Java EE meilleure approche de conception. couche logique métier?
Le projet avec lequel je travaille utilise JSF + Spring + Hibernate.
C'est une question de conception sur laquelle j'ai souvent été confus.
J'ai actuellement hérité d'un projet qui contient une approche "layered" dao -> service -> view -> controller.
La couche / niveau "Controller"? a actuellement tous les objets logic et qui interagissent avec le frontal. On m'a dit qu'il est bon de séparer en deux couches / niveaux, où le La couche/niveau" Controller " ne contient que des méthodes/objets qui interagissent avec le frontal et une deuxième couche (bm?) qui contient toute la logique métier utilisé par le contrôleur.
1st.) Quel serait le but de diviser le contrôleur de cette manière?
2e.) Y a-t-il quelque chose de mal à le laisser comme il est actuellement?
3 answers
1st.) What would the purpose be of dividing up the controller in such a way?
, Vous devez gérer la logique métier dans Service Layer. Avantages de la séparation des entités commerciales de Controller/UI Layer:
- Vous pouvez réutiliser les entités commerciales avec d'autres sections client. Exemple: si vous développez une application Web en tant qu'interface utilisateur, vous avez également développé ultérieurement une interface utilisateur de bureau. Dans ce cas, vous pouvez réutiliser vos opérations
Business Layeravec plusieurs interfaces utilisateur. Vous pouvez également utiliser business layer pour travailler en tant que service Web. - Les opérations commerciales découplées sont plus faciles à gérer. Si quelqu'un de l'équipe de développement n'a aucune idée du fonctionnement du code de l'interface utilisateur et ne veut que corriger une logique métier, il peut le faire.
2nd.) Is there anything wrong with leaving it the way it currently is?
Si vous êtes nouveau dans l'architecture en couches, il faudra un certain temps pour comprendre et implémenter les couches souhaitées. Cela dépend du délai et des exigences de l'application. Si vous prévoyez d'utiliser les points ci-dessus dans votre application, optez pour une architecture en couches, sinon optez pour l'implémentation actuelle.
Si vous demandez pourquoi c'est une bonne idée d'avoir une couche de service utilisée par la vue, la réponse est que le plus souvent, vous souhaitez accéder aux services à partir de parties de l'application différentes d'une vue spécifique.
Par exemple, supposons que vous ayez une logique pour valider une commande, qui au début était principalement utilisée sur certains /order.page xhtml. Cela ne nuirait pas à cette page d'avoir le Service et les objets correspondants (disons Order) juste là dans la vue.
Mais alors l'exigence vient de faire la validation de la commande à partir d'un travail par lots. Si le code de cette validation est étroitement couplé à votre vue, ce sera impossible ou très difficile et très probablement très gênant (j'ai vu des gens se moquer d'un JSP PageContext car une logique métier l'exigeait).
Il y a d'autres situations où cela se glisse, comme par exemple une API externe via JAX-RS, une vue totalement différente (page pour un autre utilisateur, ou peut-être une interface utilisateur ciblée mobile), etc.
La couche de logique métier ne doit pas être implémentée sur la couche de service.
DAO / Couche de service - > Couche de logique métier - > Contrôleurs d'interface utilisateur
- rico