web-dev-qa-db-fra.com

DDD et MVC: différence entre 'Model' et 'Entity'

Je suis sérieusement confus au sujet du concept de "modèle" dans MVC. La plupart des frameworks qui existent aujourd'hui placent le modèle entre le contrôleur et la base de données, et le modèle agit presque comme une couche d'abstraction de base de données. Le concept de 'Fat Model Skinny Controller' est perdu à mesure que le contrôleur commence à faire de plus en plus de logique.

Dans DDD, il y a aussi le concept d'entité de domaine, qui a une identité unique. Si je comprends bien, un utilisateur est un bon exemple d'entité (userid unique, par exemple). L'entité a un cycle de vie - ses valeurs peuvent changer tout au long de l'action - puis elle est enregistrée ou supprimée.

L'entité que je décris ci-dessus est ce que je pensais que Model était censé être dans MVC? À quel point suis-je hors de la base?

Pour encombrer davantage les choses, vous ajoutez d'autres modèles, tels que le modèle de référentiel (peut-être en y mettant un service). Il est assez clair comment le référentiel interagirait avec une entité - comment le fait-il avec un modèle?

Les contrôleurs peuvent avoir plusieurs modèles, ce qui donne l'impression qu'un modèle est moins une "table de base de données" qu'une entité unique.

MISE À JOUR: Dans ce post le modèle est décrit comme quelque chose avec des connaissances, et il peut être singulier ou une collection d'objets. Donc, cela ressemble plus à une entité et un modèle sont plus ou moins identiques. Le modèle est un terme global, où une entité est plus spécifique. Un objet de valeur serait également un modèle. Au moins en termes de MVC. Peut être???

Donc, en termes très approximatifs, quel est le meilleur?

Pas vraiment de "modèle" ...

class MyController {
    public function index() {
        $repo = new PostRepository();
        $posts = $repo->findAllByDateRange('within 30 days');
        foreach($posts as $post) {
            echo $post->Author;
        }
    }
}

Ou ceci, qui a un modèle comme DAO?

class MyController {
    public function index() {
        $model = new PostModel();
        // maybe this returns a PostRepository?
        $posts = $model->findAllByDateRange('within 30 days');
        while($posts->getNext()) {
            echo $posts->Post->Author;
        }
    }
}

Ces deux exemples n'ont même pas fait ce que je décrivais ci-dessus. Je suis clairement perdu. Une entrée?

phpmodel-view-controllermodeldomain-driven-designentity
55
Nathan Loding

Entité

Entity signifie un objet qui est un élément unique avec lequel la logique métier fonctionne, plus spécifiquement ceux qui ont une identité quelconque.
Ainsi, de nombreuses personnes se réfèrent aux objets mappés ORM comme des entités.

Certains font référence à " entité " à une classe dont une instance représente une seule ligne dans une base de données.

D'autres personnes préfèrent appeler uniquement celles de ces classes comme "entité" qui contiennent également des règles métier, la validation et le comportement général, et elles appellent les autres comme " objets de transfert de données ".

Modèle

Un Model est quelque chose qui n'est pas directement lié à l'interface utilisateur (= View) et au flux de contrôle (= Controller) d'une application, mais plutôt à la manière dont les données accèdent et l'abstraction des données principales de l'application fonctionne.

Fondamentalement, tout peut être un modèle qui correspond à ce qui précède.

MVC

Vous pouvez utiliser des entités comme modèles dans MVC. Ils signifient deux choses différentes, mais les mêmes classes peuvent être appelées les deux.

Exemples

  • Une classe Customer est vraiment une entité (généralement), et vous l'utilisez également dans le cadre de l'accès aux données dans votre application. C'est à la fois une entité et un modèle dans ce cas.
  • Une classe Repository peut faire partie du modèle, mais ce n'est clairement pas une entité.
  • S'il existe une classe que vous utilisez au milieu de votre couche de logique métier mais que vous ne l'exposez pas au reste de l'application, il peut s'agir d'une entité, mais ce n'est clairement pas un modèle du point de vue de l'application MVC.

Votre exemple

Quant à vos exemples de code, je préférerais le premier.
Un modèle est une classe qui est utilisée comme moyen d'abstaction des données d'une application, et non une classe dont le nom est suffixé par "Modèle". Beaucoup de gens considèrent ce dernier bloatware.

Vous pouvez à peu près considérer votre classe Repository comme faisant partie de votre modèle, même si son nom n'est pas suffixé par "Model".

J'ajouterais à cela qu'il est également plus facile de travailler avec le premier, et pour d'autres personnes qui devront peut-être comprendre plus tard votre code, c'est plus facile à comprendre.

46
Venemo

Toutes les réponses sont un mélange de choses différentes et tout simplement fausses.

Un modèle dans DDD ressemble beaucoup à un modèle dans le monde réel: une simplification et une abstraction de quelque chose. Ni moins ni plus. Cela n'a rien à voir avec des données, des objets ou quoi que ce soit d'autre. C'est simplement le concept d'une partie de domaine. Et dans chaque domaine complexe, il y a toujours plus d'un modèle, par ex. Commerce, facturation, logistique.

Une entité n'est pas un "modèle avec identité" mais simplement un objet avec identité.

Un référentiel n'est pas seulement un cache de 1er niveau mais aussi une partie du domaine. Cela donne une illusion d'objets en mémoire et est responsable de la récupération des agrégats (pas des entités!) De n'importe où et de leur sauvegarde, c'est-à-dire en maintenant le cycle de vie des objets.

Si vous parlez de concepts DDD, corrigez d'abord vos connaissances en lisant les bases. Comme ici ThinkDDD .

10
Don Zampano

Le "modèle" de votre application est le bit qui contient vos données. L '"entité" dans la conception axée sur le domaine est, si je me souviens bien, un modèle avec une identité. C'est-à-dire qu'une entité est un modèle qui correspond généralement directement à un élément "physique" dans une base de données ou un fichier. Je crois que DDD définit deux types de modèles, l'un étant l'entité, l'autre la valeur, qui n'est qu'un modèle sans identité.

Le modèle Repository est simplement un type de collection indexée de modèles/entités. Ainsi, par exemple, si votre code veut la commande n ° 13, il le demandera d'abord au référentiel, et s'il ne peut pas l'obtenir à partir de là, il ira le chercher de n'importe où. C'est essentiellement un cache de niveau 1 si vous voulez. Il n'y a pas de différence dans la façon dont il agit avec un modèle, et comment il agit avec une entité, mais comme l'idée d'un référentiel est de pouvoir récupérer des modèles en utilisant leurs ID, en termes de DDD, seules les entités seraient autorisées dans le dépôt.

6
KennethJ

alors qu'il s'agit spécifiquement de Ruby sur Rails, les mêmes principes et informations s'appliquent toujours puisque la discussion porte sur MVC et DDD.

http://blog.scottbellware.com/2010/06/no-domain-driven-design-in-Rails.html

1
Derick Bailey

Une solution simple utilisant le service et la collecte:

<?php
class MyController {
    public function index() {
        $postService = ServiceContainer::get('Post');
        $postCollection = $postService->findAllByDateRange('within 30 days');
        while($postCollection->getNext()) {
            echo $postCollection->current()->getAuthor();
        }
    }
}

EDIT: Le modèle (classe) est la représentation simple du schéma d'entité. Le modèle (objet) est une seule entité. Le service fonctionne sur des modèles et fournit des données concrètes au contrôleur s. Aucun contrôleur n'a de modèle. Les modèles sont autonomes.
De l'autre "côté", les mappeurs mappent les modèles en couches de persistance (par exemple: bases de données, backends tiers, etc.).

1
erenon