web-dev-qa-db-fra.com

Comment utiliser l'architecture en couches du printemps et toujours suivre la structure orientée objet?

J'ai appris le printemps et sa structure en couches (contrôleur, service et DAO)

@Controller("userController")

@service("userService")
@Transactional(     propagation = Propagation.REQUIRED,     isolation = Isolation.DEFAULT,      readOnly = true)

@Repository("userDAO")

Maintenant, je ne sais pas comment utiliser les bonnes pratiques OOPS (comme this ) avec ces structures en couches pour faire un grand projet (le monde réel a une logique métier plus complexe que les exemples d'applications généralement fournis). Je veux également utiliser ces transactions printanières et d'autres fonctionnalités fournies par le framework. Certains peuvent-ils m'aider ou se référer à un projet open source qui clarifie mon doute.

javaspringoopspring-mvcopen-source
26
Nirbhay Mishra

La conception de l'application Spring et OOD ne s'excluent pas mutuellement.

L'application type Spring (MVC) a la structure suivante:

  1. Un ou plus @ControllerDes classes. Ce sont les points d'entrée de votre candidature. Ils ne doivent contenir aucune logique métier. Malgré leur nom, je les identifie comme [~ # ~] v [~ # ~] dans MVC ( Model-View-Controller )
  2. Un ou plus @Service Des classes. C'est là que vous développez votre logique métier (BL). Un des avantages de placer votre BL ici est qu'il peut être réutilisé par plusieurs contrôleurs (par un @Controller et par un @RestController par exemple). Ce sont les [~ # ~] c [~ # ~] dans MVC.
  3. Un ou plus @Repository classes, où vous implémentez votre couche de persistance (base de données, en mémoire, peu importe ...). De plus, vous pouvez implémenter un ensemble de @Components classes qui décrivent vos objets de domaine. Ce sont les [~ # ~] m [~ # ~] dans MVC.
  4. D'autres classes que vous ne pouvez pas mapper dans le modèle MVC, comme @Configuration, @ControllerAdvice et d'autres classes de configuration/gestion Spring.

Lors de la conception de chacun de ces objets, vous pouvez suivre l'approche OOD que vous aimez.

Dans l'exemple OOD que vous avez mentionné, je concevoirais mon application comme ceci:

  1. Une vue (@Controller) pour chaque acteur
  2. Un @Service pour chaque cas d'utilisation
  3. Un @Repository et une @Component pour chaque classe de domaine

EDIT: vous pouvez trouver un exemple de projet que j'ai écrit pour l'université ici . Il implémente ce que j'ai expliqué dans les trois derniers points avec une couche supplémentaire (entre @Controller et @Service) car il était nécessaire de minimiser les dépendances sur le [~ # ~] c [~ # ~] couche. Les concepts s'appliquent toujours.

9
Marco Ferrari

Je pense que vous posez une mauvaise question ici. L'architecture en couches n'est pas intrinsèquement orientée objet et, par conséquent, tout en utilisant (certaines) des pratiques orientées objet avec elle serait possible ou même conseillé, elle ne devrait pas être en soi le but. Cela revient à demander comment utiliser les meilleures pratiques de conduite de camion pour faire du vélo.

Pourquoi dis-je que l'architecture en couches n'est pas orientée objet? Eh bien, comme nous le savons, il existe trois principes qui distinguent la conception orientée objet: l'encapsulation, l'héritage et le polymorphisme.

Bien que les deux derniers puissent ou non être présents, selon vos choix de conception, l'architecture en couches est, à peu près, le opposé d'encapsulation: par nature de cette approche, vous séparez explicitement vos données ("DTOs ") à partir de votre logique (" services ").

Ne vous méprenez pas, le fait que cette approche ne soit pas orientée objet ne signifie pas qu'elle a quelque chose de mal. Et vice versa, "orienté objet" n'est pas synonyme de "bon", c'est l'un des nombreux outils de la boîte à outils d'un programmeur et, comme avec n'importe quel outil, il est mieux adapté à la résolution de certains problèmes que d'autres.

L'architecture en couches est un bon modèle de conception, qui peut être utilisé avec succès pour résoudre de nombreux problèmes d'ingénierie réels. Il a son propre ensemble de meilleures pratiques qui peuvent et doivent être utilisées, et bien que cet ensemble puisse avoir des intersections avec son homologue de la POO, les deux ne sont certainement pas équivalents.

4
Dima

Vous essayez de comprendre deux concepts différents qui peuvent interagir ensemble.

Architecture en couches

L'architecture en couches est l'un des styles d'architecture de l'industrie. En cela, nous avons une couche séparée pour faire une logique spécifique. Par exemple, nous avons une couche de présentation, une couche métier et une couche de service de données. C'est ce qu'on appelle le découpage horizontal de l'application. Il existe d'autres styles architecturaux comme l'architecture orientée service/basée sur les composants où l'application est découpée verticalement.

Supposons que vous ayez un processus de réservation automatisé. Normalement, si vous optez pour la conception d'architecture en couches (découpage horizontal), nous avons une couche différente pour effectuer le travail requis. Mais en ce qui concerne le découpage vertical, nous identifions différentes entités de l'application comme réservation, gestion client, gestion de fonds. Nous implémenterons ces composants et ils s'intercommunieront pour construire notre application de réservation. Le point à retenir ici est que le composant interne peut suivre la même architecture en couches.

Concepts OOPS

Les concepts OOPS vous aident à concevoir l'application de manière orientée objet. Une fois que vous avez identifié le style d'architecture, vous devez implémenter l'application d'une manière extensible qui peut être facilement maintenue. Ainsi, ils ont différentes méthodologies de mise en œuvre. OOPS en fait partie. Il suggère certains des principes de conception qui vous aident à mieux implémenter les applications

Voir SOLIDE

4
BValluri