Est-ce une bonne idée d'ajouter ViewModel exactement comme Model

J'ai les couches suivantes dans ma solution:

1. App.Domain
2. App.Service
3. App.Core (vous appelez peut-être celui-ci App.DataLayer)
4. App.Web

Le modèle de conception de logiciel n'est pas ma question, j'ai le modèle suivant Domain

public class Foo {
    public int Id {get;set;}
    public int Name {get;set;}
    public int Value {get;set;}
}

Je veux utiliser ce modèle sur la vue (par exemple la page d'accueil) ET je veux utiliser Id, Name & Value, donc si je veux créer ViewModel, j'ajouterai ce qui suit:

public class FooViewModel {
    public int Id {get;set;}
    public int Name {get;set;}
    public int Value {get;set;}
}

Alors, c'est une bonne idée? ou simplement utiliser à la Fooplace de FooViewModel?

Cela peut ressembler à une violation de la règle DRY au départ, mais je dirais qu'un code "similaire, voire identique" n'est pas nécessairement une "répétition" s'il fait quelque chose de différent ou s'il peut changer indépendamment. Et dans le cas des modèles de vue, le code définit ce que le «client» voit, pas nécessairement les entités et les opérations dont parle l'entreprise. Ainsi, vous dévoilez souvent au client ou à l'interface des modèles qui sont en quelque sorte "incidemment identiques". Vous pouvez modifier les règles et conditions commerciales ou la terminologie de l'utilisateur final indépendamment les uns des autres.

Donc, je vous retourne la question. Si le domaine change, est-il acceptable pour les clients "version 1" de continuer à utiliser les anciennes interfaces? Révélerez-vous jamais des termes ou des opérations dans l'interface qui ne font pas partie des "règles métier de base"? Et vice versa?

Ce genre de questions à l'esprit, si la "fonction" de votre vue est strictement de révéler le modèle de domaine sous-jacent, oui, cela semble violer la règle DRY.

_{Gardez également à l'esprit que l'exposition d'une vue qui change plus naturellement avec les changements de modèle peut également être effectuée dans certaines langues avec des attributs de membre et une réflexion. (Ou avec moins de répétition par d'autres exploits d'intelligence ... Mais, "l'intelligence" échoue souvent à justifier la répétition qu'elle vous épargne.)}

J'aurais un modèle de vue qui contenait une seule propriété, une instance de Foo. De cette façon, vous ne violez DRY selon aucune définition de celui-ci, si Foo change, votre modèle de vue voit automatiquement le changement, et vous vous laissez libre d'une liaison directe du modèle de vue au modèle.

Si demain il est nécessaire que la vue montre autre chose ainsi que le Foo, vous pouvez simplement ajouter une nouvelle propriété, et l'intention de votre modèle de vue sera toujours claire, il contient un Foo et autre chose, vous n'aurez pas un mélange de propriétés de Foo avec d'autres propriétés indépendantes.

Je ne considérerais pas votre modèle de vue comme un FooViewModel, je le considérerais en termes de ce que la vue est censée afficher. S'il n'affiche qu'un Foo, le modèle de vue contient une propriété, un Foo.

Je ne sais pas si je l'ai expliqué clairement. Sinon, faites-le moi savoir et je vais essayer de le reformuler quand je suis réveillé!

Je dirais que l'utilisation FooViewModelde cette manière viole le principe DRY. Lorsque vous devez apporter une modification, Foovous devez également effectuer une modification FooViewModel. Je pense que vous seriez mieux servi simplement en utilisant Foocomme modèle votre point de vue. Je considérerais un modèle de vue si vous avez besoin d'afficher des choses de Foo et quelque chose d'autre. Par exemple, supposons que vous ayez besoin de restituer certaines informations à partir Fooet à partir de Bar.