遍历方向和性能

我们举一个例子，我们有两个实体：ServiceProvider和TelephoneNumber。该系统允许服务提供商添加电话号码。由服务提供商添加的每个电话号码由TelephoneNumber的实例表示。所以，我有这两个实体之间的关联。目前，我已经决定一个TelephoneNumber实例与一个服务提供者关联。我还决定这两个实体属于相同的集合，其中ServiceProvider是聚合根（一个参数是TelephoneNumber生命周期取决于ServiceProvider实体）。遍历方向和性能

我的问题是关于协会的遍历方向。我事先知道服务提供商可能会添加数百万个电话号码。

如果关联的遍历方向是从ServiceProvider到TelephoneNumber，如何以有效的方式实现？在ServiceProvider实体中存储一组电话号码效率不高（特别是对于内存）。可以使用延迟加载，但它会通过使用支持它的框架（例如Hibernate）来限制实现选项。

在一个已知的例子中，我们有Customer和Order实体，通常会选择从Order到Customer的单向关联。如果关联的遍历方向是从TelephoneNumber到ServiceProvider，那么如何执行TelephoneNumber的CRUD操作？我想我们需要使用TelephoneNumberRepository？但是，我经常看到应该仅为聚合根定义存储库，因为我们通常会获得聚合根实例，并且我们通过它与域模型进行通信。

感谢

来源

2012-04-03 Mickael Marrache

您使用的是关系数据库吗？ – 2012-04-03 09:53:26

@PreetKukreti是的，我们将在第一阶段使用关系数据库。 – 2012-04-03 11:31:24

添加完后，您将如何访问电话号码？你会大量加载它们，只是其中一些符合特定标准...？你确定没有什么比电话号码更多的电话号码吗？周围没有其他物体？ – guillaume31 2012-04-04 15:33:15

由于需要根据一些标准来访问电话号码，我不会吃惊地看到一个PhoneNumberRepository即使它不是一个聚合根。

另一方面，您可以直接在ServiceProvider中具有适当的FindPhoneNumberBy ...（）方法。令我困扰的是，您无法一次加载大量电话号码，这意味着您必须在ServiceProvider中引入某种性能管理（延迟加载/枚举等），从而打破关注点分离。

独立存储库的优点是，虽然接口将位于域层，但其具体实现将驻留在基础结构层中，该层很好地将FindPhoneNumberBy ...（）方法的契约与底层读取技巧。总而言之，我无法真正看到一个比Repository更合理的候选人来处理这种东西。

来源

2012-04-05 14:04:27 guillaume31

遍历方向和性能

回答

相关问题