我正在尝试遵循最佳多层设计实践，并且不希望我的 MVC Controller 与我的 DAL(或与此相关的任何 IRepository)交互。它必须通过我的业务服务层来执行正确的业务规则和验证。验证 - 我不想在我的域模型实体上使用各种验证属性(例如 [Required])在 Controller 中执行验证，因为这会照亮我的前端。更不用说这个服务也可以通过 WPF 前端来实现。
由于我的验证是在我的服务层中完成的，将值返回到 UI 的最佳做法是什么？我不想要“void addWhatever(int somethingsID)”，因为我需要知道它是否失败。它应该是一个 bool 值吗？它应该是一个枚举吗？我应该利用异常处理吗？或者我应该返回一些 IValidationDictionary 对象，类似于 MVC 在将验证属性装饰到 Model 对象时使用的对象吗？ (如果需要，我稍后可以在 UI 中使用适配器模式)
我想将我的实体从 Controller 传递到服务层，并了解验证/数据持久化是否失败。我也不想忽视这样一个事实，即我需要返回一个 View ，指示可能验证失败的每个字段的正确错误消息(我希望尽可能轻松地实现这一点)。
我有过几个想法，但都感觉不对。我觉得答案包括特定于 View 的模型实体，但这会导致必须处理的整个映射问题，更不用说这违反了 DRY(不要重复自己)原则。什么是最佳实践？
最佳答案
我知道，似乎进行 MVC 验证违反了 DRY，但实际上......它并没有......至少对于大多数(非平凡的)应用程序而言。
为什么？因为您的 View 验证要求通常与您的业务对象验证要求不同。您的 View 验证本身涉及验证特定 View 是否有效，而不是您的业务模型是否有效。
有时这两者是相同的，但如果您构建应用时 View 要求业务模型有效，那么您就是将自己锁定在这种情况下。如果您需要将对象创建分成两个页面会怎样？如果您决定将服务层用于 Web 服务，会发生什么情况？通过将您的 UI 锁定到业务层验证场景中，您会严重削弱您可以提供的解决方案种类。
View 是输入的验证，而不是模型的验证。
关于c# - MVC 验证 - 使用服务层保持干燥 - 最佳实践是什么？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8074548/