Ai-je implémenté une application n-tier avec MVC correctement?

Question

Étant assez peu familier avec les modèles de conception et l'architecture, j'ai du mal à expliquer aux autres exactement comment ma dernière application est conçue. J'ai basculé entre penser qu'il s'agit d'un MVC pure et n-tier, et MVC dans la couche de présentation. Actuellement, je pense que ce dernier est correct, mais je veux des idées de développeurs plus expérimentés.

Comment ça marche:

1. navigateur envoie la requête HTTP à Tomcat. Mappe la requête via web.xml à une servlet (que j'appelle contrôleur)
2. Le contrôleur instancie un ou plusieurs objets métier et appelle des méthodes sur ceux-ci, ie customerBO.getById(12) qui exécutera à nouveau la logique métier/validation avant d'appeler une ou plusieurs méthodes DAO c'est-à-dire customerDAO.getById(12). Le BO renvoie une liste de CustomerVO au contrôleur
3. Le contrôleur prépare les attributs pour la vue (JSP) (request.setAttribute("customers", customers);) et choisit un fichier .jsp à utiliser qui à son tour va itérer la liste et restituer XHTML au navigateur.

Structure (ma proposition/compréhension)

Présentation Niveau: utilise actuellement ce que je pense est une web-application MVC: servlets (contrôleurs), jsp (vues) et ma propre implémentation de OO XHTML formulaires (c'est-à-dire CustomerForm) se trouve ici. Il devrait être possible d'utiliser une interface graphique Swing/JavaFX/Flex en désactivant cette couche de présentation et sans avoir besoin de changer quoi que ce soit sur les couches ci-dessous.

Niveau logique: Divisé en deux couches, avec Business Objects (BO) en haut. Responsable de la logique métier, mais je n'ai pas trouvé grand-chose à mettre ici en dehors de la validation des entrées car l'application consiste principalement en de simples actions CRUD ... Dans de nombreux cas, les méthodes appellent simplement une méthode avec le même nom sur la couche DAO.

Classes DAO avec des méthodes CRUD, qui à nouveau contacte le niveau de données ci-dessous. Possède également des méthodes convertToVO (ResultSet res) qui exécutent ORM à partir de la base de données et des listes d'objets de valeur. Toutes les méthodes prennent des objets de valeur en entrée, c'est-à-dire clientDAO-> save (électeur) et renvoient l'électeur mis à jour en cas de succès et null en cas d'échec.

Niveau de données: Au bas des données sont stockées dans une base de données ou sous forme de fichiers XML. Je n'ai rien "codé" ici, sauf quelques procédures stockées MySQL et des triggers.

Questions (en plus de celui dans le titre):

1. Le M dans MVC. Je ne suis pas sûr si je peux appeler ce MVC n-tier lorsque les modèles sont des listes/VO retournés à partir d'objets métier dans le niveau logique? Les modèles doivent-ils résider dans la couche de présentation lorsque le contrôleur/la vue est présent? Et les modèles de formulaire dans la couche de présentation peuvent-ils être appelés modèles? Si c'est le cas; sont à la fois les formes et les listes de BO à considérer comme M dans MVC? D'après ce que je comprends, dans MVC, la vue est censée observer le modèle et mettre à jour le changement, mais cela n'est pas possible dans une application web où la vue est une page XHTML rendue? Cela m'amène à la question suivante: MVC est-il implémenté différemment pour les applications Web par rapport aux applications de bureau classiques?
2. Je n'utilise pas de pattern Front Controller lorsque toutes les requêtes HTTP sont explicitement mappées dans web.xml non?Pour utiliser le contrôleur frontal, je dois transférer toutes les demandes à un servlet/contrôleur standard qui, à son tour, évalue la demande et appelle un autre contrôleur.
3. La couche de gestion se sentait un peu "inutile" dans mon application. Que mettez-vous normalement dans cette couche/objets? Devrait-on toujours avoir une couche de gestion? Je sais que cela devrait contenir une «logique métier», mais qu'est-ce que c'est exactement? J'effectue juste la validation d'entrée et instancie un ou plusieurs DAOs et appelle les méthodes appropriées dessus ...

Je réalise qu'il y a des frameworks MVC tels que Struts for Java, mais depuis que j'ai essayé ma première application web Java j'ai essayé pour avoir une meilleure compréhension de la façon dont les choses fonctionnent. En regardant rétrospectivement, j'espère que vous pourrez répondre à certaines des questions sur lesquelles je suis tombé.

Answer 1

Je ne sais pas si je peux appeler ce n-tier MVC lorsque les modèles sont des listes/VO de retour des objets d'affaires dans le niveau logique

sont ceux parfaitement bons modèles. Je considère aussi les ActionForms dans Struts comme des modèles. ActionForms est ce que Struts utilise pour représenter/modéliser les formulaires HTML.

dans MVC la vue est censé observer le modèle et la mise à jour sur le changement, mais cela est impossible dans une application web

Oui, et c'est une question de débat pour savoir si vous pouvez avoir vrai MVC avec des applications web.

Faut-il toujours avoir une couche de gestion?

Cela dépend du type d'application. Certaines applications sont pilotées par la base de données et constituent essentiellement une interface utilisateur pour la base de données. Dans ce cas, il y a très peu de logique métier requise.

Niveau de données:

Les procédures stockées ne sont pas vraiment partie du code de niveau de données. Vous devez créer des objets d'accès aux données (DAO) qui sont appelés par les objets métier. Les DAO appellent les procédures stockées. En outre, les interfaces DAO ne doivent pas indiquer aux objets métier où les données sont stockées, qu'il s'agisse d'une base de données, d'un système de fichiers ou d'un service Web.

Answer 2

Je pense que vous êtes coincé dans la terminologie. Le modèle MVC (je crois) est antérieur à l'arc classique de l'application Web que vous décrivez. Il utilise pour être que les gens appelés app arc MVC 2 (Modèle 2, etc.) Web pour le différencier du modèle MVC originale ...

voir ce lien>http://www.javaranch.com/drive/servlet/#mvc2

HTH