ASP.NET MVC Business Logic dans le modèle de domaine contre la couche de service
Je lis depuis un moment où placer la logique métier dans ASP.NET MVC Project et je ne parviens toujours pas à comprendre certaines choses.
1 - Modèles de domaine . Quels sont-ils vraiment? Dans mon dossier Model, je n'ai qu'un tas de classes correspondant à ma base de données. J'utilise d'abord le code EF. 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 cela est parfaitement logique. J'avais décidé d'aller avec celui-ci. Cependant, "Les modèles de domaines anémiques" de Martin Fowler l'article m'a dérangé.
Je ne sais pas vraiment comment ajouter de la logique à mes modèles de domaine.
J'ai parcouru de nombreuses questions liées à la logique métier et chacune d'elles propose 1 ou 2. Ce que je ne comprends pas, c'est comment mettre en œuvre la première. L'ajout de méthodes aux classes d'entité (modèles de domaine pour moi) n'a aucun sens. Et pourquoi la deuxième approche est-elle considérée comme mauvaise?
Tout d'abord, votre dossier Model dans votre projet Asp.Net MVC doit être utilisé pour ViewModels. Ce sont les modèles que vos contrôleurs envoient à vos vues. Ils doivent être hautement optimisés pour la vue, ce qui signifie uniquement les propriétés nécessaires à la vue, et rien d'autre.
Ce que vous envisagez, les modèles de domaine, sont les mêmes que les modèles commerciaux et appartiennent à votre couche métier. Le dossier Model de votre projet Asp.Net MVC sont les modèles de votre couche UI.
La deuxième approche, la logique métier dans votre couche de service (vraiment métier) n'est pas considérée comme mauvaise. C'est un tampon très agréable entre votre couche de données et votre couche d'interface utilisateur (architecture à 3 niveaux). Votre couche de données gère l'obtention de données, à partir de services Web ou d'une base de données, et votre couche entreprise/service gère la traduction de ces données en modèles d'entreprise/de domaine. Il contient également toute logique métier, comme les calculs, etc.
Ces modèles d'entreprise/de domaine sont généralement des POCO, mais ils ne doivent pas l'être. C'est ainsi que je mets parfois en place mes business models:
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 métier dans les modèles de domaine. Je garde mes modèles de domaine généralement sous forme de POCO pour représenter mes tables/schémas DB.
Éloigner la logique métier des modèles de domaine me permettra également de réutiliser mon modèle de domaine avec un autre projet.
Vous pouvez envisager une couche intermédiaire entre vos contrôleurs et votre couche d'accès aux données/couche de référentiel pour gérer cela. J'appellerais cela une couche de service.
Je sais que cela a déjà été répondu, mais je classe les modèles en 3 groupes
ViewModels - Ce sont des classes légères (souvent poco) qui modélisent les données nécessaires à une page de votre site. Ces classes gèrent le passe-partout banal de ce qui est affiché à l'utilisateur et change lorsque les données que vous souhaitez afficher changent.
DomainModels - Ce sont normalement des classes de logique métier lourdes. Ils modélisent normalement les règles métier de base pour ce que vous faites. Ces classes sont souvent très cohérentes et sont le lieu 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 votre projet consiste à prendre ces données de l'utilisateur et à les coller dans la base de données, cette classe va être une petite classe de mappage de données. Plusieurs fois, vous verrez ces classes composées de modèles de persistance et de modèles de vue de retour.
PersistenceModels - Ce sont des modèles de votre mécanisme de persistance. Pour la plupart d'entre nous, cela signifie modéliser une table de base de données, mais cela pourrait également être un document nosql complexe ou des données json (ou autre) renvoyées par une demande d'API. Leur responsabilité est de gérer la plaque de chaudière banale de la forme que prennent vos données externes.
Gardez également à 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 pour ligne ce que vous êtes un modèle de persistance. Dans ce cas, vous gaspillez l'argent de vos clients pour écrire le tout deux fois et ajouter un modèle de domaine pour mapper l'un à l'autre. Vous êtes le développeur et c'est votre travail de savoir quand construire un porte-avions pour aller au magasin pour l'épicerie.
Les modèles de domaine doivent être en mesure d'effectuer leur travail par eux-mêmes et d'exposer des propriétés et des méthodes qui représentent leur état et leurs fonctions. Ils agissent comme des racines (racines agrégées) d'une hiérarchie d'informations dont les modèles ont besoin pour fonctionner. Ils restent cachés uniquement disponibles pour les services.
Les services exposent les fonctionnalités de l'entreprise/du domaine au monde extérieur (services Web, interface utilisateur, etc.) sous la forme d'un ensemble d'API suivant le modèle de message (demandes/réponses), en récupérant les modèles des référentiels qui encapsulent la couche d'accès aux données, puis en appelant les méthodes/l'entreprise fonctions sur les modèles et enfin les sauvegarder dans les référentiels.
Parfois, il semble que les services répètent des méthodes d'objets métier, mais en temps et en pratique, ce n'est pas ce qui se passe vraiment.
Dans une conception orientée domaine réel, vous avez besoin d'au moins 3 ensembles d'objets. Objets métier, référentiels d'objets métier et services.
Pensez comme si votre exigence était toujours que chaque type de composant soit é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 n'ait à écrire la logique sur le service lui-même. Le service pourrait alors être consommé par toute personne qui en aurait besoin sans avoir à creuser dans le modèle de base lui-même.