Application MVC.Comment mult-tier architecture dans tout ça?

Question

Je suis nouveau sur le concept de la MVC et multi-niveaux de l'architecture du web.J'ai développer une application en PHP et je suis en utilisant l'un des frameworks MVC.Ma question est comme suit:

Ce que je comprends, MVC, en soi, n'est pas considéré comme une architecture multi-niveaux.Je peux comprendre comment l'utilisation de MVC est une étape d'une approche non structurée, mais je contemplais comment une simple architecture 3 tier serait bon?Serait MVC résident dans la couche de présentation?Quels sont les avantages de l'ajout d'une approche à plusieurs niveaux?De ce que je comprends, avec MVC seul, il n'y a pas de données explicite des objets chargés de l'extraction des données à partir de la base de données et c'est généralement fourré dans le modèle.De même, la logique métier, qui, dans un 3-niveaux de l'architecture réside dans une entreprise de couche " (ou ce que vous voulez l'appeler), peuvent être placés dans le contrôleur.

Est quelque peu ma compréhension correcte?Je sais que je pose beaucoup de questions, mais j'aimerais vous entendre discuter de la façon dont vous avez constitué une architecture n-tiers dans votre MVC framework (PHP ou autre) comme je suppose que les deux ne sont pas mutuellement exclusives.Merci!

Answer 1

M) M est votre modèle.C'est généralement dans votre entreprise de la couche ou la couche juste derrière la couche de présentation.Beaucoup de gens n'aiment pas la couche présentation en ont aucune connaissance de la couche de gestion et si bien que de plus, ils abstraite qu'en ayant ce qu'on appelle un ViewModel.Ces sont le plus souvent DTO (objets de transfert de données) que vaguement carte pour votre modèle de Domaine.Pour moi (.net guy) il existe des outils tels que AutoMapper pour faire la conversion à partir du Modèle de Domaine de Visualiser le Modèle.

V) V est votre point de vue.La vue est la couche de présentation.Ceci est le code HTML ou PHP que l'utilisateur touche directement et interagit avec.La vue doit être aussi léger que possible (ce qui signifie pas de logique, si possible).Essayez de garder toute sorte de if/then type de scénarios hors de la vue et de se contenter de l'affichage et de la collecte de données.Présenter un ViewModel pour votre site web designers afin de ne pas contaminer votre DomainModel.

C) C est votre contrôleur.C'est un peu comme un coordonnateur.Il prend les données de votre point de vue et fait en sorte qu'il arrive à la bonne fin de la fonction/méthode pour le traitement des données.Il coordonne également les données de l'extrémité arrière sur le front-end.

Où multi-niveau de la conception des concepts est derrière la couche de Présentation (où est où MVC est principalement).Lorsque le contrôleur est en prenant les données de la vue et de la passer en arrière de l'extrémité arrière (si vous suivez DDD ou Domain Driven Design) permettrait de transmettre les données à un service d'application (une classe qui coordonne la fin des questions).Le service peut pousser plus loin les données dans un Dépôt de la couche (qui est une classe qui parle à la base de données, système de fichiers, services web, etc.- toute l'infrastructure de trucs).DDD est un sujet majeur, mais obtenir votre tête autour de la n-tier approche et comment il fonctionne avec MVC.

Alors que des recherches sur ce sujet, jetez un oeil à IoC (inversion of control), DI (dependency injection), TDD (test driven development), et autant de modèles que possible (façade, usine, etc.).

Answer 2

En général, la logique métier ne devrait pas être dans le contrôleur - vous vous retrouveriez avec des contrôleurs massifs si vous suivez ce modèle. Le modèle abrite essentiellement toutes vos couches non présentées ... l'accès aux données, la logique métier et les objets entités commerciales. Votre contrôleur prépare les données commerciales pour la vue.