使用扩展方法验证域模型 [英] Validating domain model using extension methods
问题描述
我已经用研究一个<一个href=\"http://www.asp.net/mvc/tutorials/older-versions/models-%28data%29/validating-with-a-service-layer-cs\"相对=nofollow>服务层他们坚持到数据库之前验证我的域模型。
I've been researching using a service layer to validate my domain models before persisting them to a database.
我找到了<一个href=\"http://lostechies.com/jimmybogard/2007/10/24/entity-validation-with-visitors-and-extension-methods/\"相对=nofollow>下面的例子使用扩展方法来验证我的模型，<强>，但不知道是否有任何具体的缺点这么做？我没有看到（从数据注释除外）验证提到的所有的东西。
I found the following example of using extension methods to validate my models, but was wondering if there were any specific disadvantages to doing so? I don't see validation (aside from Data Annotations) mentioned all that much.
我想实现如下：
public class FooService : IFooService {
public bool Add(Foo foo) {
if (!foo.IsValid()) {
return false
}
try ... catch
}
}
public static class validationExtensions {
public static bool IsValid(this Foo foo) {
// Call my validation implementation here
}
}
我很紧张要做到这一点，因为我没有看到这个推荐/实现的多。思考？
I'm nervous to do this, as I don't see this recommended/implemented much. Thoughts?
推荐答案
域对象应该自我验证，这是简单的OOP。他们不应该被允许进入无效状态摆在首位。设计得当的域对象强制所有内部没有不变依赖外部code。否则，封装被破坏，你的对象其实只是一个愚蠢的数据容器与getter和setter。
Domain objects should be self validating, this is simple OOP. They should not be allowed to get into invalid state in the first place. Properly designed domain object enforces all internal invariants without relying on external code. Otherwise the encapsulation is broken and your objects are really just a dumb data containers with getters and setters.
这个词'验证'也可以是一个非常危险的以偏概全，倾向于重点从域和对象转移到针对UI框架的选择哑数据容器。这就是为什么 DDD书从未提及'验证'的问题都没有。我觉得它更有助于思考的不变比约验证。不变量可以像简单的社会安全号码不能有字母的，在这种情况下，值对象应该被使用。或更复杂的像的为了被认为是违法的，如果它不是在2周内所许的'，可在 order.IsDelinquent封装（）或类似的方法。请注意，在第一种情况下，我们消除对象的可能性，通过实施 socialSecurityNumber的类变得无效。而在第二种情况下，我们所说的'违法'从通用语言，而不是一般的有效。请看到类似的答案： 1 ，的 2 ， 3 。
The word 'validation' can also be a very dangerous overgeneralization, that tend to shift focus from domain and objects to dumb data containers tailored to a choice of UI framework. This is why DDD book never mentions the 'validation' issue at all. I find it more useful to think about invariant than about validation. Invariants can be as simple as 'social security number can not have letters', in which case a Value object should be used. Or more complex like 'order is considered to be delinquent if it was not payed within 2 weeks' which can be encapsulated within order.IsDelinquent() or similar method. Note that in the first case we eliminate the possibility of object becoming invalid by implementing SocialSecurityNumber class. And in the second case we use the word 'delinquent' from ubiquitous language instead of generic 'valid'. Please see similar answers: 1, 2, 3.
作为一个方面说明，你应该考虑从ASP.NET的人群都DDD建议用一粒盐。 ASP.NET MVC是一个很好的框架，但学习材料混淆域模型视图模型。大部分的例子考虑'域'对象是相同的，与getter和setter数据容器，没有任何封装。 DDD是技术中立，所以你可以随时问自己做一个现实检查就这有意义的控制台应用程序？或会在非UI项目？这有意义。
As a side note, you should probably take all 'DDD' advices from ASP.NET crowd with a grain of salt. ASP.NET MVC is a great framework but the learning material confuses Domain model with View model. Most of the examples consider 'domain' object to be the same as data container with getters and setters, without any encapsulation. DDD is technology agnostic, so you can always do a reality check by asking yourself 'would this make sense in a console app?' or 'would this make sense in a non-UI project?'.
这篇关于使用扩展方法验证域模型的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
