est l'option suivante pour faire? Je sais que les modèles de domaine ne doivent jamais être utilisés dans des vues, mais il est-il correct d'utiliser des modèles de domaine dans vos modèles de vue? Pour certains très petits modèles, cela ne semble pas la peine de créer et de gérer un modèle de vue pour eux.
Par exemple P>
public class LoginDomainModel
{
public string Email { get; set; }
public string Password { get; set; }
public string DisplayName { get; set; }
public long UserTypeID { get; set; }
public virtual UserType UserType { get; set; }
}
public class UserTypeDomainModel
{
public UserType()
{
this.Logins = new List<Login>();
}
public long UserTypeID { get; set; }
public string UserType { get; set; }
public string Description { get; set; }
public virtual ICollection<Login> Logins { get; set; }
}
public class LoginViewModel
{
public string Email { get; set; }
public long UserTypeID {get; set;}
//Right here
public List<UserTypeDomainModel> UserTypesSelectList {get; set;}
}
3 Réponses :
Personnellement, j'utilise des modèles de domaine dans la vue S'ils seraient naturellement un ajustement exact . Cela ne se produira probablement que sur des projets triviaux qui sont de nature crud (éditer les entités de domaine de manière simple). Je trouve une perte de temps pour créer une copie exacte d'une entité de domaine pour des raisons de pureté.
Je vais jamais modifier un modèle de domaine au moindre pour tenir compte des besoins de la vue. Dans 95% + de mes projets, c'est la circonstance que je trouve moi-même. Au moment où vous polluez le domaine, vous introduisez des maux de tête de maintenabilité.
Jusqu'à ce que votre mise à jour des entités de domaine et que votre vue ne soit pas encore. Ensuite, vous obtenez des maux de tête avec de nouveaux champs obligatoires qui ne sont pas présentés dans l'interface. Je suppose que cela dépend de la fréquence de changements dans votre modèle de domaine ou de se produire.
@Bradchristie: Dans 95% des projets, j'ai séparément un modèle d'affichage et un modèle de domaine avec une couche de mappage (Automapper est bon). Pour 5% des projets (petits, simples, ... souvent 1 personne) qui est surchargé.
Il y a éventuellement des implications de sécurité. Je trouve que l'utilisation d'entités de modèle de domaine dans la vue / viewModel augmente considérablement la probabilité que vous introduisez des vulnérabilités de sécurité sous la forme d'attaques «surposter» (voir aussi odecode.com/blogs/scott/archive/2012/03/11 / ... ). J'observe également que l'utilisation des entités de domaine directement dans View / ViewModel est souvent un signe du "modèle de domaine anémique" anti-motif ( martinfowler.com/bliki/anemicdomainmodel.html ). J'utiliserai des "objets de valeur" dans la vue / vieilleLodel, mais pas des entités.
La question de la sécurité reste si vous utilisez quelque chose comme Compapper sans le même soin, comme indiqué sur le blog de Scott (à l'exclusion de certains mappages). Dans un cas trivial (le seul endroit où je ne considère pas de modèle de domaine distinct), le modèle de domaine va être anémique quoi que ce soit parce que par définition, le sujet est trivial. Chaque fois qu'il y a une richesse au domaine, je disposerais de domaines distincts et de voir des modèles pour cette raison même.
J'ai eu du mal à long terme avec la duplication perçue causée par des modèles de visualisation séparés et des modèles de domaine. J'affirmerais que puisqu'ils sont destinés à des fins différentes, ce n'est pas vraiment de la duplication, mais cela se sent toujours "faux" de déclarer autant de propriétés similaires.
Dans de très petits projets (en particulier ceux avec un groupe très fiable d'utilisateurs authentifiés), je peux simplement lier directement sur les modèles de domaine et être effectué avec elle. Ou je peux mélanger et correspondre si le modèle de vue nécessite une structure différente (comme @ eric J. décrit).
Cependant, : Le modèleBinder tentera de faire correspondre les valeurs de la demande aux propriétés de votre modèle. Cela signifie que toute propriété sur votre modèle de domaine peut potentiellement être peuplée par une demande (voyou). Il y a des moyens d'empêcher cela, mais pour moi, la tranquillité d'esprit l'emporte un peu d'effort supplémentaire créant des modèles de vue séparés.
Je ne vois pas de besoin absolu de créer un modèle d'affichage séparé pour les valeurs libéonnées, non liées (éventuellement la liste des types d'utilisateurs dans votre cas, bien que Vous pouvez également projeter le modèle de domaine à une abstraction orientée UI (E.G. Même avec abstraction, vous devrez peut-être toujours valider que la demande ne contient pas de valeur illégale. Par exemple, seuls les super-administrations peuvent attribuer certains TLDR: Les modèles de domaine abstrait Tout comme sont pratiques, trouvez des abstractions appropriées (un nouveau modèle de vue n'est pas toujours la bonne réponse) et être (légèrement paranoïde) sur la validation d'entrée. Icollection virtuelle publique iEnumerable sélectlistitems pour une variété de mécanismes d'entrée, de sorte que vous ne vous attachez pas à un comportement d'interface utilisateur particulier.
UsertyPedomainModel ID. Indépendamment de l'abstraction, vous devez toujours valider cela.
Cela dépend de ce que vous entendez par "modèle de domaine". Voulez-vous dire des entités EF? Ou voulez-vous dire des objets de couche d'entreprise?
Ce n'est jamais une bonne idée de passer des entités EF à la vue, en particulier si vous utilisez la liaison de modèle par défaut. Cela peut créer des problèmes de sécurité si vous ne faites pas attention. Bien que les mêmes problèmes puisse se produire si vous n'êtes pas prudent avec les objets d'affaires passés à la vue.
L'un des énormes avantages des modèles d'affichage est que vous avez beaucoup de contrôle plus fin sur la cartographie des données. Vous pouvez donc valider plus facilement que seules les cartes correctes se produisent.
Tout est tout cependant sur votre application. Si c'est une application simple, cela ne vaut peut-être pas la peine de faire des mappages plus complexes. Si c'est une application complexe, cela doit vivre longtemps et sera probablement mis à jour .. alors vous devez certainement investir l'effort.
Je faisais appelé aux entités EF.
@Preston - alors c'est votre modèle de données, pas votre modèle de domaine. Et mes conseils ci-dessus s'appliquent toujours
Toutes les grandes réponses, merci à tous.