完全是域建模的新手,不知道从哪里开始

时间:2009-09-22 20:47:25

标签: c# domain-driven-design modeling

我正在开始一个新项目,我想首先建模客户端需要存储的数据。但是,我不知道从哪里开始。到目前为止,我正在尝试模拟两个简单实体EventAddressEvent可以有多个Addresses,而Address可以与多个Events相关联。这就是我所拥有的:

public class Event
{
    public int Id { get; set; }
    public string Name { get; set; }
    public string Description { get; set; }
    public List<Address> Addresses { get; set; }
}

public class Address
{
    public int Id { get; set; }
    public string Street { get; set; }
    public string Zip { get; set; }
    public List<Event> Events { get; set; }
}

但是,当我尝试为这两个对象创建测试存储库时,我遇到了一个问题。它们具有循环依赖关系:Event无法填充其Addresses列表,直到Address完全填充,但Address无法填充其Events列表,直到Events已完全填充。这让我相信我不知道自己在做什么。

我一直在阅读很多关于POCO,DTO,DAO和DDD的内容,但无论我多么努力地理解它们,这些概念对我来说都没有多大意义。我刚刚从大学毕业,直到一周前我还没有听说过“域名模型”一词。

从概念上讲,我想要做的是首先创建表示我需要存储的数据类型的类(我相信Entities)。这些类还将包含验证逻辑(这是POCO吗?)。之后,我想设置存储库来访问这些对象的集合并填充它们可能具有的任何关系(例如,Event将填充Addresses的列表)[这是持久性无知吗? ]。只有在完成所有这些之后,我才想创建数据库来保存数据(通过DAO?ORM是DAO?我如何使用LINQ-To-SQL来执行此操作?)。 IoC在哪里适合所有这些,或者如果我知道我的后端永远不会改变而且我总是只打出一个数据库,那么它根本不适合吗?

如果它已经不明显,我对我应该从哪里开始感到困惑。我对我想做的事情有一个很好的概念,我根本不知道如何实现它。有人可以给我一个良好的起点建议吗?感谢。

3 个答案:

答案 0 :(得分:4)

在您给出的示例中,似乎地址不应包含对事件的引用,但您需要一个可以查找给定地址事件的存储库。该地址看起来更像是一个Value对象。如果要查看哪些值对象以及它们与实体对象的区别,可以在线获得book by Eric Evans部分可用的部分。

就IOC容器而言,它们在消除锅炉板工厂代码方面非常有用,工厂代码负责为您创建对象。当您拥有IOC容器时,开发人员会向容器询问您需要的类的实例。这样就无需自己编写工厂。

持久性无知,因为我理解它是对象不关心持久性,它们是存储库模式的来源。您使用存储库作为获取,保存,更新和删除对象的手段。对象本身并不关心持久性。

我会将POCO(普通旧CLR对象)视为具有行为但不关心交叉问题的对象。 DTO(数据传输对象)通常是几乎没有行为的对象,其目的是将数据从A点携带到B点.DAO(数据访问对象)用于从数据库(即存储库)访问数据。 DDD(领域驱动设计)是一套设计原则,可以引导您完成正确的设计过程,同时根据您构建的域来考虑您的软件。

我希望这会有所帮助。

答案 1 :(得分:0)

正如迈克尔所指出的,地址在许多领域都是一个“价值对象”,但我会假设你有完全有效的论据,使它成为“实体”(id)和“聚合根”(存储库)。

我自己就是NHibernate用户,并不知道Linq-to-SQL的所有细节。尽管NHibernate支持多对多映射,但强烈建议您(如果我从Hibernate in Action中正确记住它)在域模型中包含关联类(即表示引用表的类)。

事情变得更加明确,以及协会的未来属性,例如:主要地址的标志,更容易添加。

使用新模型(事件(1) - (x)EventAddress(x) - (1)地址),请记住您必须自己保留双向关联,例如遵循Fowler的UML Distilled主从模式。

使用NHibernate,你也可以告诉它哪一端是反向(奴隶),但你必须查阅Linq-to-SQL的文档,以了解它是如何做同样的技巧。

您可以在此处详细了解主从关系:http://blog.lowendahl.net/?p=88

答案 2 :(得分:0)

开始时不要过多担心法律条文。

有一些基本原则导致了模式和方法的字母表,如果你坚持这些原则,你会看到你的代码在大多数时候至少倾向于其中的一部分。

如果您担心实际解决问题的模式和概念,您可能会冒险选择一种模式,这种模式可以解决您遇到的问题。

在您要描述的示例中,您需要获取每个事件的地址列表,并且您需要获取每个地址的事件列表。

您如何对其进行建模,以便您的代码的其余部分,您的应用程序将面临的任何现在和将来的要求,可以轻松可靠地使用这两件事?根据您的特殊需求,最佳解决方案是什么?

首先考虑一下,您可能经常发现您的解决方案类似于众所周知的模式。