Модели ZF правильное использование

Question

Я борюсь с тем, как понять правильное использование моделей. В настоящее время я использую наследование Db_Table напрямую и объявляю всю бизнес-логику там. Я знаю, что это не правильный способ сделать это.

Одним из решений было бы использование Doctrine ORM, но для этого требуется кривая обучения и все текущие компоненты, которые я использую, должны быть переписаны paginator и auth. Также Doctrine1 добавляет еще дюжину классов, которые нужно загрузить.

Итак, текущая самая чистая реализация, которую я видел, - это использование классов Data Mapper между так называемой моделью и DbTabel. Я еще не реализовал это, поскольку кажется, что я пишу другой ORM. Но пример может быть что-то вроде этого: таблица SQL User

• здесь создайте класс с сеттерами, геттерами, бизнес-логикой / model / User.php
• data mapper / model / mapper / UserMapper.php , функциональность в основном записывает все обновления, сохраните действия здесь.
• источник данных / model / DbTable / User.php расширяет Db_Table_Abstract

Проблемы связаны с отношениями между другими моделями.

Answer 1

Я считаю, что не было бы полезно, если бы мои модели расширяли Db_Table, но вместо этого использовали композицию.Это означает, что моя модель «имеет Db_Table, а не« Db_Table ».

Таким образом, мне гораздо проще ссылаться на несколько таблиц в одной модели, что является распространенным требованием.Этого достаточно для простого проекта.В настоящее время я занимаюсь разработкой более сложного приложения и использовал шаблон Data Mapper и обнаружил, что он упростил мой код больше, чем я мог бы поверить.

В частности, я создал класс, который обеспечивает весь доступ кбаза данных и предоставляет такие методы, как getUser () и т. д. Таким образом, если БД изменяется, или мой клиент хочет что-то глупое, как хранение записей в XML, или мы разделяем серверы, или что-то еще, что мне нужно переписать только один класс.1008 * Опять же, мои модели не расширяют этот класс, но его экземпляр назначается в качестве свойства во время построения.

Answer 2

Я бы сказал, что «правильный» путь зависит от ситуации. Следуя принципам YAGNI и KISS, не стоит слишком усложнять настройку модели, если вы не уверены, что это принесет вам пользу в долгосрочной перспективе.

Какое приложение вы разрабатываете? Как ваша текущая настройка расширения Db_Table сдерживает вас?