Предположим что мы используем ZF table, кастомизируем его row и определяем там бизнес логику.
Паттерн Row Data Gateway выполняет роль удобного взаимодействия с БД, бизнес-логика, как правило, реализуется в другом слое, который расположен над этим.
Я лишь указал вам на несовершенство передачи данных в виде массива и на то, что при правильном оо-проектировании данные должны передаваться в виде объектов. Так же я вам показал к чему приводит на практике использование такого подхода.
Как это уходят в прошлое? Большинство современных DSLR-камер оснащено как раз кмоп-сенсорами. А вот пзс-матриц в этом сегменте почти не осталось, видимо, из-за сильных шумов при высоких ISO.
Я заметил, что есть люди, которые всё ещё не используют преимущества ООП
Например, отдавая данные из слоя бд в виде массива, а не объекта вы тоже не используете эти преимущества. Представьте что вам понадобилось в модель товара добавить метод вычисления НДС исходя из стоимости, в нормальной ситуации это просто решалось наследованием от Zend_Db_Table_Row (с добавлением нужного метода getVat()) и указанием нового класса в поле protected $_rowClass в классе таблицы. Для всего кода, который уже работает с товаром ничего не изменилось бы, просто добавилась бы возможность использования нового метода. С вашим же подходом вы прилепили бы процедурный костыль и вместо использования $table->getItemById($id)->getVat() использовали бы $item = $table->getItemById($id); $table->getVatByPrice($item['price']);
Чувствуете разницу?
К gae-приложению нельзя привязать домен второго уровня. Я так понимаю что digital-mode.ru ведет на другой сервер, на котором висит редирект на www.digital-mode.ru?
Ну тогда странно, что говорится именно об apache и linux. Может быть работают боты, использующие связку 0-day эксплоитов под апач и линукс? Тогда масштабы могут быть действительно большие.
Полностью согласен. Очень странно что автор поставил всего две звезды в «необходимость» данному пункту. Лично я пользуюсь этим инструментом очень активно.
P.S. Кстати в хроме этот инструмент присутствует и очень красиво выглядит.
Паттерн Row Data Gateway выполняет роль удобного взаимодействия с БД, бизнес-логика, как правило, реализуется в другом слое, который расположен над этим.
Это как-то противоречит с тем, что я написал? :)
Например, отдавая данные из слоя бд в виде массива, а не объекта вы тоже не используете эти преимущества. Представьте что вам понадобилось в модель товара добавить метод вычисления НДС исходя из стоимости, в нормальной ситуации это просто решалось наследованием от Zend_Db_Table_Row (с добавлением нужного метода getVat()) и указанием нового класса в поле protected $_rowClass в классе таблицы. Для всего кода, который уже работает с товаром ничего не изменилось бы, просто добавилась бы возможность использования нового метода. С вашим же подходом вы прилепили бы процедурный костыль и вместо использования $table->getItemById($id)->getVat() использовали бы $item = $table->getItemById($id); $table->getVatByPrice($item['price']);
Чувствуете разницу?
P.S. Кстати в хроме этот инструмент присутствует и очень красиво выглядит.