web-dev-qa-db-fra.com

Quelle est la différence entre les objets de domaine, les POCO et les entités?

J'avais l'impression qu'ils sont tous fondamentalement les mêmes. Les objets du modèle sont-ils également les mêmes?

En ce moment, dans mon architecture, j'ai:

class Person 
{

    public string PersonId;        
    public string Name;
    public string Email;

    public static bool IsValidName() { /* logic here */ }
    public static bool IsValidEmail() { /* logic here */ }
}


class PersonService
{
    private PersonRepository pRepository;

    PersonService()
    {
        pRepository = new PersonRepository();
    }

    public bool IsExistingEmail(string email)
    {
        //calls repo method to see if email is in db
    }


    public Person GetPerson(email)
    {
        return pRepository.Get(email);
    }


    public void SavePerson(Person p)
    {
        if (Person.IsValidEmail(p.Email) && !IsExistingEmail(p.Email)
        {
            pRepository.Save(p);
        }
    }

}


class PersonRepository
{
    public void Save(Person p)
    {
        //save to db
    }

    public Person Get(string email)
    {
        //get from db
    }

    public bool IsExistingEmail(string email)
    {
        //see if email in db
    }

}

Alors, laquelle des classes ci-dessus sont POCO, Domain Object, Model object, entity?

c#asp.netarchitecturedomain-driven-design
72
jpshook

Mes définitions Layman (non standard)

  • POCO - Plain Old% Insert_Your_Language% Object. Un type sans logique. Il stocke simplement des données en mémoire. Vous y voyez généralement uniquement des propriétés automatiques, parfois des champs et des constructeurs.
  • Domain object une instance d'une classe liée à votre domaine. J'exclurais probablement tous les objets satellites ou utilitaires de l'objet domaine, par exemple dans la plupart des cas, les objets de domaine n'incluent pas des éléments tels que la journalisation, le formatage, la sérialisation, le chiffrement, etc. - sauf si vous créez spécifiquement un produit pour journaliser, sérialiser, formater ou chiffrer respectivement.
  • Model object Je pense que c'est la même chose que Domain object. Les gens ont tendance à utiliser cela de manière interchangeable (je peux me tromper)
  • Entity une classe qui a id
  • Repository une classe qui parle d'un stockage de données d'un côté (par exemple une base de données, un service de données ou ORM) et au service, à l'interface utilisateur, à la couche de gestion ou à tout autre organisme demandeur. Il cache généralement tous les éléments liés aux données (comme la réplication, le regroupement de connexions, les contraintes clés, les transactions, etc.) et simplifie le travail avec les données
  • Service logiciel qui fournit certaines fonctionnalités généralement via une API publique. Selon la couche, il peut s'agir, par exemple, d'un conteneur autonome RESTful ou d'une classe qui vous permet de trouver une instance particulière du type requis.

Réponse originale

Ce sont termes qui sont largement utilisés dans la conception pilotée par domaine (distribuée). Ils ne sont pas les mêmes. Le terme objet modèle peut être utilisé comme synonyme de objet domaine.

Objets de domaine. Objets du domaine spécifique à l'entreprise qui représentent quelque chose de significatif pour l'expert du domaine. Les objets de domaine sont principalement représentés par des entités et des objets de valeur. De manière générale, la plupart des objets qui vivent dans la couche de domaine contribuent au modèle et sont des objets de domaine.

Entité. Un objet fondamentalement défini non pas par ses attributs, mais par un fil de continuité et d'identité. (ce qui signifie doit avoir Id )

POCO. Un objet simple sans logique compliquée, généralement il n'a que quelques propriétés et est utilisé avec ORM ou comme objet de transfert de données

class Person - Entité et POCO, l'instance de cette classe est un objet de domaine
class PersonService - Un service
class PersonRepository - Référentiel

92
oleksii

C'est plus une connotation de fonction; un objet de domaine est quelque chose de spécifique à votre implémentation logique et peut être plus complexe qu'un simple POCO; une entité a une connotation pour représenter quelque chose (généralement en référence à un support de persistance), et un POCO est juste un identifiant rapide pour une classe. Un modèle n'est qu'un terme utilisé pour représenter un objet (contenant généralement un état et traitant généralement de l'interface utilisateur ou de la base de données).

Ce n'est pas qu'il y ait une différence fonctionnelle, ce sont juste des termes différents pour décrire plus précisément quelque chose. Comme la différence entre une voiture de course, un camion et une berline familiale. Tous sont des automobiles, mais chaque terme est plus descriptif.

18
Tejs

en gros, cela revient à la logique interne

  1. Les objets de domaine ont des choses de logique de domaine interne comme la validation, etc.
  2. Le modèle est essentiellement un objet de domaine léger, ils connaissent les données qu'ils contiennent mais rien vraiment sur la façon dont il va être utilisé
  3. Les entités détiennent des données et ont une connaissance interne de leur provenance et de l'endroit où elles seront enregistrées, mises à jour, etc.
  4. POCO détient des données et peut avoir des connaissances internes sur lui-même, des choses comme quelle est la valeur totale de tous les éléments d'une collection de propriétés
  5. Le DTO est l'élément le plus simple de tous, il ne contient que des données et n'a aucune logique

Ils sont tous essentiellement utilisés pour la même chose, c'est juste à quel point vous voulez qu'ils soient intelligents

selon votre exemple de code La classe Person serait un objet de domaine ou un modèle, les 2 autres étant un service et un référentiel. Les objets de domaine, Pocos, modèles, dtos, etc. sont utilisés comme des messages passent d'une couche à la suivante, une classe de service comme PersonService est une couche dans l'application et la même chose avec la classe Repository comme PersonRepository. pour une bonne vue d'ensemble, regardez http://bob-the-janitor.blogspot.com/2009/07/n-tier-design-revisit-part-1-over-view.html dans ce cas, il s'agit d'utiliser une entité de données qui est essentiellement un dto

15
Bob The Janitor

Il y a déjà de bonnes explications sur le domaine et le modèle dans les réponses ci-dessus.

Dans une entité de contexte de base de données signifie un élément dans un ERD de modèle de relation d'entité . (c'est-à-dire une ligne dans un tableau)

Dans le Microsoft-Dotnet-EntityFramework-World Entité signifie un objet qui peut être chargé et enregistré dans une base de données en utilisant un contexte de données (de base). Habituellement, une entité ne peut exister sans son contexte de données (de base). (Unit-) Il est difficile de tester la fonctionnalité commerciale de ces classes.

Pocos (Plain Old CommonRuntime Objects) peut exister sans PersistenceFramework (EntityFramework ou NHibernate) donc ils sont beaucoup plus faciles à tester.

Le Word poco est l'adaptation de pojo (plain old Java object) qui ont été créés dans le monde Java pour la même raison) .

11
k3b

Juste une astuce design.

Au lieu d'utilisation:

class PersonService
{
    private PersonRepository pRepository;

    PersonService()
    {
        pRepository = new PersonRepository();
    }
}

Utilisation:

class PersonService
{
    private PersonRepository pRepository;

    PersonService(PersonRepository pRepository)
    {
        this.pRepository = pRepository;
    }
}

Pour fournir une injection de dépendance à PersonService.

5
Vinicius Gonçalves

Un objet de domaine est une entité dans la couche de domaine de votre application, par exemple. une classe d'adresse. "Modèle" signifie la même chose - une entité dans le "Modèle de domaine".

Un POCO (plain old CLR object) est un objet qui n'a pas de comportement (méthodes) défini et qui ne contient que des données (propriétés). Les POCO sont généralement utilisés comme DTO (objets de transport de données) pour transporter des données entre les couches, et les données sont ensuite couramment utilisées pour remplir un objet/entité de domaine.

2
MattDavey