Quelle est la différence entre un modèle et une entité ?

Question

J'ai du mal à comprendre la signification de ces mots :

Entity , Model , DataModel , ViewModel

Quelqu'un peut-il m'aider à les comprendre ? Merci à tous.

Answer 1

La définition de ces termes est assez ambiguë. Vous trouverez des définitions différentes à différents endroits.

Entité : Une entité représente une instance unique de votre objet de domaine sauvegardée dans la base de données sous forme d'enregistrement. Elle possède certains attributs que nous représentons comme des colonnes dans nos tables.

Modèle : Un modèle représente généralement un objet du monde réel qui est lié au problème ou à l'espace de domaine. En programmation, nous créons des classes pour représenter les objets. Ces classes, appelées modèles, possèdent certaines propriétés et méthodes (définissant le comportement des objets).

ViewModel : Le terme ViewModel trouve son origine dans le programme MVVM (Model View ViewModel). Dans certains cas, les données à rendre par la vue proviennent de deux objets différents. Dans de tels scénarios, nous créons une classe modèle qui se compose de toutes les propriétés requises par la vue. Il ne s'agit pas d'un modèle de domaine mais d'un ViewModel parce qu'une vue spécifique l'utilise. De plus, il ne représente pas un objet du monde réel.

Modèle de données : Afin de résoudre un problème, les objets interagissent les uns avec les autres. Certains objets partagent une relation entre eux et, par conséquent, forment un modèle de données qui représente les objets et la relation entre eux.

Dans une application gérant les commandes des clients, par exemple, si nous avons un objet client et un objet commande, ces objets partagent une relation many to many entre eux. Le modèle de données dépend finalement de la manière dont nos objets interagissent entre eux. Dans une base de données, nous voyons le modèle de données comme un réseau de tables faisant référence à d'autres tables.

Pour en savoir plus sur les relations entre objets, consultez mon article de blog : Les bases des relations entre objets

Pour plus de détails, consultez mon article de blog : Entité vs Modèle vs ViewModel vs DataModel

Answer 2

J'espère que je n'ai pas manqué votre point ici, King.net...

Quoi qu'il en soit, je suppose que vous parlez de la modélisation des entités ou de la modélisation entité-relation (ERD) :

• une entité représente toute entité du monde réel - par exemple, un étudiant, un cours,
• une entité aura des attributs - par exemple, un étudiant a un prénom, un nom de famille et une date de naissance.
• une entité aura des relations - par exemple, un étudiant "est inscrit à" un cours (où l'étudiant et le cours sont des entités avec des attributs et "est inscrit à" est la relation).
• la relation peut être "un-à-un", "un-à-plusieurs" ou "plusieurs-à-plusieurs" - par exemple, un étudiant "est inscrit à" plusieurs cours et, de même, un cours "a" plusieurs étudiants.
• les relations ont également une cardinalité

L'ajout de relations entre les entités crée un "modèle de données". Vous avez modélisé un système du monde réel et les entités/objets internes de ce système. L'étape suivante consiste à le normaliser pour s'assurer qu'il respecte la "forme normale".

En termes d'ERD, vous pouvez avoir des modèles "logiques" et "physiques". Le modèle logique décrit le modèle de données en termes simples et de haut niveau, sans les détails techniques nécessaires à sa mise en œuvre. Il représente la vue d'ensemble de la solution du système. Le modèle physique comprend les détails techniques nécessaires à la mise en œuvre effective du système (par exemple, les "tables de jonction plusieurs à plusieurs" nécessaires à la mise en œuvre des relations "plusieurs à plusieurs").

Voici quelques tutoriels en ligne (mais je suis sûr qu'il doit y en avoir des milliers) :

• http://www.maakal.com/maakalDB/Database101ERDpart1.htm
• http://www.itteam-direct.com/gwentrel.htm
• http://www.bkent.net/Doc/simple5.htm

Je ne suis pas tout à fait sûr de ce que vous entendez par "modèle" et "modèle de vue" dans un contexte connexe. Je ne sais pas si vous ne confondez pas cela avec le paradigme Modèle-Vue-Contrôleur (MVC). Ici, un modèle est un composant de données et la vue représente un observateur de ces données (comme un tableau ou un composant d'interface utilisateur graphique). Il existe de nombreuses explications en ligne sur le concept de "modèle-vue-contrôleur" ou "MVC".

J'espère que cela vous aidera, Wayne

Answer 3

Entité :

Une entité est la représentation d'un élément du monde réel dans le cadre du mappage objet-relationnel (ORM) comme l'Entity Framework. Cette représentation sera mappée sur une table dans une base de données et ses attributs seront transformés en colonnes. Une entité est écrite en utilisant une classe POCO qui est une classe simple, comme vous pouvez le voir dans l'exemple suivant en C# :

using System;
using System.Collections.Generic;
using System.Text;

namespace MyAplication.Entity
{
    public class Person
    {
        public long PersonId { get; set; }
        public string Name { get; set; }
        public short Age { get; set; }
    }
}

Travailler à la création d'une interface utilisateur est une tâche complexe. Pour garder les choses organisées, les programmeurs séparent leurs applications en couches.

Chaque couche est responsable d'une tâche, ce qui permet d'éviter le désordre dans le code. C'est dans ce scénario qu'apparaissent les modèles architecturaux comme le MVC et le MVVM.

Modèle :

Au sein du MVC, nous disposons d'une couche chargée de représenter les données précédemment stockées, une donnée pouvant être une instance d'une personne modélisée dans l'exemple précédent. Cette couche est le modèle. Ce modèle sera utilisé pour construire la vue.

ViewModel :

Un ViewModel dans l'architecture MVVM ressemble beaucoup à un modèle dans l'architecture MVC. Cependant, un ViewModel est une représentation simplifiée des données avec seulement les informations nécessaires à la construction d'une vue.

using System;
using System.Collections.Generic;
using System.Text;
using MyAplication.Web.ViewModel.BaseViewModel;

namespace MyAplication.Web.ViewModel.Person
{
    public class PersonNameViewModel : BaseViewModel<string>
    {
        //I just neet the name
        public string Name { get; set; }
    }
}

DataModel :

Il s'agit simplement d'un modèle abstrait (ce modèle est différent du modèle de la couche MVC) qui établit les relations qui existent entre les éléments qui représentent les entités du monde réel. Il s'agit d'un sujet très complet.

Answer 4

Tout d'abord, pour connaître l'entité, il faut connaître la classe. Toutes ces entités représentent les mêmes champs mais la terminologie change en fonction de la déclaration.

Considérons une table de n'importe quelle base de données [SQL,ORACLE,Informix,Cassandra..] comme exemple.

CLASSE :

En général, une table est considérée comme une classe jusqu'à ce qu'elle soit ajoutée à edmx ou dbmx.

 //Student class
        public class Student()
        {
        //Properties
        public int StudentNumber;
        public string StudentName;
        }

ENTITY :

• Après avoir glissé/déposé/ajouté la table dans le dbmx/edmx, elle est appelée Entité.

• Chaque Entité est générée à partir de sa classe correspondante et nous pouvons ajouter des attributs à l'entité qui sont utilisés pour effectuer des opérations à l'aide de la fonction
  linq ou entité.

DATAMODEL :

• Contient tous les champs de la table.

• DATAMODEL est une référence de classe directe à votre cshtml ou contrôleur où vous pouvez accéder aux attributs pour effectuer des opérations CRUD.

VIEWMODEL :

• Dans certaines situations, nous devons effectuer des opérations CRUD sur plus d'un modèle (table). plus d'un modèle (table).
• Nous combinons donc tous nos modèles requis dans une classe et nous les définissons dans son constructeur.

Exemple : Supposons que

//Student class
public class Student()
{
//Properties
public int StudentNumber;
public string StudentName;
}
//Marks Class
Public class Marks()
{
public int Maths;
public int Physics;
public int Chemistry;

//Now sometimes situations occur where we have to use one datamodel inside //other datamodel.
public Student StudentModel;
}

Answer 5

C'est simple :
DTO est l'abréviation de Data Transfer Object. Les DTO sont principalement utilisés pour le transfert de données entre services (services web, API, etc.) qui peuvent englober diverses propriétés de différentes entités (avec ou sans leur ID). Prenez cette ligne comme exemple de DTO : Considérons qu'un site Web d'achat va envoyer ses demandes d'expédition à une société de transport par un service Web. Son DTO serait quelque chose comme ceci : CustomerFullName , ShippingFee , ShippingAddress . Dans cet exemple CustomerFullName est une combinaison de propriétés FirstName + LastName pour le Customer entité, et ShippingFee est le résultat de plusieurs processus de destination, de taxation, etc. sur d'autres entités.

Au contraire, les entités sont un ensemble de propriétés rassemblées pour représenter une seule entité avec un ID spécifique (par ex, Teacher , Student , Employee etc.). En d'autres termes, les DTOs sont un tas de propriétés sans signification rassemblées pour être envoyées au client et un DTO n'a pas nécessairement de relation avec les autres DTOs, alors qu'une Entité inclut les propriétés d'un objet spécifique avec une relation significative avec les autres entités. Dans un paradigme de base de données relationnelle, nous pouvons considérer les DTO comme des lignes de vues tandis que les Entités sont des lignes de tables avec la clé primaire.

Cependant, le modèle est une combinaison de ces deux éléments. Un modèle peut contenir plusieurs entités connexes ainsi que des données supplémentaires pour traiter les problèmes d'application/UI du monde réel. Considérons un modèle nommé CustomerOrdersModel qui contient Customer Entité, List<Order> Entités, et un indicateur booléen supplémentaire PayWithCredit spécifiant si l'utilisateur va payer avec une carte de débit ou une carte de crédit.