重构胖控制器并在服务层处理验证和日志记录

Question

我目前有一个受胖控制器影响的应用程序。我正在尝试将业务逻辑提取到服务层中，并希望阐明我的方法。

为了引发模型错误，我计划使用如下所述的方法：http://www.asp.net/mvc/tutorials/older-versions/models-%28data%29/validating-with-a-service-layer-cs - 使用 IValidationDictionary 方法大约降低了 1/2。

但我发现新版本的文档中没有讨论这种方法。在较新的版本中，服务层部分中的验证已完全删除。

我希望对于以下问题/验证我的方法有足够的背景：

1. 我相信上面链接中的方法已经过时，不应该用于支持 DataAnnotations（并且可能覆盖 IsValid - 这可能很天真，我不完全理解验证 ModelState.IsValid）。我的理解是否正确，还是这些问题有些不同？
2. 我希望对实体（在具有到实体的字段 1-1 映射的简单表单上）和 DTO（在具有不太简单映射到实体的表单上）的强类型视图进行混合。是否可以让实体验证冒泡到 DTO 以避免重复非业务需求验证？在没有 DTO 的情况下可以强类型化的实体上，我是否应该在实体上包含业务逻辑验证（这似乎是错误的）？我是否正确地考虑/处理了这一点？
3. 该站点正在使用存储库方法 - 我可以跳过服务层并让我的业务逻辑分布在数据注释和存储库中吗？我又问对了问题吗？

Answer 1

1. DataAnnotations 是当前 (MVC 4) 模型验证的最佳实践方法。就模型验证的工作流程而言，验证发生在模型绑定时，即 MVC 框架检查请求中的值并尝试绑定/水合/填充请求所针对的操作方法中列出的参数。

2. 当使用带有 MVC 的服务层时，将 DTO 与 MVC 中的视图模型合并是非常自然和方便的。两者的目的是只封装将在两点之间传递的数据。所以我想说创建一个类用作 DTO 和视图模型，并用 DataAnnotations 标记其属性以进行模型验证。

3. 这个问题有点主观，还取决于已部署应用程序的预期网络架构。如果您的目标是包含 Web、应用程序和数据库服务器的 3 层部署架构，则服务/应用程序层将是固有且必要的。话虽如此，如果未设置网络架构，则可能没有真正的理由拥有服务层，特别是如果不需要其他应用程序（无论是内部的还是外部的）来使用服务层中包含的逻辑。在模型验证和存储库中实现您的业务逻辑非常好。