Web 服务的验证和验证规则答案

【问题标题】：Validation & Validation Rules for Web ServicesWeb 服务的验证和验证规则
【发布时间】：2011-09-21 23:32:39
【问题描述】：

在我从事过的大多数 Web 服务应用程序中，我都经历过以下场景：

我们创建一个领域模型（在 C# 中）。这是应用程序的核心。领域模型包含业务和验证规则，用于确定实体在什么条件下有效。
我们创建一个“Web 服务”层（在 C#/WCF 中）。 这一层定义了由 Web 服务公开的类似 DTO 的对象。 类似 DTO 的对象是从域实体的片段中分割和组装的，通常以粗粒度的方式。
在网络客户端（JavaScript 和 HTML）上，验证规则以不同的格式重复，通常是某种形式的 JavaScript 验证。

附加到域实体片段的验证规则如何通过 Web 服务向客户端公开？这样做的原因是域模型的验证规则应该定义一次，然后在整个系统的其余部分以某种格式提供给消费者客户端。

到目前为止，我提出的唯一解决方案是使域中的验证规则以某种形式的元数据可用，以 XML、JSON 或类似形式定义。最大的问题是服务层的 DTO 和域实体之间的模式不同，因此域的验证规则不能直接发送到 Web 客户端——客户端使用不同的模式和域模型。

因此我的问题是：什么方法需要最少的手动和重复代码，在应用程序中的不同架构和层之间进行映射，但允许一切解释验证规则？

【问题讨论】：

为什么不直接序列化您的域对象，而不是创建具有不同验证规则的不同 DTO？除非您想更改域对象但保持服务层不变，否则我看不到此转换添加了什么。
定义服务 DTO 的原因有很多。使用该服务的 UI 客户端具有与域不同的架构要求。在 REST 中，您将定义和传输 REST 资源。域实体附加了很多东西，这对服务客户没有意义。它符合 SOA 最佳实践……等等等等。
有趣，我认为服务层是应用程序的核心，因为它定义了公开的信息和可用的功能。抱歉，我没有你的问题的答案。我首先想到了OCL（对象约束语言），但那是我只听说过的。

标签： c# javascript web-services validation domain-driven-design

【解决方案1】：

有两种类型的业务规则：

应用程序特定规则

领域特定规则。

如何在两者之间划分规则是另一回事，但没有理由不能重复检查。

例如，我在我的 Web 应用程序中使用了一个 ViewModel，它装饰有验证属性，便于通过 jQuery 进行不引人注目的客户端验证。

我使用 AutoMapper 将域对象转换为 ViewModel，反之亦然。

拥有单独的 ViewModel 允许我扩展必填字段的域验证，并进行一些特定于应用程序的检查（通过验证属性可以实现）。

【讨论】：

请解释一下，例如，您如何让您的客户端和服务层知道在您的 Person 域实体上定义了 FirstNameMandatoryValidatioRule，而无需在您的 ViewModel 上手动重新定义/重新编码它？换句话说，理想情况下，我正在寻找一种解决方案，我可以在其中更新域中的 FirstNameMandatoryValidationRule 和服务 DTO，并且 Web 客户端应该能够自动知道在其架构中调用该字段的任何内容都是强制性的。验证规则应该只定义一次，系统的其余部分应该只解释它。
Web 客户端（在您的情况下为 ViewModel）也应该能够在本地执行验证，而无需调用服务和域。
"验证规则应该只定义一次，系统的其余部分应该只解释它。"我不同意这种说法。域层中的验证应该是监管，而不是命令。如果存在重复使用的潜力，则应考虑它 - 例如在 UI 中绑定到公开的域对象，而不是 DTO，但是 TBH 这在其他方面是如此的限制，以至于大多数情况下它是不值得的。这里可能还有其他意见，我承认我没有给你你正在寻找的答案 - 也许只是值得深思。
Web 客户端应该在本地执行验证。然后在数据库前面的 web 服务中对此进行双重检查（Web 应用程序没有直接连接到数据库 - 仅连接到 WCF 服务）。出于性能原因，Web 应用程序必须自行验证。 WCF 服务也必须进行验证，因为这是它存在的理由 - 以保护数据的有效性。
注意 - 建议不要直接绑定到域对象的文章 - codethinked.com/aspnet-mvc-think-before-you-bind