Meilleures pratiques pour l'architecture MVC [fermé]

28

Ma question est plus sur la façon d'architecturer une application MVC. Par exemple, nous sommes encouragés à utiliser DI avec le modèle de référentiel pour découpler l'accès aux données du contrôleur, mais très peu est dit sur la façon de le faire spécifiquement pour MVC. Où placerons-nous les classes de référentiel, par exemple? Ils ne semblent pas être spécifiquement liés au modèle, car le modèle devrait également être relativement découplé des technologies réelles d'accès aux données.

Une deuxième question concerne la façon de structurer les couches ou les niveaux. La plupart des exemples d'applications (Nerd dinner, Music Store, etc.) semblent tous utiliser une approche à deux niveaux, à deux niveaux (sans compter les tests) qui a généralement des contrôleurs appelant directement le code L2S ou EF.

Si je veux créer une application à plusieurs niveaux / couche, quelles sont les meilleures pratiques en matière de MVC?

Erik Funkenbusch
la source

Réponses:

5

DI est accompli dans ASP MVC en utilisant un Controller Factory. Cette usine est utilisée pour résoudre vos dépendances de contrôleur.

MvcContrib dispose de certaines implémentations de Controller Facotry que vous pouvez utiliser immédiatement. J'utilise leur implémentation de Castle Windsor et cela fonctionne bien. Je suggère également de vérifier leur classe TestHelper. Il a des fonctionnalités très intéressantes pour se moquer du contrôleur HTTPContext, des sessions, etc. MVCContrib

Personnellement, j'aime donner à mes modèles une instance de référentiel avec laquelle travailler. Le modèle expose une api au référentiel (CRUD). La dépendance du contrôleur sur un modèle particulier est injectée lors de la création (constructeur), elle est injectée via le Controller Factory. Il s'agit de mon point d'entrée vers le graphe d'objets géré par mon conteneur IoC.


la source
2

Où placerons-nous les classes de référentiel, par exemple?

Ils appartiennent au modèle; c'est le modèle intégré à l'application.

Comment structurer les calques? Si je veux créer une application à plusieurs niveaux / couche, quelles sont les meilleures pratiques en matière de MVC?

Les niveaux représentent les séparations physiques du code. Les couches représentent des séparations logiques. Les couches (telles qu'elles sont actuellement) fonctionnent bien pour MVC. Selon la quantité de logique métier, il peut être placé dans votre contrôleur, ou il peut être placé dans un assemblage séparé et peut être utilisé par le contrôleur pendant le cycle de demande.

George Stocker
la source
Vous proposez donc qu'ils devraient aller dans le projet UI d'une application à plusieurs niveaux?
Erik Funkenbusch
@Mystere Man Si ce n'est pas gigantesque, alors ils devraient aller dans le projet qui héberge votre application MVC. Plus précisément, la logique métier irait dans le contrôleur et chaque action aurait sa propre logique. MVC n'est pas seulement un modèle d'interface utilisateur uniquement; c'est pourquoi je ne suis pas d'accord avec votre affirmation selon laquelle il s'agit d'un «projet d'interface utilisateur». Ça ne l'est pas. C'est un projet MVC qui en tant que Viewsection (il y a votre interface utilisateur).
George Stocker
D'accord, j'ai peut-être mal formulé cela. Cependant, n'êtes-vous pas d'accord que la couche de vue ne devrait pas manipuler la base de données? Et si vous placez les classes de référentiel dans le modèle, la vue peut le faire.
Erik Funkenbusch du
dans une application Small MVC, l'interface utilisateur "Layer" est simplement le dossier qui contient les vues. Dans une application plus large, il pourrait s'agir de son propre projet. S'il s'agit de son propre projet, il se coordonnerait avec le contrôleur et le contrôleur pourrait se connecter au BusinessLayer selon les besoins. Personne en dehors du contrôleur n'aurait même besoin de savoir que la couche métier existe. Je pense que vous pensez automatiquement qu'il s'agit de projets distincts, mais ils ne doivent pas nécessairement l'être.
George Stocker du