考虑到这个应用程序设计，放置验证逻辑的最佳位置在哪里？答案

【问题标题】：Where is the best place to put validation logic given this application design?考虑到这个应用程序设计，放置验证逻辑的最佳位置在哪里？
【发布时间】：2010-10-12 17:26:12
【问题描述】：

考虑一个使用 EF4 POCO 实体和存储库模式将信息存储在 SQL Server 数据库中的 ASP.NET MVC 2 Web 应用程序项目。到目前为止，有 3 个项目，如果算上数据库，则为 4 个：

1.) Domain.dll，没有依赖关系，公开 POCO 和存储库接口。

2.) Storage.dll，依赖于域，实现存储库接口（使用 EF 4）。

3.) Mvc.dll，依赖于#1 和#2，提供 UI 层。

4.) SQL Server 数据库 + 连接，dll 不可知（无依赖关系）。

假设我添加了另一个 Web 应用程序来托管 WCF 数据服务，它使用 Domain.dll 和 Storage.dll 提供数据库的 OData 提要：

5.) Provider.dll，依赖于Domain & Storage，提供OData服务层。

域验证逻辑在此解决方案中属于什么位置？如果域 POCO 类装饰有验证属性，WCF 数据服务是否需要其他任何东西来保护数据？将验证逻辑放入存储过程中是个好主意还是坏主意，为什么？

【问题讨论】：

将验证逻辑放在 SP 中是一个坏主意，因为您不能轻易更改 dbs（实际上几乎不会发生），但这意味着如果没有实际的 db（实际上是一件坏事），而且它很笨拙，无法在层级中获取错误消息。此外，您正在损害可扩展性。话虽如此，唯一键等应该存在于您的数据库中，以作为后盾。
正确。由于特定的验证，我实际上是在询问 sp。我的一些实体代表分层节点，因此可能存在循环分层关系。这可能是我应该通过检查数据库客户端和数据库本身来加强的地方，尽管通过触发器而不是 sp。

标签： asp.net-mvc entity-framework-4 poco validation relational-database

【解决方案1】：

我会说将 DataAttributes 放在域上并使用 MVC 中的验证作为 MVC 部分，并使用 Ent Lib 在 WCF 服务中进行验证。或者，您可以在 MVC 和 WCF 中使用 Ent Live 验证，但这不是它的目的。我不知道这需要归结为 DDD 语义。当模型具有 DataAttributes 时，MVC 会对模型进行验证，因此请遵循并在 WCF 中执行相同的操作。

【讨论】：

谢谢，其实我昨天问了这个问题后才发现了entlib验证块。 MVC 项目已经在使用 Unity 2.0，因此 entlib 看起来很有希望。
我将为此插入我自己的博客...如果您想将 entlib 作为提供者放入您的 MVC 解决方案中，请查看这篇文章：bitsinmyhead.com/2010/09/…
我还发现了这个在 MVC 中使用 entlib 验证的小知识：codebetter.com/blogs/david.hayden/archive/2009/02/03/…

【解决方案2】：

我将此标记为主观且有争议的，因为即使是 DDD 社区也无法对此做出决定。

如果出现对 Customer.LastName 的新验证要求，您需要更改多少层？ UI 层能否通知用户 domain、wcf、web、数据库层拒绝了他们的命令？姓氏不能超过 50 个字符的姓氏限制是业务域的一部分吗？

您可以看到这实际上是一个讨论，而不是一个可以回答的问题。

此外，如果您使用 OData 作为您的服务的数据库提要，则您没有使用 DDD。您正在使用 Persistance-As-Model 或 DDD-Lite。这实际上是有害的，并且会导致类似这样的问题，试图解决同时使用两种不兼容模式的问题。

【讨论】：