Dans MVC, DAO doit être appelé à partir du contrôleur ou du modèle


14

J'ai vu divers arguments contre le DAO appelé directement à partir de la classe Controller et également le DAO à partir de la classe Model.En fait, je pense personnellement que si nous suivons le modèle MVC, le contrôleur ne devrait pas être couplé au DAO, mais à la classe Model devrait appeler le DAO de l'intérieur et le contrôleur devrait invoquer la classe de modèle.Pourquoi, nous pouvons découpler la classe de modèle en dehors d'une application Web et exposer les fonctionnalités de différentes manières, comme pour un service REST d'utiliser notre classe de modèle.

Si nous écrivons l'invocation DAO dans le contrôleur, il ne serait pas possible pour un service REST de réutiliser la fonctionnalité, n'est-ce pas? J'ai résumé les deux approches ci-dessous.

Approche n ° 1

  public class CustomerController extends HttpServlet {

    proctected void doPost(....)  {

            Customer customer = new Customer("xxxxx","23",1);
            new CustomerDAO().save(customer);

    }


 }

Approche n ° 2

  public class CustomerController extends HttpServlet {

    proctected void doPost(....)  {

            Customer customer = new Customer("xxxxx","23",1);
            customer.save(customer);

    }


 }

 public class Customer {

   ...........

   private void save(Customer customer){

        new CustomerDAO().save(customer);

   }

}

Remarque -

Voici ce qu'est une définition du modèle:

Modèle: le modèle gère le comportement et les données du domaine d'application, répond aux demandes d'informations sur son état (généralement à partir de la vue) et répond aux instructions de changement d'état (généralement à partir du contrôleur).

Dans les systèmes événementiels, le modèle avertit les observateurs (généralement des vues) lorsque les informations changent afin qu'ils puissent réagir.

J'aurais besoin d'un avis d'expert à ce sujet car j'en trouve beaucoup en utilisant # 1 ou # 2, alors lequel est-ce?


Le contrôleur doit tout charger du modèle et le transmettre à la vue.
jgauffin

êtes-vous l'approche de suggestion # 2?

1
"Un contrôleur peut envoyer des commandes à sa vue associée pour modifier la présentation de la vue du modèle (par exemple, en faisant défiler un document). Il peut envoyer des commandes au modèle pour mettre à jour l'état du modèle (par exemple, modifier un document)." .. emm .. où est-il dit, que le contrôleur devrait extraire des données ou les faire circuler?
mefisto

Réponses:


31

À mon avis, vous devez faire la distinction entre le modèle MVC et l'architecture à 3 niveaux. Pour résumer:

Architecture à 3 niveaux:

  • données: données persistantes;
  • service: partie logique de l'application;
  • présentation: hmi, webservice ...

Le modèle MVC a lieu dans le niveau de présentation de l'architecture ci-dessus (pour une webapp):

  • Les données: ...;
  • un service: ...;
  • présentation:
    • contrôleur: intercepte la requête HTTP et retourne la réponse HTTP;
    • modèle: stocke les données à afficher / traiter;
    • vue: organise la sortie / l'affichage.

Cycle de vie d'une requête HTTP typique :

  1. L'utilisateur envoie la requête HTTP;
  2. Le contrôleur l'intercepte;
  3. Le contrôleur appelle le service approprié;
  4. Le service appelle le dao approprié, qui renvoie certaines données persistantes (par exemple);
  5. Le service traite les données et renvoie les données au contrôleur;
  6. Le contrôleur stocke les données dans le modèle approprié et appelle la vue appropriée;
  7. La vue est instanciée avec les données du modèle et est renvoyée comme réponse HTTP.

Ce que vous appelez le "cycle de vie d'une demande HTTP typique" n'est pas MVC. Et DAO n'est qu'un objet, ce qui facilite l'interaction / traduction entre la logique du domaine et la persistance. Ce n'est PAS un nom différent pour l'enregistrement actif. Aussi .. depuis quand le modèle fait partie de la présentation?!
mefisto

1
@teresko 1) Oui, c'est MVC, mais dans une architecture à 3 niveaux. Sinon, pourquoi? 2) Vous aviez raison, j'ai édité. 3) Étant donné que l'ensemble du modèle MVC a lieu dans le niveau de présentation. Exemple typique: Spring MVC, dont les modèles ne sont que des cartes contenant des paires clé-valeur. SpringFuse a également fait ce choix.
sp00m

2
Je suis d'accord avec @ sp00m ici ... Sa description d'une demande HTTP typique est exacte pour une application Web MVC, et son positionnement du modèle (comme le «M» dans MVC) dans le cadre du niveau de présentation est également correct . Dans les applications MVC à n niveaux, le «modèle» est généralement la façade du niveau de présentation sur les autres niveaux ci-dessous.
Eric King

8

De la couche modèle.

Pour être plus précis: à partir des services, qui sont contenus dans la couche modèle , car ils régissent l'interaction entre les objets de domaine et les abstractions logiques de stockage.

Le contrôleur ne doit être responsable que de la modification de l'état de la couche modèle. Les DAO font partie du mécanisme de persistance. Cela fait partie de la logique métier et applicative du domaine. Si vous commencez à interagir avec les DAO dans le contrôleur, vous fuiriez la logique du domaine dans la couche de présentation .


Pour utiliser une couche de service, il doit s'agir d'un modèle DDD? Corrige moi si je me trompe. Avons-nous une couche de service dans MVC?

Vous pouvez avoir. Les services sont utilisés pour séparer la logique du domaine de la logique d'application. Cela devient nécessaire, puis vous passez de structures de domaine CRUD pures (enregistrement actif) à quelque chose qui sépare la logique de stockage de la logique de domaine. Dans la couche modèle entièrement réalisée, vous disposez de 3 séparations logiques: persistance, domaine et application.
mefisto

3

Je ne sais pas ce que le modèle MVC officiel appelle, mais j'aime normalement avoir une couche "service" entre les contrôleurs et les DAO. Le contrôleur extrait les données de la demande et les transmet à la classe de service appropriée. La classe de service est chargée d'appeler un ou plusieurs DAO qui retransmettent les classes de modèle. Ces classes de modèle sont ensuite renvoyées au contrôleur afin d'être envoyées à la couche de vue. L'intégration de la couche de service facilite la réutilisation, car plusieurs contrôleurs peuvent utiliser les mêmes méthodes de couche de service.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.