DDD et MVC : différence entre "modèle" et "entité".

Question

Je suis très confus quant au 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 la base de données. Le concept de 'Fat Model Skinny Controller' est perdu lorsque le contrôleur commence à faire de plus en plus de logique.

Dans DDD, il existe également le concept d'entité de domaine, qui possède une identité unique. Si j'ai bien compris, un utilisateur est un bon exemple d'Entité (userid unique, par exemple). L'entité a un cycle de vie - ses valeurs peuvent changer au cours de l'action - puis elle est sauvegardée ou éliminée.

L'entité que je décris ci-dessus est ce que je pensais que le modèle était censé être dans MVC ? A quel point suis-je à côté de la plaque ?

Pour encombrer davantage les choses, vous ajoutez d'autres patterns, comme le pattern Repository (en y ajoutant peut-être un Service). La manière dont le Repository interagit avec une Entity est assez claire, mais comment le fait-il avec un Model ?

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.

UPDATE : Dans ce poste le modèle est décrit comme quelque chose ayant des connaissances, et il peut être singulier ou une collection d'objets. Il semble donc qu'une Entité et un Modèle soient plus ou moins identiques. Le Modèle est un terme englobant, alors qu'une Entité est plus spécifique. Un objet de valeur serait également un modèle. Au moins en termes de MVC. Peut-être ?

Alors, en termes très approximatifs, lequel est le meilleur ?

Pas de "Modèle" vraiment ...

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 contribution ?

Answer 1

Entité

Entity désigne un objet qui est un élément unique avec lequel la logique d'entreprise travaille, plus précisément ceux qui ont une identité quelconque.
C'est pourquoi de nombreuses personnes appellent les objets mappés par l'ORM des entités.

Certains parlent de " entité " à une classe dont l'instance représente une seule ligne dans une base de données.

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

Modèle

A Model est quelque chose qui n'est pas directement lié à l'IU (= View ) et le flux de contrôle (= Controller ) d'une application, mais plutôt sur la façon dont l'accès aux données et l'abstraction principale des données de l'application fonctionnent.

En fait, 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

• A Customer est une entité (en général), et vous l'utilisez également dans le cadre de l'accès aux données dans votre application. Dans ce cas, elle est à la fois une entité et un modèle.
• A Repository peut faire partie du modèle, mais elle n'est clairement pas une entité.
• Si vous utilisez une classe au milieu de votre couche logique mais que vous ne l'exposez pas au reste de l'application, il s'agit peut-être 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'abstraction des données d'une application, et non une classe dont le nom est suffixé par "Modèle". Beaucoup de gens considèrent cette dernière comme un bloatware.

Vous pouvez pratiquement 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 le fait qu'il est également plus facile de travailler avec le premier, et pour les autres personnes qui devront peut-être comprendre votre code plus tard, il est plus facile à comprendre.

Answer 2

Toutes les réponses sont un amalgame de différentes choses et sont 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 plus ni moins. Il n'a rien à voir avec les données, les objets ou quoi que ce soit d'autre. Il s'agit simplement du concept d'une partie de domaine. Et dans chaque domaine complexe il y a toujours plus d'un modèle, par exemple le commerce, la facturation, la 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. Il donne une illusion d'objets en mémoire et est responsable de l'extraction de des agrégats (pas des entités !) de n'importe où et de les sauvegarder c'est-à-dire de maintenir le cycle de vie des objets.

Si vous parlez de concepts DDD, commencez par corriger vos connaissances en lisant les bases. Comme ici ThinkDDD .

Answer 3

Le "modèle" de votre application est l'élément qui contient vos données. L'"entité" dans la conception pilotée par le domaine est, si je me souviens bien, un modèle avec une identité. En d'autres termes, 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 étant la valeur, qui est juste un modèle sans identité.

Le modèle de référentiel est juste un type de collection indexée de modèles/entités. Ainsi, par exemple, si votre code veut la commande n°13, il va d'abord la demander au référentiel, et s'il ne peut pas l'obtenir de là, il ira la chercher ailleurs. C'est essentiellement un cache de niveau 1 si vous voulez. Il n'y a pas de différence entre la façon dont il agit avec un modèle et la façon dont il agit avec une entité, mais puisque 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 référentiel.

Answer 4

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 de l'entité. Le modèle(objet) est une entité unique. Le service opère sur les 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 transforment les modèles en couches de persistance (par exemple, bases de données, backends tiers, etc.).

Answer 5

Bien que cet article porte spécifiquement sur Ruby on Rails, les mêmes principes et informations s'appliquent puisque la discussion porte sur MVC et DDD.

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