【问题标题】:Is it okay to use attributes and IValidatableObject on domain objects?可以在域对象上使用属性和 IValidatableObject 吗?
【发布时间】:2015-12-20 23:02:10
【问题描述】:

我习惯于使用实体对象,现在我正在切换到 DDD 原则,因此我将开始使用域对象。

我习惯用RequiredAttributeStringLengthAttribute等属性来装饰我的实体对象的属性。我也习惯在我的实体对象上实现IValidatableObject

我的问题是 - 在我的域对象上使用属性和 IValidatableObject 是否可以接受?与DDD一致吗?谢谢。

【问题讨论】:

标签: asp.net-mvc domain-driven-design


【解决方案1】:

您的域模型应该只适用于业务概念,它不应该与 DAL 或 View 有任何直接关系。您应用的属性意味着您将域模型用作视图模型。创建单独的视图模型。不要使用描述存储模型的实体对象作为域的根类。为域对象创建新类。添加明确解释业务的方法 -

ChangeLastName(string newName) 而不是obj.LastName = "Some name"

CreateNewPost(string text,string author) 而不是obj.Posts.Add(..)

您可以编写一些扩展方法来进行映射,例如ToViewModel,或者做一些其他的事情。一个有趣的设计/基础架构模式是 CQRS 和 EventSourcing。它允许您避免映射,但有一些缺点(例如聚合之间的事务)。最后 - 在大多数情况下更适合简单的 CRUD 操作 - 快速、简单、容易。

【讨论】:

  • @AntonPutao 仍然没有回答问题。我认为这个问题已经暗示了视图模型和域模型,其中视图模型映射到域模型。在域层,它仍然需要重新验证该属性是否是一个有效的电子邮件地址。这可以通过使用属性装饰属性并检查 ModelState 是否有效在视图模型中轻松完成。一旦验证了视图模型并将其映射到域模型以供域服务使用,那么现在上面的问题,可以在域模型中使用属性和 IValidateable 吗?
【解决方案2】:

从 DDD 的角度来看,最好通过在实体的行为方法中使用 exceptions 或通过实现 规范 来保持域模型的精简>通知模式来强制执行验证规则。

在将接受输入的ViewModel 类(而不是域实体)中的应用程序层使用数据注释是有意义的,以允许在 UI 层内进行模型验证。但是,这不应该在排除域模型中的验证时进行。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2018-05-31
    • 1970-01-01
    • 1970-01-01
    • 2013-11-21
    • 2015-12-23
    • 2011-10-22
    • 1970-01-01
    • 2013-12-17
    相关资源
    最近更新 更多