Application MVC. Comment s'intègre l'architecture multiniveau?

Question

Je suis nouveau au concept de MVC et de l'architecture Web à plusieurs niveaux. Je développe une application PHP et j'utilise l'un des frameworks MVC disponibles. Ma question est la suivante:

D'après ce que je comprends, MVC en soi n'est pas considéré comme une architecture à plusieurs niveaux. Je peux comprendre comment l'utilisation de MVC à elle seule est une étape de l'adoption d'une approche non structurée, mais je réfléchissais à la façon dont une simple architecture à trois niveaux s'intégrerait. MVC réside-t-il dans la couche de présentation? Quels sont les avantages de l'ajout d'une approche à plusieurs niveaux? D'après ce que je comprends, avec MVC seul, il n'y a pas d'objets de données explicites responsables de la récupération des données de la base de données et cela est généralement bourré dans le modèle. De même, la logique métier, qui dans une architecture à trois niveaux se trouve dans une «couche de gestion» (ou peu importe comment vous l'appelez), peut être introduite dans le contrôleur.

Est-ce que ma compréhension est plutôt correcte? Je sais que j'ai posé beaucoup de questions, mais je voudrais vous entendre discuter de la façon dont vous avez incorporé une architecture n-tier dans votre framework MVC (PHP ou autre) car je suppose que les deux ne sont pas mutuellement exclusifs. Merci!

Answer 1

M) M est votre modèle. Cela réside généralement dans votre couche de gestion ou dans la couche située juste derrière votre couche de présentation. Beaucoup de gens n'aiment pas que la couche de présentation ait une quelconque connaissance de la couche de gestion et donc ils l'abstiennent en ayant ce qu'on appelle un ViewModel. Ce sont souvent des objets DTO (objets de transfert de données) qui correspondent à votre modèle de domaine. Pour moi (.net guy) il y a des outils tels que AutoMapper pour faire la conversion de Domain Model en View Model.

V) V est votre point de vue. La vue est votre couche de présentation. C'est le code HTML ou PHP réel que l'utilisateur touche directement et interagit avec. La vue devrait être aussi légère que possible (ce qui signifie pas de logique si possible). Essayez de ne pas afficher de scénarios de type «si/alors» et de vous contenter d'afficher et de collecter des données. Présentez un ViewModel à vos concepteurs Web afin qu'ils ne contaminent pas votre DomainModel.

C) C est votre contrôleur. C'est un peu comme un coordinateur. Il prend des données à partir de votre vue et s'assure qu'il atteint la bonne fonction/méthode dorsale pour le traitement de ces données. Il coordonne également les données de l'arrière vers l'avant.

Lorsque des concepts de conception à plusieurs niveaux interviennent derrière la couche Présentation (où se trouve MVC principalement). Lorsque le contrôleur prend des données de la vue et les transmet à l'arrière-plan (si vous suivez DDD ou Domain Driven Design), les données sont transmises à un service d'application (une classe qui coordonne le back-end). Le service peut en outre pousser les données dans une couche Repository (qui est une classe qui parle à la base de données, au système de fichiers, aux services Web, etc.). DDD est un sujet important, mais vous comprendrez mieux l'approche n-tier et comment cela fonctionne avec MVC. En étudiant ce sujet, jetez un oeil à IoC (inversion de contrôle), DI (injection de dépendance), TDD (développement piloté par test), et autant de motifs que possible (façade, usine, etc.).

Answer 2

En règle générale, la logique métier ne doit pas se trouver dans le contrôleur: vous obtiendriez des contrôleurs massifs si vous suiviez ce modèle. Le modèle contient essentiellement toutes vos couches de non-présentation ... accès aux données, logique métier et objets d'entité métier. Votre contrôleur prépare les données métier pour la vue.