EF 实体与服务模型与视图模型 (MVC)

Question

我正在尝试了解和找出设计应用/域模型 (POCO/DTO) 的良好做法。

假设我有以下数据库表，帐户：

UserID int
Email varchar(50)
PasswordHash varchar(250)
PasswordSalt varchar(250)

当然，EF4 会像这样构建实体：

public class Account
{
    public int UserID { get; set; }
    public string Email { get; set; }
    public string PasswordHash { get; set; }
    public string PasswordSalt { get; set; }
}

现在，假设我有一个用于注册新用户的视图模型，它可能看起来像这样：

public class RegistrationViewModel
{
    public string Email { get; set; }
    public string Password { get; set; }
}

最后，我有一个需要注册用户的服务：

public class RegistrationService
{
    public void RegisterUser(??? registration)
    {
        // Do stuff to register user
    }
}

我正在尝试找出要传递给 RegisterUser 方法的内容。视图模型当然位于我的 Web 应用程序（表示层）下，所以我不希望它被传递给我的服务。

所以，我在考虑以下四种可能性之一：

1) 设置一个与 RegistrationViewModel 相似（如果不相同）的服务模型，并使用它：

public class RegistrationServiceModel
{
    public string Email { get; set; }
    public string Password { get; set; }
}

public class RegistrationService
{
    public void RegisterUser(RegistrationServiceModel registration)
    {
        // Do stuff to register user
    }
}

2）设置模型的接口，并在我的视图模型中继承这个，并设置我的方法接受接口：

public interface IRegistrationModel
{
    string Email;
    string Password;
}

public class RegistrationServiceModel : IRegistrationModel
{
    public string Email { get; set; }
    public string Password { get; set; }
}

public class RegistrationService
{
    public void RegisterUser(IRegistrationModel registration)
    {
        // Do stuff to register user
    }
}

3) 传入 Account 实体，在我的控制器中进行 RegistrationViewModel 到 Account 的映射：

public class RegistrationService
{
    public void RegisterUser(Account account)
    {
        // Do stuff to register user
    }
}

4) 将我的视图模型从表示中移到域/服务层，并将其传递给服务方法：

public class RegistrationService
{
    public void RegisterUser(RegistrationViewModel account)
    {
        // Do stuff to register user
    }
}

这三种情况似乎都不理想，因为我发现每种情况都存在问题。所以我想知道是否还有其他我想不到的方法。

对此有什么好的做法？

提前致谢。

Answer 1

您永远不会将视图模型传递给服务。服务甚至不知道您可能已在表示层中定义的视图模型的存在。服务与域模型一起工作。
使用Auto mapper 在视图模型和域模型之间进行映射，反之亦然。

就我个人而言，我从未听说过 DDD（服务视图模型）中的服务模型。

Answer 2

使用 3rd 选项，当然。正如 šljaker 所说，Service 应该不知道应用程序的表示部分（您的 ViewModel 是其中的一部分）。

当然，也不要通过包含大量过渡模型（例如 RegistrationServiceModel 或更糟糕的 - IRegistrationModel（最后一个模型有一天会导致“界面爆炸”）来使事情变得过于复杂。

所以：

1. 拥有一个域实体（使用 Entity Framework 或 NHibernate 或 NoRM 等持久化的 POCO 实体）。
2. 在给定的上下文中拥有一个代表您的域模型的 ViewModel。如有必要，请不要犹豫，为每个控制器操作创建一个 ViewModel。严格的 ViewModel（与您的视图 1:1 的那些）的副作用是完全没有过度发布和发布不足的问题。不过，这取决于您的具体情况/口味。
3. 将 DataAnnotation 属性与您的 ViewModel 一起使用以提供基本验证（请记住也要验证业务规则，但它应该位于线路后面 - 在 Services/Repositories 层内）。
4. 不要让应用服务知道 ViewModel。创建一个域实体实例并将其提供给服务（以验证/保持）。
5. 使用 AutoMapper 作为选项将您的域实体快速映射到 ViewModel。
6. 在控制器操作或自定义 IModelBinder 中将传入的 ViewModel 或 FormCollection 映射到您的实体。
7. （可选）我建议关注Thunderdome Principle。这是 ViewModel 的一种非常非常方便的用法。

Answer 3

在这种情况下，使用 DTO（数据传输对象）非常有意义。您可以在服务层创建一个AccountDto 类，并使用它将注册数据向下传递给服务。在某些情况下，它可能类似于 ViewModel，但通常您可以在视图中显示比创建用户所需的更多内容。为了进一步说明这一点，您的 ViewModel 可能至少看起来像这样：

public class RegistrationViewModel
{
    [Required]
    public string Email { get; set; }

    [Required]
    public string Password { get; set; } 

    [Required]
    [Compare("Password")]
    public string RepeatPassword { get; set; } 
}

而您的 DTO 只需要 Email 和 Password 属性。

public class AccountDto
{
    public string Email { get; set; }
    public string Password { get; set; }
}

如您所见，ViewModel 仅包含View 所需的数据。电子邮件验证和密码比较逻辑发生在您的 Web 层中。您使用 DTO 仅获取服务的电子邮件和密码。然后在服务层对密码进行哈希处理，填充实体对象并将值保存到数据库中。