ASP.NET logique opérationnelle du MVC dans le modèle de domaine par rapport à la couche de Service
j'ai lu sur où mettre la logique des affaires dans ASP.NET MVC projet pendant un certain temps et je ne peux toujours pas obtenir clair sur certaines choses.
1 - modèles de Domaine . Quelles sont-elles vraiment? Dans mon dossier Model, Je n'ai qu'un tas de classes correspondant à ma base de données. Je suis à l'aide de EF premier code. Je suppose que ce sont mes modèles de domaine.
2 - Couche De Service . Cette réponse suggère une couche de service et je pense que c'est parfaitement logique. J'avais décidé d'aller avec celui-ci. Cependant, l'article de Martin Fowler" anemic Domain Models " m'a embrouillé l'esprit.
Je ne sais pas vraiment comment ajouter de la logique à mes modèles de domaine.
j'ai passé en revue de nombreuses questions liées à la logique de l'entreprise et chacune d'entre elles propose soit 1 ou 2. Ce que je ne comprends pas, c'est comment mettre en œuvre le premier. Ajout de méthodes pour les classes d'entités (modèles de domaine pour moi) n'ont aucun sens. Et pourquoi la seconde approche est-elle considérée comme mauvaise?
5 réponses
tout d'abord, votre dossier modèle dans votre Asp.Net le projet MVC doit être utilisé pour les Modèles de vue. Ce sont les modèles que vos contrôleurs envoient à vos vues. Ils doivent être hautement optimisés pour la vue, ce qui signifie seulement les propriétés nécessaires pour la vue, et rien d'autre.
ce que vous prenez au sujet, les Modèles de domaine, sont les mêmes que les modèles D'affaires, et appartiennent à votre couche D'Affaires. Le dossier modèle dans votre Asp.Net MVC project sont les modèles de votre couche UI.
la deuxième approche, la logique d'affaires dans votre couche de service (vraiment d'affaires) n'est pas considérée comme mauvaise. C'est un très bon tampon entre votre couche de données et votre couche UI (architecture à 3 niveaux). Votre couche de données traite l'obtention de données, soit à partir de services web ou d'une base de données, et votre couche business/service traite la traduction de ces données en modèles business/domain. Il contient également toute logique commerciale, comme les calculs, etc.
Ces affaires/domaine les modèles sont généralement des POCOs, mais ils n'ont pas à l'être. C'est ainsi que je crée parfois mes modèles d'affaires:
public class BusinessObject
{
private DataObject _dataObject;
public BusinessObject(DataObject dataObject)
{
_dataObject = dataObject;
}
public int BusinessId
{
get {return _dataObject.Id;}
set {_dataObject.Id = value;}
}
public string Name
{
get {return _dataObject.Description;}
set {_dataObject.Description = value;}
}
}
je préfère ne pas avoir de logique d'affaires dans les modèles de domaine. Je garde mes modèles de domaine habituellement comme POCO pour représenter mes tables/schéma de base de données.
garder la logique de l'entreprise éloignée des modèles de domaine me permettra de réutiliser mon modèle de domaine avec un autre projet également.
vous pouvez envisager une couche intermédiaire entre vos contrôleurs et votre couche d'accès aux données/ couche Repository pour gérer cela. Je dirais que c'est une couche de service.
je sais que cela a déjà été répondu, mais je catégorise les modèles en 3 groupes
modèles de vue-Ce sont des classes de poids léger (souvent poco) qui modélisent les données nécessaires par une page sur votre site. Ces classes gèrent le boilerplate banal de ce qui est montré à l'utilisateur, et change lorsque les données que vous voulez afficher changent.
DomainModels - il s'agit normalement de classes logiques d'affaires lourdes. Ils modélisent normalement le noyau les règles d'affaires pour ce que vous faites. Ces cours sont souvent très cohésifs et sont l'endroit où la majorité du travail qui rend votre site spécial se produit. J'ai dit que ces modèles sont normalement lourds mais en réalité si tout ce que votre projet fait est de prendre ces données de l'utilisateur et de les coller dans la base de données, cette classe va être une petite classe de cartographie de données. Plusieurs fois vous verrez ces classes être composées de modèles de persistance et de modèles de retour de vue.
Modèles de persistance - ce sont des modèles de votre mécanisme de persistance. Pour la plupart d'entre nous, cela signifie la modélisation d'une table de base de données, mais pourrait aussi être un document nosql complexe ou des données json (ou autre) qui sont retournés à partir d'une demande api. Leur responsabilité est de gérer la banale chaudière de ce que prend la forme de vos données externes.
gardez aussi à l'esprit que vous n'avez pas toujours besoin d'avoir ces trois types de modèles présents dans votre projet. Parfois, votre modèle de vue sera ligne par ligne ce que vous êtes à la persistance du modèle est. Dans ce cas, vous gaspilleriez l'argent de vos clients pour tout écrire deux fois et Ajouter un modèle de domaine pour cartographier l'un à l'autre. Vous êtes le promoteur et c'est votre travail de savoir quand construire un porte-avions pour aller à l'épicerie.
devraient être capables d'effectuer leur travail de manière autonome et d'exposer les propriétés et les méthodes qui représentent leur état et leurs fonctions. Ils agissent comme des racines (des racines agrégées) à une hiérarchie de l'information qui est requise par les modèles pour fonctionner. Elles restent cachées uniquement pour les services.
Les Servicesexposent le monde extérieur (services web, interface utilisateur, etc.) à des fonctionnalités d'entreprise/domaine en tant qu'ensemble D'API suivant le modèle de message( requêtes / réponses), par extraire les modèles des dépôts qui encapsulent la couche d'accès aux données, appeler les méthodes/fonctions commerciales sur les modèles et finalement les sauvegarder dans les dépôts.
parfois, il semble que les services répètent des méthodes d'objets d'affaires, mais dans le temps et la pratique réelle, ce n'est pas ce qui se produit vraiment.
dans un véritable domaine de conception vous avez besoin d'au moins 3 ensembles d'objets. Les objets d'affaires, les dépôts d'objets D'affaires et Service.
pensez comme si votre exigence est toujours que chaque type de composant est écrit par des équipes différentes. Une équipe a besoin d'un service exposé sans connaître les détails et sans que l'autre ait à écrire la logique sur le service lui-même. Le service pourrait alors être consommé par toute personne qui en a besoin sans avoir à creuser dans le modèle de base lui-même.
flux d'Application de la logique de contrôle qui appartient à un contrôleur.
la logique D'accès aux données appartient à un dépôt.
La logique de Validationfait partie d'une couche de service.
une couche de service est une couche supplémentaire dans un ASP.NET application MVC qui assure la communication entre un contrôleur et une couche de dépôt.
la couche service contient la logique de validation des activités.
pour par exemple, une couche Service produit a une méthode CreateProduct ().
la méthode CreateProduct() appelle la méthode ValidateProduct() pour valider un nouveau produit avant de passer le produit au référentiel produit.
Source: http://www.asp.net/mvc/overview/older-versions-1/models-data/validating-with-a-service-layer-cs