Шлюз табличных данных в стиле ORM Zend Framework и расширение Zend_Db_Table_Abstract

В кратком руководстве по Zend Framework было изменение от моделей, которые расширяют Zend_Db_Table_Abstract на шаблон шлюза табличных данных.

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

Краткий пример из краткого руководства:

Старый способ:

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();
}

Из-за отсутствия опыта работы с этим стилем программирования мне трудно понять реальные преимущества этого последнего способа; Я понимаю, что этот метод максимально отделяет базу данных от реальной логики, что теоретически должно упростить переход на другую платформу базы данных. Однако я действительно не вижу этого ни в одном проекте, над которым я работаю.

Почти нет сомнений в том, что я что-то упускаю из виду, поэтому я хотел бы услышать ваш совет.

Вопрос:

  • Не могли бы вы объяснить мне, почему (или если) последнее лучше?

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

Заранее спасибо.


person Aron Rotteveel    schedule 30.06.2009    source источник
comment
Не совсем ответ, так что это она. Через несколько лет я понял, что абстракция - это вид искусства, у искусства не всегда есть причины. Сегодня я абстрагирую минимум, который мне нужен, и делаю вещи, поэтому мне придется кодировать как можно меньше, чего в вашем случае, если добавить этот дополнительный уровень абстракции, не произойдет.   -  person Itay Moav -Malimovka    schedule 30.06.2009
comment
Чтобы уточнить, Zend_Db_Table является реализацией шаблона TDG / RDG. Что происходит, так это то, что они переходят на скороговорку Data Mapper.   -  person jason    schedule 30.06.2009


Ответы (2)


Вот мое объяснение того, почему это лучше:

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

Скажем, например, вашему приложению нужно было начать использовать службу SOAP или XML-RPC в качестве источника / хранилища данных. Используя подход сопоставления данных, вы получаете явное преимущество, так как у вас уже есть необходимая структура для добавления этих конкретных интерфейсов уровня данных без значительного (если таковое имеется) вмешательства в существующие модели.

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

Мне просто нравится ощущение, что я создаю что-то, что я считаю лучшим и часто приносит свои плоды.

person Kieran Hall    schedule 01.07.2009
comment
Хотя вы подтверждаете то, о чем я уже думал, это отличный ответ на обе части моего вопроса и определенно помогает мне принять лучшее решение. Спасибо! - person Aron Rotteveel; 01.07.2009
comment
Рад, что смог помочь. Кроме того, если вы хотите продолжить чтение, у Мэтью Вейера О'Финни есть несколько полезных слайдов из его презентации на голландской конференции PHP. slideshare.net/weierophinney/zend-framework-workshop-dpc09 ( слайд 28 - это место, где начинается обсуждение модели). - person Kieran Hall; 01.07.2009
comment
Интересно, что я тоже не могу понять концепцию этого: P это немного похоже на излишнюю инженерию. Насколько отличается изменение сопоставителя вместо изменения модели при изменении источника данных? И на практике, сколько раз это действительно случается, выделяются лишние строки для написания чего-то, что только добавляет мне раздувания: p Но что я знаю - person Chris; 14.11.2010
comment
Вот и мы, 2011 год. И мои мысли таковы: следуйте модели SCRUM (XP), просто добавляйте средства отображения данных, когда вы действительно почувствовали необходимость. Меньше кодирования, больше функциональности и рефакторинга. - person Keyne Viana; 14.05.2011

Это полезно, потому что вы можете делать $insert = new Model_Guestbook($param1, $param2, $param3); - означает, что когда кто-то приходит к проекту, он может легко создать новый экземпляр, не зная структуры базы данных (путем проверки интерфейса источника / модели). Это лишь одно из преимуществ этого метода :)

person Tomáš Fejfar    schedule 01.07.2009
comment
Я не вижу в этом большого преимущества, поскольку это означало бы, что изменение схемы привело бы к необходимости изменять соответствующий код более чем в одном месте. Я все еще чувствую, что что-то резко упускаю из виду. - person Aron Rotteveel; 01.07.2009