Архитектура приложения ООП: В каком слое находится ленивый загрузчик? - PullRequest
Новая
       40

Архитектура приложения ООП: В каком слое находится ленивый загрузчик?

2 голосов
/ 02 апреля 2010

Я планирую внедрение шаблона Inheritance Mapper для компонента приложения 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 = Шаблоны проектирования, управляемые доменом, Эрик Эванс - книга
  • PoEAA = Шаблоны шаблонов архитектуры приложений, Мартин Фаулер - книга

Ответы [ 2 ]

2 голосов
/ 06 апреля 2010

Простой ответ заключается в том, что он, вероятно, находится на вашем уровне DataAccess. 

//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 (), и он может изящно обойти всю проблему, изменив обход отношений, где у каждого продукта есть метод GetStore (), и вы получите список продуктов, например: 

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

С другой стороны, если отношения должны существовать так, как вы их изначально набросали, то, возможно, ленивая загрузка на самом деле является концепцией, которая имеет смысл для области? В этом случае он находится в домене и, вероятно, должен иметь более конкретное и значимое имя, чем просто LazyLoader.

Имеет смысл?

1 голос
/ 02 апреля 2010

Вы пишете свой слой доступа к данным? Если это так, вы можете попробовать методику, изложенную здесь:

http://mynerditorium.blogspot.com/2010/01/practical-pi-lazy-loading-for-your-hand.html

Обратите внимание, что я следую больше стандартному шаблону DAO, но я думаю, что вы могли бы применить ленивые биты загрузки к вашему конкретному шаблону.

При использовании вышеописанного метода я прикрепляю коллекцию отложенной загрузки к агрегату в DAL агрегата. Однако я считаю, что коллекция является членом уровня домена.

...