使用 EF 和 POCO 时，我应该在哪里/何时验证我的数据？
我启动了一个项目，看看 EF 4 可以用 POCO 做什么。我创建了一个数据库和一个自定义 POCO。现在我想验证我的数据。为此，我使用 Enterprise Library Validation Block 5。
我可以通过属性在 POCO 中包含验证并将其与实体框架一起使用，但这意味着我的 POCO 将不再是 POCO，因为我将依赖项插入到验证框架。
有什么建议我应该在哪里插入验证部分并保持 POCO 清洁吗？
I started a project to see what EF 4 can do with POCOs. I created a db and a custom POCO. Now i want to validate my data. For this i'm using the Enterprise Library Validation Block 5.
I have no problem including the validation in my POCOs through attributes and using it with Entity Framework but this means that my POCOs wouldn't be POCOs anymore because i inserted the dependency to the Validation framework.
Any advice where should i insert the validation part and keep the POCOs clean?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我将创建一个服务类并在该类中进行验证。
例如，您有一个名为 Listing 的 POCO 类。创建一个名为 ListingService 的服务类。然后在 ListingService 中的 ValidateListing 方法中进行验证。
I would create a service class and do the validation in that class.
For instance, you have a POCO class called Listing. Create a service class called ListingService. Then do the validation in ListingService in a method called ValidateListing.
我同意您希望让您的实体免于验证。它不是域对象本身的责任 (SRP)。
除了基于属性的验证之外，企业库验证应用程序块 (VAB) 还支持基于配置的验证。您可以在此处遵循两种模型：
使用基于 XML 的配置。这得到了很好的支持。 VAB 包含一个配置工具，允许您配置整个事物，而无需编写任何 XML 行。尤其是5.0的工具非常好。尽管如此，使用 XML 仍然很难重构模型中的任何内容（但是，单元测试将帮助您更快地发现错误）。
使用基于代码的配置。虽然我个人喜欢这个模型，因为它可以更好地使您的领域易于重构。你可以让它工作，但它还没有得到很好的支持。您可以查看此线程以查看如何编码的示例基于配置以及当前的缺点是什么。
祝你好运。
I agree that you would like to keep your entities free from validation. It is not the responsibility (SRP) of the domain object itself.
Besides attribute based validation, the Enterprise Library Validation Application Block (VAB) also supports configuration based validation. There are two models you can follow here:
Use XML based configuration. This is well supported. The VAB contains a configuration tool that allows you to configure the whole thing without writing a single line of XML. Especially the 5.0 tool is very good. Still, using XML makes it hard to refactor anything in your model (however, unit tests will help you spot error sooner).
Using code based configuration. While I personally like this model, because it can do a much better job in making your domain easy to refactor. You can get it to work, but it isn't a well supported yet. You can look at this thread to see an example of how to code based configuration and what the current short comes are.
Good luck.
就我个人而言，我不认为将验证作为实体的一部分有多大问题 - 毕竟，实体是域模型的一部分，并且验证规则可以被认为是域模型的一部分他们的属性。不过，我不是领域建模专家:)
最后，验证需要在某种程度上与实体结合起来。如果您决定减少耦合，我认为最终可能会出现尴尬的代码。对于我最新的项目，我确实将验证分为不同的类，这些类被放置在实体的部分类中，到目前为止我对结果非常满意。
Personally I don't see that much of a problem having validation as part of the entities - after all, the entities are part of your domain model, and validation rules can be thought of, arguably, as part of their attributes. I'm no domain modeling expert though :)
In the end, validation will need to be somewhat coupled with the entities. If you decide to decrease the coupling, I think there's a risk of ending up with awkward code. For my latest project, I did split up the validation into different classes, which were placed in partial classes of the entities, and I'm quite happy with the result so far.