Différenciation entre domaine, modèle et entité par rapport à MVC
Quelqu'un peut-il expliquer ces 3 concepts et les différences entre eux par rapport à un framework MVC avec un exemple. Pour moi, ceux-ci semblent presque équivalents, et il semble qu'ils soient utilisés de manière interchangeable dans certains articles et pas dans d'autres.
Les termes sont un peu vagues je suis d'accord. J'utiliserais domaine pour faire référence au domaine d'activité avec lequel vous traitez. Comme la banque ou l'assurance ou autre chose. Ensuite, vous avez des modèles de domaine. Ce sont les choses que vous traitez dans ce domaine commercial, comme pour domaine des opérations bancaires que vous avez des comptes, des clients, des transferts, etc. J'utiliserais le terme entité pour référencer la classe/POJO ou la version persistante/concrète d'un modèle.
Ce qui vous confond probablement ici, c'est que dans le terme MVC , le modèle est une chose concrète, mais il fait référence au modèle de données utilisé pour représenter une présentation dans une interface graphique Web, alors ne mélangez pas cela avec l'explication ci-dessus.
Les termes qui vous confondent sont: " objets de domaine ", "entités de domaine" et "objets de modèle". Bien qu'ils soient généralement utilisés de manière interchangeable, les entités de domaine et l'objet de modèle peuvent également être des instances du modèle enregistrement actif (essentiellement: des objets de domaine avec une logique de stockage ajoutée).
Dans un objet de domaine ordinaire, il n'y a pas de logique de stockage. Il est géré par mappeurs de données .
Le terme "objets de modèle" vient des livres de Fowler (lire PoEAA pour plus de détails), et, à mon humble avis, fait partie des confusions MVC, parce que le modèle entier est une couche d'application (MVC se compose de lui et couche de présentation), qui contient ces "objets de modèle", qui sont généralement traités par services (dans cette image, la couche de modèle est constituée de trois cercles concentriques).
Je préfère de loin utiliser le terme "objet de domaine" à la place.
Le terme "entité de domaine" (ou "objet d'entité") est généralement utilisé lorsque l'auteur implique que l'objet est une représentation directe d'une structure de stockage (le plus souvent - une table de base de données). Ce sont aussi presque toujours des implémentations d'enregistrement actif.
P.S.: dans certains articles, vous verrez également le terme "modèles" (pluriel). Il n'est généralement pas directement lié au modèle de conception MVC, car il parle d'une architecture de type Rails, où les "modèles" ne sont que des enregistrements actifs, qui sont directement exposés/créés par le contrôleur.
.. je ne sais pas si cela vous a plus dérouté
Pour mémoire. Dans un but pratique, le domaine et le modèle sont les mêmes, tandis que l'entité est également un domaine/objet qui serait utilisé pour le stockage dans la base de données.
Certaines personnes sont tentées de ré-expliquer ces sujets, mais aucun d'entre eux n'est Canon.
La différence est que, dans le monde de Java, le domaine est plus utilisé, tandis que dans le monde de C #, le modèle est utilisé (et MS encourage son utilisation) mais sa juste convention et vous pouvez utiliser les deux.
Dans le même concept, Value Object (VO) est utilisé par les gens de Java, tandis que DTO pour les gens de C # même lorsque les deux sont pratiquement les mêmes. Aussi POJO (Java) vs POCO (C #), Packages (Java) vs NameSpace (C #), Setter and Getter (Java) vs Encapsulation (C #)
Les domaines et les modèles sont des classes. La façon dont la classe est utilisée distingue si elle doit être classée et placée dans un dossier de domaine ou de modèle. Si la classe doit être utilisée UNIQUEMENT dans la vue, placez-la dans le dossier modèle. Si la classe est mappée à un objet de base de données, placez-le dans le dossier du domaine.
Vous pourriez dire qu'un domaine sont les classes pour les tables de base de données, les objets de service externes, etc. Donc, si vous développez un projet et créez un répertoire de domaine, vous y mettez les objets de base de données. Une classe comme celle-ci est une entité et peut être une classe client avec ses propriétés. Pourquoi est-ce une entité et non un POCO? C'est à cause de son utilisation. Le contenu de l'entité peut être lu/écrit dans la base de données. En raison de la considérer comme une entité, vous savez où vous pouvez l'utiliser. En sachant que vous savez que c'est une entité, vous ne le mettez pas en son nom. Maintenant pour le modèle. Si vous utilisez ce client, il peut y avoir des propriétés que vous ne souhaitez pas utiliser. Un client peut être une entité vraiment simple. Mais disons que vous en avez un complexe. Celui que vous lisez à partir d'un service Web avec autant de propriétés que vous n'utiliserez pas. Ensuite, vous pouvez lire cette entité (= peut parfaitement se faire avec la sérialisation) et utiliser cette entité pour en créer un modèle. Si cette entité est utilisée pour copier des données dans le modèle, nous parlons également d'un objet de transformation de données (DTO), parfois vous l'écrivez en tant que CustomerDTO. Pour copier les données de l'entité vers un modèle, vous pouvez utiliser les outils de mappage. Le nom de l'entité devient alors CustomerModel. Ensuite, vous utilisez l'extension Model car sinon vous ne saurez pas ce qui est quoi. Dans ce CustomerModel, il peut y avoir beaucoup d'autres propriétés. Certaines de ces propriétés peuvent être des propriétés de processus (elles ne doivent pas nécessairement provenir de l'entité Client). Le contenu de ces propriétés provient d'autres services. Un nom simple qui peut être créé à partir du client est Fullname, son composé de plusieurs propriétés du client. Remplir un CustomerModel peut donc être complexe. Nous pouvons mettre le code pour remplir le CustomerModel dans une soi-disant Factory et appeler ce CustomerFactory.