В Quickstart Zend Framework произошли изменения от моделей, которые расширяют Zend_Db_Table_Abstract до шаблона Zend_Db_Table_Abstract Data Tableway.
Лично у меня не было большого опыта работы с этим шаблоном, и я продолжаю слышать, что это скорее всего будет использоваться вместо старого.
Краткий пример из быстрого запуска:
Старый путь:
class Default_Model_Guestbook extends Zend_Db_Table_Abstract { protected $_name = 'tablename'; // do stuff }
Новый путь:
// The actual model class Default_Model_Guestbook { protected $_comment; protected $_created; protected $_poster; // list continues with all columns } // Dbtable for this model class Default_Model_DbTable_Guestbook extends Zend_Db_Table_Abstract { /** Table name */ protected $_name = 'guestbook'; } // Mapper class Default_Model_GuestbookMapper { public function save($model); public function find($id, $model); public function fetchAll(); }
Из-за моего отсутствия опыта в этом стиле программирования мне трудно понять фактические выгоды от этого последнего способа; Я понимаю, что этот метод как можно больше отделяет базу данных от фактической логики, что теоретически облегчает переход на другую платформу базы данных. Тем не менее, я действительно не вижу этого в любом проекте, над которым я работаю.
Я почти не сомневаюсь, что я что-то пропускаю, поэтому я бы хотел услышать ваши советы.
Вопрос:
Может кто-нибудь, пожалуйста, объясните мне, почему (или если) последнее лучше?
Должен ли я перейти от старого пути к новому, или есть все еще правильные причины для прикрепления к моделям, которые представляют таблицы базы данных?
Заранее спасибо.
Вот мое объяснение, почему это более эффективная практика:
Я считаю, что реальная выгода от этого – возможность беспрепятственного изменения ваших источников данных. Добавляя дополнительный уровень абстракции в ваше приложение, ваши модели больше не представляют таблицу базы данных (она никогда не должна иметь, на мой взгляд), поскольку модель должна представлять собой представление данных (а не шлюз к ней). Уровень доступа к базе данных должен быть инкапсулирован моделью, что обеспечивает большую гибкость.
Скажем, например, ваше приложение должно было начать использовать SOAP-службу или XML-RPC, поскольку это источник данных / хранилище. Используя подход картографирования данных, вы явно отличаетесь друг от друга, поскольку у вас уже есть необходимая структура для добавления этих интерфейсов уровня данных без особых (если есть) помех вашим существующим моделям.
Если вы это сделаете? Это прагматичный вопрос. Лично мне нравится иметь душевное спокойствие, что я развиваю то, что является гибким, и следует (согласованным) лучшим практикам. Тем не менее, только вы знаете, будет ли создание более гибкого приложения сделать ваши проекты более легкими, как сейчас, так и в будущем, для создания и обслуживания.
Для меня мне просто нравится, что я что-то создаю, я считаю, что это лучшая практика, и она часто выплачивает дивиденды.
Это полезно, потому что вы можете сделать $insert = new Model_Guestbook($param1, $param2, $param3); – означает, что когда кто-то приходит в проект, он может легко создать новый экземпляр без знания структуры базы данных (путем проверки интерфейса source / by model). Это лишь одно из преимуществ этого метода: