Question

这是一个普遍的问题：当您使用实体框架构建项目时，控制器将使用数据库连接并将ID等内容传递给它，并将模型返回给您的视图。

不应该将ID传递给您的Model然后处理查询逻辑吗？

我在mvc中的理解是你的数据访问应该在你的模型中完成，所以有如下内容：

public ActionResult Customer(int id)
{
    View(db.Customers.FirstOrDefault(x => x.id = id)) //Where this view accepts a CustomerModel
}

应该是

public ActionResult Customer(int id)
{
    var model = new CustomerModel(id) //Get customer logic is done within the model
    View(model)
}

我在构建一个脚手架项目时看到了很多第一个例子。特别是对于自动生成的Edit函数。这些CRUD操作不应该存放在模型中吗？或者这是Entity Framework独有的东西吗？

如果你不考虑EF，那么处理模型中的所有CRUD函数是否是设计它的正确方法？

Answer 1

你将这种模式的MVC与微软框架MVC混为一谈。当然，可以理解的是，考虑到微软选择的名称，但实际上，ASP.NET MVC只是非常松散地遵循MVC，即模式。

即，进入ASP.NET MVC的大多数新开发人员将其视为模型，仅仅是实体。它只是一个DTO类来保存数据，因为它随机播放数据库。 绝对不包含查询逻辑。

大多数ASP.NET MVC开发人员最终都会添加服务/存储库层并将模型视图混合在一起。这三者，实体，服务/存储库层以及各种视图模型一起构成MVC模型。服务/存储库负责处理CRUD函数和其他与数据库相关的业务逻辑，而视图模型负责与UI相关的业务逻辑。实体只是EF可以填充数据的东西。

Answer 2

imho，你正在混合（至少）两个概念：

控制器（在其他情况下并通过业务领域层）建立两者之间的联系。

AND NO：视图不需要（不得）查看数据层。

最后：这个问题可能是基于意见的（见imho）。

Answer 3

这真的是一个偏好的问题。就个人而言，我喜欢将我的模型保持为愚蠢的物体，但您也可能更喜欢将模型用于CRUD。通过将ID传递给构造函数来获取客户的示例并不是最好的主意，因为您的模型中存在对DbContext的硬依赖性，这会使测试变得困难并导致问题。

scaffolded控制器直接与DbContext交互，只做必要的最小量并保持简单。如果你需要额外的逻辑，你可以在其他地方重构它。