Les contrôleurs gèrent le flux d'application, alors d'où vient ma logique métier aller?

Question

Je commencerai cette question en avouant que je suis très nouveau pour MVC. Le modèle de conception logique me à un niveau élevé, mais maintenant que je suis à explorer ASP.NET MVC, quelques-unes des pièces d'architecture remettent en question mes idées préconçues. L'apprentissage est une bonne chose.

Je travaille avec Oxite ces derniers temps comme un outil d'apprentissage écrit par des personnes au société qui a créé ASP.NET MVC et donc, une application de référence ostensible pour ASP.NET MVC.

Mais aujourd'hui, j'ai vu un blog sur Oxite par Rob Conery qui dit:

  

L'une des choses que l'équipe Oxite   a décidé de faire était de séparer les   Contrôleurs et vues dans un autre   Projet pour ce que je ne peux que supposer est   la séparation de la logique de gestion de   la logique de vue. Cela peut conduire à un certain   confusion puisque les contrôleurs sont destinés   pour gérer le flux d'application - non   nécessairement la logique métier.

Cela m'a jeté pour une boucle. Est-ce un principe de séparation de MVC et donc une erreur par les développeurs Oxite, ou est-ce l'avis de Rob? Si la logique métier appartient dans le modèle, pourquoi l'équipe Oxite a mis dans le contrôleur? Comment puis-je exécuter une action que est logique métier sinon dans le contrôleur?

Suite à cela, que je fais une erreur en utilisant Oxite comme une référence d'apprentissage tenant compte des commentaires comme Rob?

Answer 1

Votre logique métier va dans votre couche d'affaires. Les contrôleurs utilisent la couche d'affaires pour créer un modèle pour votre point de vue de rendre. Un bon exemple est l'application MVC Storefront que Rob Conery a produit. Oxite actuellement obtenir beaucoup de mauvaise presse car il ne semble pas bon faire usage du framework MVC.

La raison pour laquelle vous voulez une couche d'affaires qui est séparé de vos contrôleurs est que vous pouvez réutiliser la couche d'affaires sur plusieurs contrôleurs, ou même plusieurs applications. Un exemple de ceci serait les fonctions normales de l'utilisateur pour l'affichage des données et fonctions administratives pour la mise à jour et l'ajout de données. Vous pouvez utiliser les mêmes composants BL dans les deux cas mais ont des contrôleurs et points de vue pour rendre les données. Les objets de modèles seraient les mêmes.

Answer 2

Vous pouvez mettre en œuvre votre couche d'affaires (à savoir le modèle) avec vos entités, des agrégats, des dépôts et des services. Les services appellent les dépôts, qui tirent des données de votre DAL sous la forme d'entités.

Cela peut être réglé dans un seul projet séparé qui est rien de plus qu'une DLL.

Ensuite, demandez à votre application MVC, ce qui est vraiment votre couche de présentation, et avoir utiliser votre projet de couche d'affaires. les contrôleurs travailleront avec vos services, et pomper les données ces services génèrent dans ViewData qui est ensuite pompée dans vos vues.

Les contrôleurs ne doivent répondre aux préoccupations de routage, telles que les vues à afficher, sur la base de l'entrée d'utilisateur des formes, querystrings, les cookies, sessions, etc.

il y a eu un tollé de la communauté « MVC puristes » au sujet de la validité de Oxite utilisé un bon exemple MVC. La ligne de fond est, la logique métier ne doit pas être contenu dans les contrôleurs, que je suis sûr que vous verrez que Oxite se refactorisé au cours des prochains mois.