Моделирование в Zend Framework - PullRequest
Новая
       35

Моделирование в Zend Framework

3 голосов
/ 17 июля 2011

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

В настоящее время я реализую два класса для каждой сущности (например, класс 'author' и 'author'), где класс множественного числа содержит такие методы, как «выборка авторов» (используя Zend_Db_Table_Abstract для множественного числа и Zend_Db_Table_Row_Abstract для единственного числа).

Однако я понял, что часто видел такие методы, как функции «выборка / список» в объекте одной сущности, что выглядит довольно аккуратно с точки зрения того факта, что мне не нужно иметь столько файлов.

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

Ответы [мнения] с благодарностью получены!

Роб Ганли

1 Ответ

4 голосов
/ 17 июля 2011

Лично я предпочитаю модель под названием Person, которая фактически представляет отдельного человека, и модель, подобную PersonCollection, для представления совокупности людей. Ни в том, ни в другом случае у меня не было бы методов для выборки / получения этих объектов. Скорее я бы поместил эти методы в класс PersonRepository или PersonMapper.

Это действительно моя самая большая проблема с ActiveRecord в качестве шаблона для моделирования. Наличие таких методов, как find() и save(), открывает двери для таких методов, как getPersonByName(), getPersonsWithMinimumAge() и т. Д. Эти методы великолепны, с ними все в порядке, но я думаю, что семантически они лучше работают на картограф или класс хранилища. Пусть Model на самом деле моделирует, оставит постоянство и поиск для картографов и репозиториев.

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

  1. Person - фактически моделирует человека
  2. PersonCollection - расширяет некоторый класс Abstract Collection, каждый элемент класса Person
  3. PersonMapper - сохранение и извлечение Person объектов и PersonCollections

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

Вероятно, неудивительно, что меня тянет к Doctrine2. EntityManager там функционирует как единая точка контакта для сохранения и поиска. Затем я могу создать репозитории и службы, использующие EntityManager для пользовательских функций. И тогда я могу наложить на помощников действий или фабрики или контейнеры внедрения зависимостей, чтобы упростить получение / создание этих репозиториев и сервисов.

Но я знаю, что стандартный подход ActiveRecord довольно распространен, понятен и очень распространен. Используя его, вы можете получить хорошие результаты и найти множество разработчиков, которые сразу поймут это и смогут с ним хорошо работать.

Как и в большинстве случаев, YMMV.

...