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

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 层部署架构，则服务/应用程序层将是固有且必要的。话虽如此，如果未设置网络架构，则可能没有真正的理由拥有服务层，特别是如果不需要其他应用程序（无论是内部的还是外部的）来使用服务层中包含的逻辑。在模型验证和存储库中实现您的业务逻辑是非常好的。