OOP应用程序体系结构:惰性加载程序位于哪一层? [英] OOP App Architecture: Which layer does a lazy loader sit in?

问题描述

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

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

域对象需要具有的一大功能是引用大量的聚集项目(其他10,000个域对象)

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.

为使我的(php)模型 脚本保持井井有条，我将它们存储在两个文件夹中:

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 =数据访问
• DDD =域驱动设计模式，埃里克·埃文斯(Eric Evans)-书
• PoEAA =应用程序体系结构模式的模式，Martin Fowler-书

推荐答案

简单的答案是它可能位于您的DataAccess层中.

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
  }
}

然后，您的DAO可能如下所示:

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
  }
}

---

更复杂的答案是-这很蠢.您是否真的需要延迟加载内容?重新检查您的聚合根可能是一个更好的主意.也许您根本不需要$ store.GetGiantListOfProducts()方法，并且可以通过更改每个产品都有GetStore()方法的关系遍历来宽容地避免整个问题，这样您就可以得到如下产品列表:

---

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
  }
}

另一方面，如果关系必须以您最初绘制关系的方式存在，那么惰性加载实际上是对领域有意义的概念吗?在这种情况下，它位于域中，并且应该具有比LazyLoader更为具体和有意义的名称.

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.

有道理吗?

这篇关于OOP应用程序体系结构:惰性加载程序位于哪一层?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！