重构胖控制器并处理验证和登录服务层

Question

我目前有一个受Fat Controllers影响的应用程序。我试图将业务逻辑划分为服务层，并希望澄清我的方法。

为了提出模型错误，我计划使用这里描述的方法：http://www.asp.net/mvc/tutorials/older-versions/models-%28data%29/validating-with-a-service-layer-cs - 大约使用IValidationDictionary方法的一半。

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

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

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

Answer 1

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

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

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