OOP 应用程序架构：惰性加载程序位于哪一层？

发布于 2024-08-27 19:18:23 字数 747 浏览 4 评论 0原文

我正在计划为应用程序组件实现继承映射器模式 http://martinfowler.com/eaaCatalog/inheritanceMappers.html

它需要具备的一项功能是为了使域对象引用大量聚合项（10,000 个其他域对象），

因此我需要某种延迟加载集合从聚合根域对象传递到其他域对象。

为了保持我的（php）模型脚本的组织，我将它们存储在两个文件夹中：

MyComponent\
 controllers\
 models\
  domain\     <- domain objects, DDD repository, DDD factory
  daccess\    <- PoEAA data mappers, SQL queries etc
 views\

但现在我绞尽脑汁想知道我的延迟加载集合位于哪里。它似乎跨越了两层。在内部它是一种数据映射器，在外部它是一个域对象。

对于将其放在一个地方而不是另一个地方有什么建议/理由吗？

daccess = 数据访问
DDD = 领域驱动设计模式，Eric Evans - 书籍
PoEAA = 应用程序架构模式模式，Martin Fowler - 书籍

原文

I am planning the implementation of an Inheritance Mapper pattern for an application component
http://martinfowler.com/eaaCatalog/inheritanceMappers.html

One feature it needs to have is for a domain object to reference a large list of aggreageted items (10,000 other domain objects)

So I need some kind of lazy loading collection to be passed out of the aggregate root domain object to other domain objects.

To keep my (php) model scripts organised i am storing them in two folders:

MyComponent\
 controllers\
 models\
  domain\     <- domain objects, DDD repository, DDD factory
  daccess\    <- PoEAA data mappers, SQL queries etc
 views\

But now I am racking my brains wondering where my lazy loading collection sits. It seems to stride both layers. Internally its a kind of data mapper, externally its a domain object.

Any suggestions / justifications for putting it in one place over another another?

daccess = data access
DDD = Domain Driven Design Patterns, Eric Evans - book
PoEAA = Patterns of Application Architecture Patterns, Martin Fowler - book

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

∞琼窗梦回ˉ 2024-09-03 19:18:23

简单的答案是它可能位于您的数据访问层中。

//Domain Object
class Store {
  public function GetGiantListOfProducts() { }
}

//DataAccess Object
class LazyLoadingStore extends Store {
  public function GetGiantListOfProducts() { // function override
     // data access code
  }
}

然后，你的 DAO 可能看起来像这样：

class StoreProvider {
  public function GetStoreById($id) {
     //User expects a list of Store, but you actually return a list of LazyLoadingStore - nobody need know the difference
  }
}

更复杂的答案是 - 这很臭。你真的需要延迟加载东西吗？重新检查你的聚合根可能是一个更好的主意。也许您根本不需要 $store.GetGiantListOfProducts() 方法，并且可以通过更改关系遍历来优雅地回避整个问题，其中每个 Product 都有一个 GetStore() 方法，并且您会得到如下产品列表

class ProductProvider {
  public function GetAllForStore($store) {
     // return list of products for the store
  }
}

：另一方面，如果关系必须按照您最初勾勒出来的方式存在，那么也许延迟加载实际上是一个对该领域有意义的概念？在本例中，它位于域中，并且可能应该有一个比简单的 LazyLoader 更具体、更有意义的名称。

有道理吗？

The simple answer is that it probably sits in your DataAccess layer.

//Domain Object
class Store {
  public function GetGiantListOfProducts() { }
}

//DataAccess Object
class LazyLoadingStore extends Store {
  public function GetGiantListOfProducts() { // function override
     // data access code
  }
}

Then, your DAO might look like this:

class StoreProvider {
  public function GetStoreById($id) {
     //User expects a list of Store, but you actually return a list of LazyLoadingStore - nobody need know the difference
  }
}

The more complicated answer is - this reeks. Do you really need to lazy load stuff? It might be a better idea to re-examine your aggregate roots. Perhaps you don't need a $store.GetGiantListOfProducts() method at all and could gracefully sidestep the entire problem by changing the relationship traversal where each Product has a GetStore() method and you get a list of products like so:

class ProductProvider {
  public function GetAllForStore($store) {
     // return list of products for the store
  }
}

On the other hand, if the relationship has to exist the way that you initially sketched it out, then perhaps lazy loading is actually a concept that is meaningful to the domain? In this case it lives in the domain and should probably have a more specific and meaningful name than simply LazyLoader.

Makes sense?

回复收藏 0 原文