使用扩展方法验证域模型
我一直在研究使用 服务层用于在将域模型保存到数据库之前验证它们。
我找到了以下示例 使用扩展方法来验证我的模型，但是想知道这样做是否有任何具体的缺点？我没有看到验证（除了数据注释）提到那么多。
我正在考虑实施以下内容：
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've been researching using a service layer to validate my domain models before persisting them to a database.
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.
I was thinking of implementing the following:
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
域对象应该是自我验证的，这是简单的 OOP。首先就不应该允许它们进入无效状态。正确设计的域对象强制执行所有内部不变量，而不依赖于外部代码。否则封装就会被破坏，你的对象实际上只是一个带有 getter 和 setter 的愚蠢数据容器。
“验证”这个词也可能是一种非常危险的过度概括，它往往会将焦点从域和对象转移到针对 UI 框架选择定制的哑数据容器。这就是为什么DDD 书根本没有提到“验证”问题。我发现考虑不变性比考虑验证更有用。不变量可以像“社会安全号码不能有字母”一样简单，在这种情况下，值对象。或者更复杂，例如“如果在 2 周内未付款，则订单被视为拖欠”，可以将其封装在
order.IsDelinquent()或类似方法中。请注意，在第一种情况下，我们通过实现 SocialSecurityNumber 类来消除对象无效的可能性。在第二种情况下，我们使用无处不在的语言中的“delinquent”一词，而不是通用的“valid”。请参阅类似的答案：1、2、3。附带说明一下，您可能应该对 ASP.NET 人群的所有“DDD”建议持保留态度。 ASP.NET MVC 是一个很棒的框架，但学习材料混淆了域模型和视图模型。大多数示例认为“域”对象与具有 getter 和 setter 的数据容器相同，没有任何封装。 DDD 与技术无关，因此您始终可以通过问自己“这在控制台应用程序中有意义吗？”来进行现实检查。或者“这在非 UI 项目中有意义吗？”。
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.
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 implementingSocialSecurityNumberclass. And in the second case we use the word 'delinquent' from ubiquitous language instead of generic 'valid'. Please see similar answers: 1, 2, 3.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?'.