Comment structurer une application MVC d'entreprise et où se trouve la logique métier?

Question

Je suis un débutant en MVC. Pour autant que je puisse dire :

• Contrôleur : gère le routage des requêtes
• Vue : gère la présentation des données
• Modèle : ressemble beaucoup à une couche d'accès aux données

Où va la logique métier ?

Prenons une grande application d'entreprise avec :

• Plusieurs sources de données différentes (WCF, WebServices et ADO) liées ensemble dans une couche d'accès aux données (utilisant différents DTO).
• Beaucoup de logique métier segmentée sur plusieurs DLL.

Quelle est la meilleure façon pour une application web MVC de se superposer à tout cela (en termes de structure de code et de projet) ?

Les exemples que j'ai vus où tout est placé dans le dossier Modèle ne semblent pas adaptés pour des applications très volumineuses.

Merci pour tout conseil !

Answer 1

Dans mes applications, je crée généralement un projet "Core" séparé du projet web.

Le projet Core contient :

1. Les objets métier, tels que les entités, etc.
2. L'accès aux données
3. Tout ce qui n'est spécifiquement pas conçu pour le web

Le projet web contient :

1. Les contrôleurs, qui dirigent les requêtes de l'interface utilisateur vers la logique de base
2. Les vues, qui se concentrent sur la présentation des données en HTML
3. Les Modèles de vue, qui aplatissent/transforment les objets métier de base en structures plus simples conçues pour prendre en charge des vues spécifiques

Le point clé ici est que le dossier/namespace des modèles basés sur le web est uniquement utilisé pour des modèles spécifiques à la présentation qui documentent les variables spécifiques nécessaires pour une vue donnée. Autant que possible, la "logique métier" va dans le projet Core.

Answer 2

Le Modèle Vue Controller semble s'adresser à vos 3 niveaux, mais ce n'est pas le cas. Il organise vraiment la manière dont votre interface utilisateur est mise en place. Le Contrôleur est au milieu et typiquement (A) effectue des actions en utilisant des objets d'affaires et (B) à partir des objets d'affaires récupère les objets Modèle à transmettre à la Vue. La partie MVC de votre système (la fonctionnalité de l'interface utilisateur) ne sait pas ce qui se passe de l'autre côté de la couche métier. Base de données? Appels de services? E/S disque? Tirs de lasers? Ainsi, MVC-B-? serait un acronyme qui décrit MVC et comment cela se connecte.

Pensez au Controleur au centre, avec une ligne qui va vers le bas vers les objets d'affaires. Le contrôleur récupérera généralement le Modèle des objets affaires pour le transmettre à la Vue, mais le Modèle n'est que des données. C'est essentiel. Le Controleur est maintenant la partie la plus intelligente du système dans un sens, mais les objets d'affaires restent les plus puissants.

Ainsi, les objets Modèle sont une grande partie de la communication entre le Controleur et les objets d'affaires. De plus, chaque vue a un VM (Vue Modèle) objet qu'elle prend, qui pourrait être un Modèle, mais pourrait être quelque chose construit par le Controleur pour transmettre des ensembles d'informations plus complexes à la Vue.

Ainsi, un contrôleur (1) prend des données du client et fait des actions avec les objets affaires (si nécessaire), communiquant peut-être en utilisant des objets Modèle, puis (2) obtient des objets Modèle auprès d'objets d'affaires, construit un VM et le donne à une vue (éventuellement plusieurs) pour être rendu.

Au début, cela semblera vraiment être des couches et niveaux partout, surtout parce que se plonger dans le MVC est un bon moment pour augmenter votre utilisation des interfaces (voir les 3 ou 4 principes SOLID) et le test unitaire. Vous aurez probablement beaucoup plus de fichiers dans votre projet que vous en auriez autrement. Très rapidement cependant, vous verrez que c'est en fait une excellente façon d'organiser les choses.

En tant que partie "sommet" du système, la partie MVC, nous nous soucions simplement de la manière dont les objets Modèle ont été construits ou de ce que les objets d'affaires en font. Ne soyez pas surpris bien sûr si votre objet Client modèle ressemble beaucoup à votre table de base de données pour les Clients! C'est normal et courant. Cependant, votre objet Modèle client et votre objet d'affaires client auront vraiment des vies distinctes. C'est un bon moment pour envisager le Modèle de Référentiel.

Résistez à la tentation d'être paresseux et de mettre beaucoup de logique dans le Controleur. Efforcez-vous à chaque instant de placer les préoccupations là où elles appartiennent. Le Controleur sert simplement à connecter les choses. S'il y a beaucoup de code nécessaire là pour construire un VM adéquat pour que la vue l'utilise, c'est normal, car c'est le travail des contrôleurs. Trop souvent, on voit de la logique métier ou de rendu dans le contrôleur. Mettez-la là où elle doit être!

J'ai essayé de trouver un équilibre entre l'exhaustivité et la concision, mais vous avez posé une énorme question!

Answer 3

Le MVC n'est pas une architecture complète pour vos besoins, il ne couvre que la couche de présentation. Vos contrôleurs devraient communiquer avec une couche métier et récupérer des objets Modèle. La couche métier peut communiquer avec d'autres couches, comme l'accès à la base de données, les services web, le système de fichiers, etc.

Answer 4

Je tends à mettre ma logique métier dans des services, et les appeler depuis le contrôleur, qui collecte les données et les envoie au service approprié.

Pour avoir une application MVC reposant sur cela, j'utiliserais un patron de façade ou quelque chose de similaire, pour rediriger les appels vers votre logique métier existante. Ainsi, vos services sont essentiellement des façades passant simplement les données à la logique métier existante.

De cette façon, il y a une rupture nette entre la logique métier existante et votre nouveau code basé sur le MVC.

Answer 5

"Ça dépend" :)

Les demandes sont routées vers des contrôleurs, qui les gèrent de manière appropriée. Les contrôleurs sont la "colle" qui maintient tout le reste (Modèles, Vues, etc) ensemble. Il est donc naturel que la "logique métier" soit soit traitée directement, soit déchargée vers un autre composant par un contrôleur.

Où vous placez réellement la logique dépend de vos besoins. Si la logique n'est nécessaire que par un seul contrôleur, la placer directement à l'intérieur est correct. Bien sûr, la logique peut également être placée dans un seul modèle si elle est nécessaire pour la cohérence des données.

Alternativement, vous pouvez placer la logique dans des classes/fonctions d'aide, ou (comme d'autres l'ont mentionné), vous pouvez créer une couche de services pour la logique métier.