Je construis une application Web qui constitue principalement des opérations de CRUD de données à partir de Back Fin / Base de données. Il y a des cas où je dois écrire une logique commerciale (je suis sûr que nous aurons plus de logique commerciale construite alors que nous allons plus profondément au développement). Actuellement pour chaque écran d'interface utilisateur, je crée, je crée une classe de modèle, une classe de service, une classe DAO, un contrôleur (c'est essentiellement servlet) et des pages JSP. Dans la plupart des cas, la classe de service appelle simplement les méthodes de DAO pour passer des objets de modèle. Essentiellement, nous utilisons des classes de modèle pour cartographier les données des écrans d'interface utilisateur. Par conséquent, le contrôleur aura les objets de modèle peuplés lorsqu'un formulaire est soumis. J'ai commencé à utiliser des classes de service pour conserver une couche de séparation de la couche Web à la couche DAO. Mais parfois, je pense que la classe de service ne fait que ajouter un niveau inutile d'appels d'API, je penserais que je pouvais simplement injecter le DAO dans le contrôleur et compléter la tâche plus rapidement. Je souhaite utiliser la classe de service uniquement lorsqu'il y a une logique commerciale supplémentaire à effectuer. Si vous devez concevoir une application, quels facteurs envisagez-vous d'utiliser Controller-> DAO VS Controller-> Service-> Dao Control Flow?
4 Réponses :
Daos sont plus granulaires et traitent d'une entité spécifique. Les services fournissent des fonctionnalités de niveau macro et peuvent finir par utiliser plus d'un DAO. En règle générale, les services sont utilisés pour définir les limites de la transaction pour obtenir de l'atomicité. En d'autres termes, si vous finissez par mettre à jour plusieurs tables à l'aide de plusieurs DAOS, la définition de la limite de transaction au service vous aidera à s'engager ou à annuler toutes les modifications apportées à DB.
Dans votre conception, car vous faites principalement du CRUD pour diverses entités, il peut sembler que les services ne contribuent pas beaucoup de valeur. Cependant, pensez à l'extrémité avant basée sur le Web comme moyen de mettre à jour les données. L'utilisation des services vous permettra d'exposer les mêmes capacités qu'un service Web plus tard à d'autres formes de client comme des intégrateurs tiers, etc.
Donc, en résumé, votre conception semble être conforme aux pratiques conventionnelles. Si vous sentez que vous pouvez combiner plusieurs services en une seule base sur un thème commun de telle sorte qu'il puisse réduire les frais généraux du code, vous devriez alors aller de l'avant et le faire. En fin de journée, l'objectif ultime est de créer un code maintenu que personne n'a peur de changer quand il faut se poser.
"Utilisation des services" Vous n'avez pas besoin d'une classe de service pour renvoyer une liste simple / effectuer CRUD ou exposer comme une API reposante. Vous avez besoin de classes de service de serpent lors de la manipulation de plusieurs entités interagissantes.
Vous voudrez également des services lorsque vous fournissez des applications externes. Imaginez que vous avez un service Web qui fournit des données pour une application Android. Vous pouvez créer une couche de service qui obtiendra les données et renvoyer DTO (Objets de transfert de données) pour une couche d'adaptateur qui gère les demandes de repos et transforme ces DTOS dans JSON ou XML vers l'application Android.
Je faisais référence à ma réponse ici
La longue et la courte de celle-ci est l'avantage d'utiliser une couche de service, c'est qu'il vous donne de la place à vous déplacer à l'avenir si vous souhaitez faire quelque chose avec la sécurité et les rôles de printemps, etc. Il vous permet de gérer des transactions plus atomiquement et du printemps elle-même a de très belles annotations pour cela.
Ensuite, vous devez passer par les douleurs d'impressionner vos préoccupations DAO de vos contrôleurs. Si vos contrôleurs sont fortement liés à votre DAOS, cela fonctionne plus à l'avenir si vous n'avez pas encore construit de couche de service.
Parce que le service devrait fournir une séparation des préoccupations en.wikipedia.org/wiki/separation_of_concerns . Il serait une pratique médiocre d'ignorer cette façade de service et d'aller directement au DAO du contrôleur si vous avez introduit une couche de service. Bien que au départ, vous allumeriez la règle sèche en n'ayant pas besoin d'une couche de service initialement, le fait que ce soit SOC serait plus une douleur à l'avenir pour tout refactoring.
Je vais juste laisser cela ici ici
Utilisez une classe de service lorsque vous traitez avec plus d'un racine totale .
Injectez des référentiels (AKA A DAO qui renvoie une collection) ou DAO directement dans le contrôleur, pas besoin d'une couche supplémentaire / classe à faire un get de base.
Utilisez uniquement des classes de service si nécessaire, sinon vous avez deux fois plus de code que nécessaire.
Vous pouvez créer un référentiel générique et annoyer à @TransAderal (propagation = propagation.requiked) qui applique une transaction est présente, mais ne créera pas de nouveau si déjà présent. Donc, si vous utilisez ultérieurement des dépositatifs multiples dans une méthode de classe de service, vous n'aurez qu'une transaction unique.
Dans le livre Pro-Spring-3, ils ont mentionné ci-dessous la ligne, pour contrôleur avec JPA2
package com.apress.prospring3.ch10.service.jpa;
// Import statements omitted
@Service("jpaContactService")
@Repository
@Transactional
public class ContactServiceImpl implements ContactService {
private Log log = LogFactory.getLog(ContactServiceImpl.class);
@PersistenceContext
private EntityManager em;
// Other code omitted
}
Je suis entré dans un projet déjà existant lorsque j'ai commencé mon emploi actuel. Je suis ici depuis un peu plus d'un an. Honnêtement, je viens de me rendre compte qu'il est censé être une couche séparée pour injecter Dao. Le projet au travail les injecte simplement dans les contrôleurs. Maintenant que je le sais et que je suis prêt à l'avantage de l'atomicité, je pense que disposer d'une couche de service aurait été bonne puisque nous avons plusieurs entités interagissantes dans la demande.