Занимаюсь этой же задачей в настоящий момент. Решение подобное предложенному вами исключил по причине отсутствия универсальности: надо создавать файл со списками классов, а это как-то криво. Добился того, что собирается только Zend Framework со всеми зависимостями и покомпонентно (иначе полная сборка существенно увеличивает расход памяти, а использоваться могут не все классы). Именно такой вариант считаю правильной сборкой в один файл, т.к. даже при обновлении надо будет всего лишь перезапустить скрипт с таким же набором опций. Готового ничего не находил (поэтому и решил взяться за задачу). Скоро причешу код, добавлю скрипту управление через консоль и выложу здесь в статье. Надеюсь кому-то будет полезно.
>Ведь тогда мы придем к преобразователю данных, разделив взаимодействие c базой и логику на две паралелльные иерархии классов, но за это придется платить сложностью.
Как-то мы с вами уже спорили на подобную тему… и если уж выносить логику выше в отдельную иерархию классов, то надо отказываться от Row совсем. Иначе получится путаница — 2 места для добавления новой функциональности. Применять сразу оба подхода в рамках одного компонента нецелесообразно.
Думаю, процесс работы с БД эволюционирует по такой схеме: используем ORM везде, т.к. очень удобно => понимаем, что она тормознутая, и используеп ООП обёртки над SQL => используем ORM только там, где это можно сделать без лишней нагрузки на сервер и на себя.
>Во первых — селект ихний хоть и хорош, но давайте спустимся с высоты ооп и посмотрим все глазами адекватных людей — это большой такой костыль для SQL
Это так, но такой «костыль» помогает вести командную разработку, т.к. динамическая сборка запроса облегчается в разы без боязни что-то испортить в исходном варианте.
>И если вам нравится ZF Select, то вообще советую посмотреть в сторону Doctrine с ее DQL
Честно говоря, давно собираюсь присмотрется поближе, т.к. паттерн Row, Rowset совсем не вызывает симпатии.
Согласен. Но и ORM надо использовать с умом, а не как предлагает автор, запрашивая базу при каждой итерации цикла.
Что же касается Zend Framework, то наиболее удобным и гибким методом для извлечени данных считаю Zend_Db_Select. Создав более или менее абстрактный запрос к основным таблицам модели, в будущем его можно без проблем модифицировать в специализированных методах.
Это просто жесть. Зачем делать запросы к базе в цикле? Если уж на то пошло, то соберите все идентификаторы в массив. Потом выборку по in (1, 5, 6, 7) + order, и в цикле разберёте по новостям. Будет 2 запроса вместо фиг знает скольки.
И лучше не часто использовать Zend_Db_Table_Row(set) для работы с базой. Если задача просто вывести новости, то никакой проблемы заметно не будет. А вот при повсевместном использовании это сильно затормозит работу приложения. Проверено на личном опыте =).
Компонент состоит из нескольких классов. Работу над компонентом начинает один человек, а заканчивает другой. Так что всё нормально, и получается, что над одними и теме же классами работают несколько человек.
Ну вряд ли вы знаете все. Почитайте о тех, что не знаете. Ведь люди, которые их придумали и описали прошли вашим путём. Почему бы не взять их опыт? Конечно, он не заменит собственного, но зато вы будете знать где и какой паттерн можно применить на стадии проектирования.
Честно говоря я вообще не представляю как предложенный автором вариант можно реализовывать в командной работе, когда даже в разработке одного класса может принимать участие несколько человек. Далеко тут без проектирования не уедешь.
А сколько времени вы работали по TDD, прежде чем перешли на интеграцию тестов сразу в код? Другими словами сколько времени ушло на осознание того, что можно делать иначе практически тоже самое?
>Паттерны описаны для неумеющих программировать.
Паттерны написаны для того, чтобы не изобретать велосипед. Если программист с мозгами, то он может сразу понять при написании класса какой паттерн ему тут может пригодиться. Тот, кто их не знает совсем будет писать какой-то свой велосипед, и, возможно, как вы говорите придёт к тому же паттерну. Но это лишнее время.
Всё таки Eclipse + PDT на мой взгляд хоть и грозкий, но выигрывает по доступному функционалу. Чего-то не хватает? Всегда найдётся плагин (ну или почти всегда =))
Вы оптимист. Многое что вы перечислили надо изучать в ВУЗе. Школа не даёт полного образование и это не её функция. Не зря же оно называется средним? Там учатся не только программисты.
Как-то мы с вами уже спорили на подобную тему… и если уж выносить логику выше в отдельную иерархию классов, то надо отказываться от Row совсем. Иначе получится путаница — 2 места для добавления новой функциональности. Применять сразу оба подхода в рамках одного компонента нецелесообразно.
Это так, но такой «костыль» помогает вести командную разработку, т.к. динамическая сборка запроса облегчается в разы без боязни что-то испортить в исходном варианте.
>И если вам нравится ZF Select, то вообще советую посмотреть в сторону Doctrine с ее DQL
Честно говоря, давно собираюсь присмотрется поближе, т.к. паттерн Row, Rowset совсем не вызывает симпатии.
Что же касается Zend Framework, то наиболее удобным и гибким методом для извлечени данных считаю Zend_Db_Select. Создав более или менее абстрактный запрос к основным таблицам модели, в будущем его можно без проблем модифицировать в специализированных методах.
Это просто жесть. Зачем делать запросы к базе в цикле? Если уж на то пошло, то соберите все идентификаторы в массив. Потом выборку по in (1, 5, 6, 7) + order, и в цикле разберёте по новостям. Будет 2 запроса вместо фиг знает скольки.
И лучше не часто использовать Zend_Db_Table_Row(set) для работы с базой. Если задача просто вывести новости, то никакой проблемы заметно не будет. А вот при повсевместном использовании это сильно затормозит работу приложения. Проверено на личном опыте =).
Паттерны написаны для того, чтобы не изобретать велосипед. Если программист с мозгами, то он может сразу понять при написании класса какой паттерн ему тут может пригодиться. Тот, кто их не знает совсем будет писать какой-то свой велосипед, и, возможно, как вы говорите придёт к тому же паттерну. Но это лишнее время.