Entité vs modèle vs voir modèle
Je viens de passer un peu de temps à lire à propos de ces termes (je ne les utilise pas beaucoup car nous n'avons pas d'applications MVC et je dis généralement "modèle"), mais j'ai le sentiment que cela signifie des choses différentes selon le contexte :
Entité
C'est assez simple, c'est une ligne dans la base de données:
2) Par rapport à une base de données, une entité est une personne, un lieu ou une chose unique sur laquelle les données peuvent être stockées.
Modèle
Je lis souvent, il s'agit essentiellement d'une combimation d'entités pour représenter un ensemble complet de données, disons qu'un modèle de liste d'adresses d'un client combinerait les entités client, adresse et probablement individuel.
Viewmodel
Un terme dans les modèles MVVM ou MVC, qui est un modèle, qui représente exactement les données que vous pouvez voir sur la vue. Le modèle de vue est au niveau de l'application et possède des attributs pour la validation, par exemple. ASP.NET MVC Model vs ViewModel
De mon point de vue, ces termes semblent tous un peu redondants: le Viewmodel a évidemment son utilité, sinon la vue devrait faire tout le travail pour montrer les bonnes choses. L'entité n'est que la représentation, comme nous le savons par l'EF, mais si vous combinez ces deux, où a le modèle son utilisation?
Des choses comme la validation, la sécurité, etc. doivent être effectuées sur le ViewModel. Souhaitez-vous utiliser le modèle lorsque vous avez des centaines de petites tables pour mettre une autre abstraction entre les entités et le modèle d'affichage? Ou, en termes d'entités et de modèles MVC et MVVM, sont-ils généralement les mêmes?
Comme d'habitude merci et bon week-end
Matthias
Différentes personnes comprennent ces termes un peu différemment, mais voici comment je les comprends:
Entité - objet qui a une identité (ID), provient généralement d'une base de données. Classe assez simple.
Modèle - tout objet commercial, c'est un terme un peu large. Il peut s'agir d'une entité, d'une classe personnalisée que vous avez créée dans votre projet, etc. C'est à peu près tout ce qui n'est pas une vue ni un contrôleur/modèle de vue.
ViewModel - une sorte de médiateur entre un modèle et la vue. Il module la communication entre le modèle et la vue, applique par exemple la validation, combine plusieurs modèles en un objet plus grand, etc., aux fins de l'interaction avec la vue spécifique. ViewModel est également responsable de la gestion des événements (clics de souris par exemple), il expose donc les commandes à la vue à laquelle vous vous associez (WPF).
Le terme "modèle" est ambigu. Ce sont tous des modèles.
Modèle d'entité
Une classe qui ressemble étroitement à la structure en persistance. A MemberEntity est un modèle qui représente une ligne de membre dans la table Members d'une base de données. Pas strictement lié à une base de données, mais une entité d'une certaine persistance. A généralement une propriété "ID" telle que "int MemberID".
ViewModel
Une classe qui ressemble étroitement à la structure d'une vue/interface utilisateur. Un MemberViewModel est un modèle qui représente un membre à afficher sur une vue/interface utilisateur sur le frontend d'une application. Pas strictement lié au modèle MV *.
Remarquer
... que les deux modèles ci-dessus représentent une communication sur les limites de l'application. C'est-à-dire, la frontière avant (point d'entrée) qui reçoit la communication (événements utilisateur et communication via protocole) pour initier les règles métier; Et la limite arrière qui prend les commandes des règles métier pour ouvrir la communication avec d'autres systèmes (tels que des bases de données ou d'autres points de terminaison).
Modèle de domaine
Une classe qui représente une partie du domaine problématique. Le MemberModel est responsable de sa création et de sa validation. Parce que les services acceptent et renvoient des modèles, les modèles sont responsables de leur propre logique métier qui valide leur construction et leur utilisation correctes. E.G .: A MemberModel devrait se casser si vous essayez de l'utiliser sans UserName.
Services de domaine
Les services de domaine prennent modèles d'entité et les transforment en modèles de domaine afin que lesdits services puissent fonctionner avec les modèles. Si une entité vient de la limite arrière et ne parvient pas à sérialiser ou à mapper dans un modèle de domaine, il y a un drapeau rouge indiquant que les données sont mauvaises.
Les services de domaine prennent Modèles de domaine et les mappent à Entités afin de les envoyer hors de la limite arrière. Si la limite arrière (DB/SDK?) Ne parvient pas à accepter le modèle, le DB/SDK doit être corrigé.
- Remarque: les entités sont conformes aux modèles car la persistance est un détail. Le domaine est le roi d'un système, pas le matériel ou la structure de table de la persistance. Le domaine n'a jamais tort.
Front-Boundaries prend ViewModels et les transforme en Modèles de domaine afin qu'ils puissent être passés dans le domaine. Si un ViewModel ne parvient pas à sérialiser ou à mapper dans un modèle de domaine, il y a un indicateur rouge que la vue/json/xml est mauvaise.
Les services de domaine renvoient modèles de domaine à la limite avant, qui sont ensuite mappés à ViewModels afin de communiquer à l'avant. Si la vue/l'interface utilisateur n'accepte pas le modèle, la vue doit être corrigée.
- Remarque: les ViewModels sont conformes aux modèles car les consommateurs sont un détail. Le domaine est le roi d'un système, pas les interfaces utilisateur ou les sous-applications qui les consomment. Le domaine n'a jamais tort.
n ViewModel ne connaît JAMAIS une entité car une interface utilisateur/un consommateur ne sait jamais que la persistance existe même.
Core Business-Logic ne doit pas connaître les ViewModels ou les entités. Core Business-Logic fonctionne uniquement avec les modèles de domaine. C'est pourquoi il existe des contrôleurs et des services frontaux à proximité; Pour mapper des modèles de domaine <=> ViewModels. C'est aussi pourquoi les SDK et les services backend à proximité existent; Pour mapper les entités DomainModels <=>.
Lorsqu'un système est créé, le domaine et la logique métier sont créés en premier (espérons-le TDD). Ensuite, des adaptateurs sont placés sur le devant et le dos de la logique métier qui déterminent le mécanisme de livraison (frontend) et les dépendances (service/persistance) (backend). Mais ces frontends et ces backends pourraient être arrachés, et la logique métier de base existe toujours.
Version plus courte (TLDR;):
Entité: enregistrement de base de données.
Modèle de domaine: logique métier spécifique au modèle (Google "Value Object") pour représenter un objet dans le problème de domaine.
ViewModel: page (ou section) d'une vue.
Ma compréhension est que le modèle est une notion centrale ici, il reflète la compréhension du problème résolu. Les entités déterminent comment les objets du modèle seront stockés dans la base de données. Les Viewmodels déterminent quelle partie du modèle va être montrée à l'utilisateur final.
La définition de ces termes est assez ambiguë. Vous trouverez différentes définitions à différents endroits.
Entité : une entité représente une seule instance de votre objet de domaine enregistrée dans la base de données en tant qu'enregistrement. Il possède certains attributs que nous représentons sous forme de colonnes dans nos tableaux.
Modèle : Un modèle représente généralement un objet du monde réel lié au problème ou à l'espace de domaine. En programmation, nous créons des classes pour représenter des objets. Ces classes, appelées modèles, ont certaines propriétés et méthodes (définissant le comportement des objets).
ViewModel : Le terme ViewModel provient du [~ # ~] mvvm [~ # ~] (Model View ViewModel) modèle de conception. Il existe des cas où les données à restituer par la vue proviennent de deux objets différents. Dans de tels scénarios, nous créons une classe de modèle qui comprend toutes les propriétés requises par la vue. Ce n'est pas un modèle de domaine mais un ViewModel car une vue spécifique l'utilise. En outre, il ne représente pas un objet du monde réel.
Pour plus de détails, visitez mon article de blog: Entity vs Model vs ViewModel vs DataModel