gpt4 book ai didi

c# - 持续无知领域层

转载 作者:太空狗 更新时间:2023-10-29 23:41:06 24 4
gpt4 key购买 nike

我的编程语言是 C#。我有一个关于我的域模型中的持久性无知的问题。

假设我有一个像这样的 person 类:

public class Person
{
private string email;

public string Email
{
get { return email; }
set { email = value; }
}

public Person(string email)
{
this.email = email;
}
}

现在,在我的域模型中,有一条规则,即不能有两个人拥有相同的电子邮件地址。因此,在实例化一个新人时,这需要在更改电子邮件属性时进行验证。所以我想知道您将如何在持久性无知域层中解决此类验证。我目前所做的是使用工厂模式进行人员实例化,我在其中注入(inject)人员存储库。在那里我可以搜索具有相同电子邮件地址的其他人。像这样:

public class PersonFactory
{
private static readonly IPersonRepository personRepository;

public Person CreateNewPerson(string email)
{
Person personWithSameMail = personRepository.GetPersonByEmail(email);

if (personWithSameMail != null)
throw new ApplicationException("Email already exists.");

return new Person(email);
}

public PersonFactory(IPersonRepository personRepository)
{
this.personRepository = personRepository;
}
}

但是使用这个解决方案,仍然没有涵盖更改人员电子邮件地址时的检查(这可以是一个有效的业务案例)。此外,Person 类仍然公开一个公共(public)构造函数,并且通过绕过工厂,仍然可以使用具有重复电子邮件地址的人。

对此有什么优雅的解决方案吗?

附言致所有以数据为中心的人:不,我不想在数据访问层验证欺骗性电子邮件;)

更新:

可能这整个问题已经过时了。根据域模型上下文检查重复电子邮件总是需要知道所有人的“东西”——根。 “某物”可以是地址簿,也可以是包含所有具有电子邮件地址的人的整个世界。因此,也许我混淆了程序员对技术上优雅的问题解决方案的需求,这只是因为缺乏完整且经过深思熟虑的领域模型而存在。这里可以这样吗?不仅仅是一个有电子邮件地址的人在太空中漂浮(嘿,太空将是我在这里的聚合根;))只是为了存在的乐趣?但如果这是一个真实的业务案例,如地址簿应用程序,地址簿将是个人的聚合根,因此可以检查其内部集合中的所有人,以确保没有重复的电子邮件地址。

最佳答案

我不是 DDD 专家,但我的看法是这样的。

首先,对我来说,您的设计中最大的缺陷是允许实体上的 setter。这意味着您可以更改实体的状态,而聚合根不知道它。我会重构它,删除 setter 并在对象创建时通过构造函数设置它。

还有一点。个人实体不应该对电子邮件进行验证(以检查电子邮件是否已被使用的形式),因为如果她是聚合的根,它只能知道自己的状态和相关的子实体。然后你应该从实体中引用存储库,这对我来说是糟糕的设计。我认为这就是您使用工厂的原因。

我认为验证应该首先在 UI 中进行,以尽快失败。但这还不够。当持久化你的域状态时,你应该强制执行这个人有一个唯一的电子邮件的规则。我认为验证应该发生在域服务中,例如名为 PersonRegistrationService 的域服务,它会引用 IPersonRepository 并且在添加人员实体之前为了使其收集持久化,它会首先检查该人的电子邮件是否是唯一的。如果不是,我会通知用户错误并且不添加该实体。

你怎么看?

关于c# - 持续无知领域层,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/8398049/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com