В чем преимущество использования DataMapper с Zend_Db_Table по сравнению с использованием только DataMapper с адаптером базы данных напрямую?

Question

Я просматривал краткое руководство по Zend Framework, и в своем демонстрационном коде они используют средство отображения данных, которое использует Zend_DB_Table для доступа к базе данных (см .: http://framework.zend.com/manual/en/learning.quickstart.create-model.html). Похоже, что Zend_DB_Table не использует подготовленные операторы илипредоставьте способ использовать транзакции. Поэтому я склоняюсь к тому, чтобы просто использовать datamapper напрямую с zend_db_adapter. Имея это в виду, кто-то может посоветовать ситуации, в которых Zend_DB_Table будет выгоден?*

Answer 1

В общем, я вижу Zend_Db_Table как быстрый и простой способ выполнения запросов с одной таблицей .

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

Конечно, в любом случае, безусловно, желательно оставить все это позади модели или картографаили уровень обслуживания.Затем, когда вы измените эти детали реализации, скажем, начните с реализации Zend_Db_Table, но позже поймете, что вам нужно объединить данные из другой таблицы, чтобы вы переходили к запросам на основе адаптера - ничего из этого не повлияет на потребителеймодель / картограф / сервис.

Надеюсь, это поможет.

Answer 2

На мой взгляд, вы хотите, чтобы ваш код был как можно более объектно-ориентированным для удобства обслуживания и тестирования.

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

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

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

В любом случае, надеюсь, это поможет:)

Answer 3

1. Например, если вы хотите изменить данные из базы данных
   
2. Или, если вам нужно отправлять письма людям о записях вставок и т. Д.