MVC с DAO / VO - с каким DAO должен разговаривать контроллер? - PullRequest
2 голосов
/ 25 февраля 2012

Справочная информация:

У меня проблема с шаблоном проектирования, которую я надеялся решить. Я программирую на PHP, но считаю, что DAO / VO популярен на Java.

Я использую MVC уже много лет. Я разработал магазин, который был MVC, но использовал процедурное программирование. Поэтому недавно я решил снова разработать тележку, используя OO.

Проблема:

Проблема, с которой я столкнулся, заключалась в том, что в моем классе Product не было смысла иметь метод RetrieveAll (). Например. Если бы у меня было 10 продуктов в списке, из какого экземпляра я бы вызвал метод RetrieveAll ()? У меня было бы 10 вариантов.

Решение:

Таким образом, я нашел модель DAO / VO. Если я недостаточно исследовал этот шаблон - я считаю, что каждая таблица БД должна иметь Model + DAO. Ни одна модель или DAO не должны знать о другом наборе моделей или DAO. Таким образом, будучи заключенным в капсулу. Шаблон имеет смысл, отрывая слой базы данных от Модели.

Тем не менее. В корзине моим продуктам назначены категории. Категория может быть электроника, одежда и т. Д.

Есть 3 таблицы: - Категория (pid, имя) - пункт категории (iid, name) - Категория Ссылка (pid, iid)

Из подхода MVC не имеет смысла, с каким DAO контроллер должен разговаривать?

Должно ли это быть:

  • Контроллер связывается со всеми 3 DAO и затем возвращает соответствующую структуру данных в View?
  • Или должен ли DAO общаться друг с другом (как-то) и возвращать единственную структуру обратно в Контроллер?

Пожалуйста, смотрите здесь, например (изображение)

Ответы [ 3 ]

1 голос
/ 25 февраля 2012

Я тоже не эксперт по DDD, но это мое мнение. Это ситуация, когда применяется шаблон хранилища. По сути, Домен не знает и не заботится ни о DAO, ни о чем-либо еще, касающемся эксплуатации. Максимум знает об интерфейсе репозитория (который должен быть реализован на уровне инфраструктуры).

Контроллер знает о домене и хранилище. Репозиторий инкапсулирует все, что связано с БД, приложение знает только о самом репозитории (фактически должен быть введен интерфейс как фактическая реализация). Затем в хранилище у вас есть DAO, как вы считаете нужным. Хранилище получает и отправляет обратно только объекты приложения / домена, ничего не связанного с реализацией базы данных.

В двух словах, все, что связано с БД, является частью и является подробностью реализации репозитория.

1 голос
/ 25 февраля 2012

Я не уверен, что вы подразумеваете под VO. Это объект ценности?

Я большой поклонник подхода DDD (доменного дизайна) (хотя я не считаю себя гуру в этом). В DDD у вас есть так называемые Услуги . Сервис Это действие, которое работает в вашем домене и возвращает данные. Сервис инкапсулирует манипуляции с данными вашего домена.

Вместо того, чтобы контроллер мог выполнять всю логику домена, например, какие элементы извлекать, какие DAO использовать и т. Д. (Почему контроллер должен заботиться о Домене в любом случае?), Он должен быть инкапсулирован в самом Домене, в DDD дело внутри службы.

Так, например, вы хотите получить все элементы категории категории "электроника". Вы можете написать контроллер, который выглядит следующим образом (извините, если код имеет неверный синтаксис, для примера):

public function showItemsByCategoryAction($categoryName) {
  $categoryId = $categoryDAO->findByName($categoryName);
  if(is_null($categoryId)) {
    //@TODO error
  }

  $itemIds = $categoryLinkDAO->getItemsByCategoryId($categoryId);
  if(empty($itemIds)) {
    //@TODO show error to the user
  }

  $items = $categoryItemDAO->findManyItems($itemIds);

  //@TODO parse, assign to view etc
}

Это создает как минимум две проблемы:

  1. Контроллер FSUC (Жир, тупой уродливый контроллер)
  2. Код не подлежит повторному использованию. Если вы хотите добавить еще один уровень представления (например, API для разработчиков, мобильная версия веб-сайта и т. Д.), Вам придется скопировать и вставить тот же код (ожидайте, что часть рендеринга представления), и в конечном итоге вы придете к что-то, что будет инкапсулировать этот код, и это то, для чего предназначены Сервисы.

С уровнем Services тот же контроллер может выглядеть как

public function showItemsByCategoryAction($categoryName) {
  $service = new Item_CategoryName_Finder_Service();
  $items = $service->find($categoryName);

  if(empty($items)){
    //@TODO show empty page result, redirect or whatever
  }

  $this->getView()->bind('items', $items);
}

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

Теперь некоторые люди считают, что контроллер не должен ничего знать о DAO и взаимодействуют с Доменом только с помощью Сервисов, другие говорят, что можно совершать вызовы DAO из контроллера, нет строгих правил, решать, что лучше подходит для вы.

Надеюсь, это поможет вам! Удачи:)

0 голосов
/ 26 июля 2012

тип возвращаемого значения можно учитывать при принятии решения, какой метод дао должен идти к какому классу дао, следовательно, с каким дао должен обращаться контроллер:

Реализация одного класса DAO для каждого объекта данных более понятна,

Операции CRUD должны входить в классы Дао, C-Create, R-Read, U-Update, D-Delete

Операции чтения не похожи на «Создать», «Обновить», «Удалить», в большинстве случаев операции чтения имеют различный вид при рассмотрении того, что они возвращают.

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

ниже приведены некоторые юридические лица и есть Дао

Exchange -> ExchangeDao
Company -> CompanyDao
Stock -> StockDao
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...