考虑到此应用程序设计，放置验证逻辑的最佳位置在哪里？
考虑一个 ASP.NET MVC 2 Web 应用程序项目，该项目使用 EF4 POCO 实体和存储库模式在 SQL Server 数据库中存储信息。到目前为止，有 3 个项目，如果算上数据库的话，有 4 个：
1.) Domain.dll，没有依赖项，公开 POCO 和存储库接口。
2.) Storage.dll，依赖于Domain，实现存储库接口（使用EF 4）。
3.) Mvc.dll，依赖于#1和#2，提供UI层。
4.) SQL Server 数据库 + 连接，与 dll 无关（无依赖项）。
假设我添加另一个 Web 应用程序来托管 WCF 数据服务，该服务使用 Domain.dll 和 Storage.dll 提供数据库的 OData 源：
5.) Provider.dll，依赖于 Domain 和 Provider.dll。 Storage，提供OData服务层。
域验证逻辑在此解决方案中属于哪里？如果域 POCO 类用验证属性修饰，WCF 数据服务还需要其他东西来保护数据吗？将验证逻辑放入存储过程中是好还是坏主意，为什么？
Consider an ASP.NET MVC 2 web application project that uses EF4 POCO entities and the repository pattern to store information in a SQL Server database. So far there are 3 projects, 4 if you count the database:
1.) Domain.dll, has no dependencies, exposes POCO's and repository interfaces.
2.) Storage.dll, depends on Domain, implements repository interfaces (using EF 4).
3.) Mvc.dll, depends on both #1 and #2, provides UI layer.
4.) SQL Server database + connection, dll agnostic (no dependencies).
Let's say I add another web application to host a WCF Data Service, which provides an OData feed of the database using Domain.dll and Storage.dll:
5.) Provider.dll, depends on Domain & Storage, provides OData service layer.
Where does the domain validation logic belong in this solution? If the domain POCO classes are decorated with validation attributes, does the WCF data service need anything else to protect the data? Is it ever a good/bad idea to put validation logic into stored procedures, and why?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我想说将 DataAttributes 放在域上，并在 MVC 中使用 MVC 部分的验证，并使用 Ent Lib 在 WCF 服务中进行验证。或者，您可以在 MVC 和 WCF 中使用 Ent Live 验证，但这不是本文的目的。我不知道这需要归结为 DDD 语义。当模型具有 DataAttributes 时，MVC 会对模型进行验证，因此请遵循这一点并在 WCF 中执行相同的操作。
I would say put DataAttributes on the Domain and use the validation in MVC for the MVC part and use Ent Lib to do the validation in the WCF Service. Alternatively you could use the Ent Live validation in both MVC and WCF, but thats not what this is about. I dont know that this needs to come down to DDD semantics. MVC does validation on the Models when they have DataAttributes, so follow that and do the same in WCF.
我将其标记为主观且有争议的，因为即使是 DDD 社区也无法对此做出决定。
如果出现新的 Customer.LastName 验证要求，您需要更改多少层？ UI层能否通知用户域、wcf、web、数据库层拒绝了他们的命令？姓氏不能超过 50 个字符的姓氏限制如何成为业务域的一部分？
你可以看到，这实际上是一个讨论，而不是一个可以回答的问题。
此外，如果您使用 OData 作为服务的数据库源，那么您就没有使用 DDD。您正在使用 Persistance-As-Model 或 DDD-Lite。这实际上是有害的，并会导致类似这样的问题，试图解决同时使用两种不兼容模式的问题。
I marked this as subjective and argumentative because even the DDD community can't make up its mind about this.
How many layers do you need to change if a new validation requirement for Customer.LastName comes in? Can the UI layer inform the user the domain, wcf, web, database layers have rejected their commands? How is a LastName restriction that a LastName can't exceed 50 characters part of the business domain?
You can see that this is really a discussion and not a answerable question.
Also if your using OData as a Database feed for your services you are not using DDD. You are using Persistance-As-Model or DDD-Lite. This is actually harmful and results in questions like this that try to resolve the problems with using two incompatible patterns together.