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

Я планирую реализовать шаблон 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 = Domain Driven Design Patterns, Эрик Эванс - книга
  • PoEAA = Шаблоны шаблонов архитектуры приложений, Мартин Фаулер - книга

person Community    schedule 01.04.2010    source источник


Ответы (2)


Простой ответ заключается в том, что он, вероятно, находится на вашем уровне 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.

Имеет смысл?

person Community    schedule 06.04.2010
comment
Привет спасибо за ответ. Одна вещь, в вашем первом примере LazyLoadingStore расширяет Store? Возможно, здесь опечатка. Точно сказать не могу. После некоторого размышления я думаю, что вы были правы во второй части своего ответа в том смысле, что это что-то больше «домен», чем «доступ к данным». - person JW.; 08.04.2010
comment
Ага, это была опечатка. Хороший улов. Я починил это. Прошло много времени с тех пор, как я программировал php, поэтому синтаксис дается нелегко. - person George Mauer; 08.04.2010
comment
В конце концов я решил реализовать DDD repository (на уровне домена) и используйте Repository Iterator, который извлекает Collections. - person JW.; 02.11.2011

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

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

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

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

person Community    schedule 01.04.2010
comment
Спасибо за это. Да, собственноручно накатываю на старый беспорядок. Перейдя по вашей ссылке, я теперь разрываюсь между: * ayende.com/Blog / archive / 2006/05/12 / и * joelonsoftware.com/articles/fog0000000069 .html - person JW.; 02.04.2010
comment
Вы разрываетесь между советами, данными в постах возрастом 4 и 10 лет соответственно? Ой вей - person George Mauer; 08.04.2010
comment
Да, я бы рассмотрел совет, которому 4, 10 или даже тысячу лет (хотя я не особо религиозен и никогда бы не принял его как доктрину без проверки альтернатив) - person JW.; 26.04.2010