本文介绍了DDD:更新实体的多个属性的指南的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!
问题描述
因此,我决定学习DDD,因为它似乎可以解决我一直面临的一些架构问题。虽然有很多视频和示例博客,但我还没有遇到一个可以指导我解决以下场景的:
假设我有一个实体
public class EventOrganizer : IEntity
{
public Guid Id { get; }
public string Name { get; }
public PhoneNumber PrimaryPhone { get; }
public PhoneNumber AlternatePhone { get; private set; }
public Email Email { get; private set; }
public EventOrganizer(string name, PhoneNumber primaryPhoneNr)
{
#region validations
if (primaryPhoneNr == null) throw new ArgumentNullException(nameof(primaryPhoneNr));
//validates minimum length, nullity and special characters
Validator.AsPersonName(name);
#endregion
Id = new Guid();
Name = name;
PrimaryPhone = primaryPhoneNr;
}
}
我的问题是:假设这将被转换并馈送到MVC视图,并且用户想要更新AlternatePhone、电子邮件和许多其他属性,这些属性对于给定的有界上下文在此实体中存在是有意义的(为简洁起见,未显示)
我知道正确的指导是每个操作都有一个方法,但是(我知道它有点反模式)我忍不住想知道这是否会最终触发对数据库的多个更新调用。
这是如何处理的?最终,是否会有某种东西将我的EventOrganizer映射到某个东西-比如DbEventOrganizer,并收集对域实体所做的所有更改,并一次性应用这些更改?
推荐答案
ddd更适合基于任务的UI。你所描述的是非常粗俗的。在您的示例中,各个属性被视为独立的数据字段,其中一个或多个可以通过单个通用业务操作(更新)进行更新。
如果您想要成功地使用DDD,则必须对您的域执行比此更深入的分析。为什么有人要一起更新所有这些字段?用户试图通过这样做来实现哪些隐含的业务操作呢?是否有更具体的业务流程通过同时变更PrimaryPhone
、AlternatePhone
、Email
来表示?
EventOrganizer
的ContactInformation
?如果是这种情况,那么您可以在EventOrganizer
上建模单个ChangeContactInformation
操作。然后,您的UI将发送ChangeContactInformation
命令,而不是update
命令。
至于聚合根(AR)的持久性,如果您使用的是RDBMS,这通常由NHibernate这样的ORM处理。但是,还有其他方法可以在RDBMS中保存AR,如事件源、NoSQL数据库,甚至storing JSON或任何其他数据交换格式。
这篇关于DDD:更新实体的多个属性的指南的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持编程学习网!
本站部分内容来源互联网,如果有图片或者内容侵犯您的权益请联系我们删除!