11

以下可以吗？我知道领域模型不应该在视图中使用，但是在视图模型中使用领域模型可以吗？对于一些非常小的模型，为它们创建和管理视图模型似乎不值得。

例如

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;}
}
4

3 回答 3

9

我个人在视图中使用域模型，如果它们自然是完全适合的。这可能只发生在本质上是 CRUD 的琐碎项目上（以直接的方式编辑域实体）。我发现为了纯粹性而创建域实体的精确副本是浪费时间。

我永远不会修改域模型来满足视图的需要。在我 95% 以上的项目中，这就是我发现自己所处的环境。当你为了视图而污染域时，就会引入可维护性问题。

于 2013-02-23T20:47:22.100 回答
1

长期以来，我一直在为由单独的视图模型和域模型引起的感知重复而苦苦挣扎。我会断言，由于它们用于不同的目的，因此并不是真正的重复，但是声明这么多相似的属性仍然感觉“错误”。

在非常小的项目中（尤其是那些具有高度信任的经过身份验证的用户组的项目），我可能只是直接绑定到域模型并完成它。或者，如果视图模型需要不同的结构（如@Eric J. 所述），我可以混合搭配。

但是：ModelBinder 将尝试将请求中的值与模型上的属性相匹配。这意味着域模型上的任何属性都可能被（流氓）请求填充。有一些方法可以防止这种情况发生，但对我来说，安心胜过创建单独的视图模型的一点额外努力。

我认为没有绝对需要为只读的未绑定值创建单独的视图模型（在您的情况下可能是用户类型列表，尽管public virtual ICollection<Login> Logins可能会否定这一点）。

或者，您可能希望将域模型投影到面向 UI 的抽象（例如IEnumerable<SelectListItem>）。您可以使用SelectListItems多种输入机制，因此您不会将自己束缚于特定的 UI 行为。

即使使用抽象，您仍可能需要验证请求不包含非法值。例如，也许只有超级管理员可以分配某些UserTypeDomainModelID。不管抽象如何，您仍然需要验证这一点。

TLDR：尽可能多地抽象领域模型，找到适当的抽象（新的视图模型并不总是正确的答案），并且（有点偏执）输入验证。

于 2013-02-23T21:03:11.887 回答
1

这取决于您所说的“域模型”是什么意思。你的意思是EF实体吗？还是您的意思是业务层对象？

将 EF 实体传递给视图绝不是一个好主意，尤其是在您使用默认模型绑定的情况下。如果您不小心，这可能会产生安全问题。尽管如果您对传递给视图的业务对象不小心，也会出现同样的问题。

视图模型的巨大优势之一是您可以更好地控制数据映射，因此您可以更轻松地验证只有正确的映射出现。

不过，这一切都取决于您的应用程序。如果它是一个简单的应用程序，那么做更复杂的映射可能不值得。如果它是一个复杂的应用程序，它必须存在很长时间，并且可能会更新很多......那么你绝对应该投入精力。

于 2013-02-23T21:03:48.227 回答