Utilisation des services et des DAO dans le contrôleur de mvc de printemps

Question

Je construis une application web qui constitue principalement des opérations CRUD de données à partir de back-end/base de données. Il y a des cas où je dois écrire une logique d'entreprise (je suis certain que nous aurons plus de logique métier à mesure que nous approfondirons le développement). Actuellement, pour chaque écran d'IU que je crée, je crée une classe de modèle, une classe de service, une classe DAO, un contrôleur (c'est essentiellement une servlet) et un tas de pages jsp. Dans la plupart des cas, la classe de service appelle simplement les méthodes de DAO pour passer dans les objets de modèle. Essentiellement, nous utilisons des classes de modèles pour cartographier les données à partir des écrans de l'interface utilisateur. Par conséquent, le contrôleur aura les objets du modèle remplis lors de la soumission d'un formulaire. 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 est en train d'ajouter un niveau inutile d'appels d'API, je pense que je pourrais juste injecter le DAO dans Controller et terminer la tâche plus rapidement. Je souhaite utiliser la classe de service uniquement lorsqu'il existe une logique métier supplémentaire à exécuter. Si vous devez concevoir une application, quels sont les facteurs que vous considérez utiliser contrôleur-> DAO vs contrôleur-> Service-> flux de contrôle DAO?

Answer 1

Les DAO sont plus granulaires et traitent d'une entité spécifique. Les services fournissent des fonctionnalités de niveau macro et peuvent utiliser plusieurs DAO. Généralement, les services sont utilisés pour définir des limites de transaction pour gagner de l'atomicité. En d'autres termes, si vous finissez la mise à jour de plusieurs tables à l'aide de plusieurs DAO, la définition de la limite de transaction au niveau du service vous aidera à valider ou annuler toutes les modifications apportées à la base de données.

Dans votre conception, puisque vous faites principalement CRUD pour diverses entités, il peut sembler que les services n'ajoutent pas beaucoup de valeur. Cependant, pensez à un frontal Web comme un moyen de mettre à jour les données. L'utilisation de services vous permettra d'exposer ultérieurement les mêmes fonctionnalités qu'un service Web à d'autres formes de clients comme des intégrateurs tiers, etc.

Donc, en résumé, votre conception semble être conforme aux pratiques conventionnelles. Si vous pensez que vous pouvez combiner plusieurs services en un en fonction d'un thème commun de sorte qu'il peut réduire les frais généraux de code, alors, vous devriez aller de l'avant et le faire. À la fin de la journée, le but ultime est de créer un code maintenable que personne n'a peur de changer en cas de besoin.

Answer 2

Je référencer ma réponse here

La longue et courte, il est l'avantage d'utiliser une couche de service est-il vous donne de la place pour se déplacer à l'avenir si vous voulez faire quoi que ce soit avec la sécurité du printemps et les rôles etc. Il vous permet de gérer les transactions plus atomiquement et Spring lui-même a de très bonnes annotations pour cela.

Answer 3

Utilisez une classe de service pour plus d'un aggregate root.

Injectez les dépôts (alias dao qui retourne une collection) ou dao directement dans le contrôleur, pas besoin d'une couche/classe supplémentaire pour faire un get basique. N'utilisez les classes de service que si nécessaire, sinon vous avez deux fois plus de code que nécessaire.

Vous pouvez rendre le référentiel générique, et annoter avec @Transactional(propagation = Propagation.REQUIRED) qui impose une transaction est présent, mais n'en créera pas un nouveau s'il est déjà présent. Donc, si vous utilisez plus tard plusieurs repositos dans une méthode de classe de service, vous n'aurez qu'une seule transaction.

Answer 4

Dans le livre Pro-Printemps-3, ils mentionnés ci-dessous ligne, pour le contrôleur avec JPA2

Once the EntityManagerFactory had been properly configured, injecting it into your service layer 
classes is very simple. 

et ils utilisent la même classe que le service et le dépôt comme ci-dessous:

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 
} 

mais dans le cas où vous allez utiliser CRUDRepository ou JPARepository, alors votre DAO sera Interface et vous devrez créer une couche de service pour gérer votre code