web-dev-qa-db-fra.com

Pourquoi utiliser la couche de service?

J'ai regardé l'exemple sur http://solitarygeek.com/Java/developing-a-simple-Java-application-with-spring/comment-page-1#comment-1639

J'essaie de comprendre pourquoi la couche de service est nécessaire en premier lieu dans l'exemple qu'il fournit. Si vous l'avez retiré, dans votre client, vous pouvez simplement faire:

UserDao userDao = new UserDaoImpl();
Iterator users = userDao.getUsers();
while (…) {
…
}

Il semble que la couche de service soit simplement un wrapper autour du DAO. Quelqu'un peut-il me donner un cas où les choses pourraient devenir compliquées si la couche de service était supprimée? Je ne vois tout simplement pas l’utilité d’avoir la couche de service pour commencer.

springservice-layer
31
joe martinez

Avoir la couche de service comme wrapper autour du DAO est un anti-modèle courant. Dans l'exemple que vous donnez, ce n'est certainement pas très utile. L'utilisation d'une couche de service signifie que vous bénéficiez de plusieurs avantages:

  • vous pouvez faire une distinction claire entre l'activité de type Web mieux réalisée dans le contrôleur et la logique métier générique qui n'est pas liée au Web. Vous pouvez tester la logique métier liée au service séparément de la logique du contrôleur.

  • vous pouvez spécifier le comportement des transactions. Ainsi, si vous avez des appels à plusieurs objets d'accès aux données, vous pouvez spécifier qu'ils se produisent dans la même transaction. Dans votre exemple, il y a un appel initial à un dao suivi d'une boucle, qui pourrait vraisemblablement contenir plus d'appels dao. Conserver ces appels dans une seule transaction signifie que la base de données fait moins de travail (elle n'a pas besoin de créer une nouvelle transaction pour chaque appel à un Dao), mais plus important encore, cela signifie que les données récupérées seront plus cohérentes.

  • vous pouvez imbriquer des services de sorte que si l'un d'entre eux a un comportement transactionnel différent (nécessite sa propre transaction), vous pouvez l'imposer.

  • vous pouvez utiliser l'intercepteur postCommit pour effectuer des notifications telles que l'envoi d'e-mails, de sorte que cela ne gâche pas le contrôleur.

En règle générale, j'ai des services qui englobent des cas d'utilisation pour un seul type d'utilisateur, chaque méthode sur le service est une action unique (travail à effectuer dans un seul cycle de demande-réponse) que cet utilisateur effectuerait, et contrairement à votre exemple, il y a généralement plus qu'un simple appel d'objet d'accès aux données.

31
Nathan Hughes

Jetez un œil à l'article suivant:

http://www.martinfowler.com/bliki/AnemicDomainModel.html

Tout dépend de l'endroit où vous souhaitez placer votre logique - dans vos services ou vos objets de domaine.

L'approche de la couche de service est appropriée si vous avez une architecture complexe et que vous avez besoin d'interfaces différentes pour vos DAO et vos données. Il est également bon de fournir des méthodes granulométriques pour les clients à appeler - qui appellent plusieurs DAO pour obtenir des données.

Cependant, dans la plupart des cas, vous souhaitez une architecture simple, alors ignorez la couche de service et envisagez une approche de modèle de domaine. Domain Driven Design par Eric Evans et l'article InfoQ ici développent ceci:

http://www.infoq.com/articles/ddd-in-practice

19
Jon

L'utilisation de la couche de service est un modèle de conception bien accepté dans la communauté Java. Oui, vous pouvez tout de suite utiliser l'implémentation dao, mais que faire si vous souhaitez appliquer certaines règles métier.

Disons que vous souhaitez effectuer certaines vérifications avant d'autoriser un utilisateur à se connecter au système. Où mettriez-vous ces logiques? En outre, la couche de service est le lieu de délimitation des transactions.

Il est généralement bon de garder votre couche de dao propre et mince. Je vous suggère de lire l'article "Ne répétez pas le DAO" . Si vous suivez les principes de cet article, vous n'écrirez aucune implémentation pour vos daos.

Veuillez également noter que l'objectif de cet article de blog était d'aider les débutants au printemps. Le ressort est si puissant que vous pouvez le plier en fonction de vos besoins avec des concepts puissants comme aop, etc.

Cordialement, James

19
James Selvakumar