asp.net-mvc - ASP.NET MVC - MVC 职责

Question

我可能在这里分析过度了，但是根据我对 MVC 的阅读，似乎有很多关于如何做事情的观点。

是否有一个“最佳实践”网站或文档来定义 MVC 各个部分的职责？

请记住，我使用 EF/Repository&UnitOfWork/Service 模式时遇到的几个问题是:

1)如何将领域对象和业务规则的验证结果(错误消息等)从服务层获取到 View 模型？

2)我使用域对象和一个执行所有业务逻辑的服务层，然后我将域对象发送到 Controller 并让它们(通过 AutoMapper)将它们转换为 View 的 View 模型。 Controller 还负责哪些其他类型的事情？下面的代码可以吗？ Controller 中的逻辑是否太多？:

public ActionResult SomeAction()
{
    var model = Mapper.Map<DomainObject, ViewModel>(service.QueryReposForData());
    model.SomeCollectionForSelectList = Mapper.Map<IEnumerable<DomainObject>, IEnumerable<ViewModel>>(service.QueryReposForSelectListData());
    return View(model);
}

我不认为 Controller 中唯一的东西就是返回一个带有映射到 View 模型的对象图的 View 的一行？

3)我认为在 ViewModel 上拥有属性可以向 View 指示是否可以隐藏某些内容，然后在 View 中执行该逻辑？示例:

@if(Model.DisplaySomething)
{
    <div>Something to show</div>
}
else
{
    <div>Something else to show</div>
}

4) 我正在考虑让我的服务在写入时将某种 TransactionResult 对象返回给 Controller ，以使服务有责任处理事务。所以我会有一个聚合服务来启动一个事务(UnitOfWork)做它需要做的事情，然后返回这个可能有错误消息的 TransactionResult ？我认为我不应该让 Controller 负责管理事务，而是让它只将映射到域对象的 View 模型传递给服务并让它对其进行操作？

5) 另外，您想使用多少 ActionFilter？我知道这是一个巨大的扩展点，但我经常发现自己试图将所有模型创建填充到过滤器中。

Answer 1

这里只是基于我们工作方式的意见。

我们把 Controller 保持得很瘦，几乎在所有情况下，他们都会厌食。

对于 ViewModel，我们遵循为每个 View 都有一个 ViewModel 的模式。 Controller 加载它需要的任何东西，然后启动它。从那里开始，ViewModel 驱动一切。在我们的世界中，ViewModel 直接与 View 绑定(bind)，并且不包含可以在应用程序的其他部分使用的代码。它与它需要的更大“模型”(服务层等)的任何部分进行交互，并将内容打包以供 View 使用。

对于你的#3 示例，我会说绝对是的 - 这就是我们使用 ViewModel 的方式。

再说一遍，这些都不是福音 - 只是我对我们如何处理它的看法。