ASP.NET MVC应用程序是否应该直接使用实体框架作为模型？

我正在Visual Studio 2013（MVC 5）中构建我的第一个MVC应用程序，但我对设置模型的最佳方法尚不清楚。

我已经从现有数据库中使用代码优先生成了一个实体框架模型。我的第一个直觉是创建一些中间类，这些中间类将成为视图使用的模型，并使这些类与实体框架类一起工作。

当我编写中介类时，我意识到我只是在重新实现EF类已经用偶尔的私有setter或从一种数据类型转换为另一种数据类型所做的许多事情。因此，这似乎是一种浪费。

是否直接将实体框架类用作MVC应用程序的模型是一般规则？还是构建这些中间课程缺少一些好处？

在我的应用程序中，我总是使用数据库（实体框架）和MVC的不同模型来分离事物。我也将它们分为不同的项目：

• Example.Entities-包含我的EF实体和用于访问它们的数据库上下文。
• Example.Models-包含MVC模型。
• Example.Web -Web应用程序。同时取决于Example.Domain和Example.Models。

MVC模型不是像域实体那样保存对其他对象的引用，而是将ID作为整数保存。

当对页面的GET请求进入时，MVC控制器执行数据库查询，该查询返回一个实体。我编写了采用域实体并将其转换为MVC模型的“转换器”方法。还有其他方法则相反（从MVC模型到域实体）。然后将模型传递给视图，从而传递给客户端。

当发出POST请求时，MVC控制器将获得MVC模型。转换器方法将其转换为域实体。此方法还执行任何无法表示为属性的验证，并确保如果域实体已经存在，则我们将对其进行更新而不是获取新的。这些方法通常看起来像这样：

public class PersonConverter
{
    public MyDatabaseContext _db;

    public PersonEntity Convert(PersonModel source)
    {
         PersonEntity destination = _db.People.Find(source.ID);

         if(destination == null)
             destination = new PersonEntity();

         destination.Name = source.Name;
         destination.Organisation = _db.Organisations.Find(source.OrganisationID);
         //etc

         return destination;
    }

    public PersonModel Convert(PersonEntity source)
    {
         PersonModel destination = new PersonModel()
         {
             Name = source.Name,
             OrganisationID = source.Organisation.ID,
             //etc
         };

         return destination;
    }
}

通过使用这些方法，我消除了在每个控制器中原本会发生的重复。使用泛型可以进一步消除重复数据。

用这种方式做事有很多好处：

• 您可以根据特定的视图或操作来自定义模型。假设您有一个人的注册表单，该表单在提交后会创建许多不同的实体（人，组织，地址）。如果没有单独的MVC模型，这将非常困难。
• 如果我需要向视图传递比仅在实体中可用的信息更多的信息，或者将两个实体组合到一个模型中，那么我的宝贵数据库模型就永远不会被触及。
• 如果您曾经将MVC模型序列化为JSON或XML，则只会获得序列化的直接模型，而不是链接到该模型的所有其他实体。

我会说这确实取决于您的应用程序。它只是在做纯CRUD，没有任何业务逻辑吗？然后，我将直接在视图中使用EF模型。

大多数时候，至少涉及一些业务逻辑，然后在数据/ EF模型与视图之间形成一个层可能是一个好主意。在这种情况下，可能需要执行“ CQRS-lite”（请参见下文）并在控制器内外使用不同的模型。在大多数情况下，读取模型比写入模型“麻烦”得多。

但是，如果应用程序包含很多业务逻辑和/或需要扩展很多，我将至少使用CQRS（命令查询责任隔离），DDD（域驱动设计）以及可能的事件源实现其核心。然后，EF可以用作读取模型的外观。

还要记住，您不必为整个应用程序坚持一种策略/模式，某些区域可能是纯CRUD，而其他区域可能包含许多业务逻辑...