>>> Если вы работаете над сайтом, который размещается на LAMP стеке – какова вероятность того, что клиент сменит БД
Был какраз этот случай. С мускуля на постгрес через несколько лет разработки с plain sql запросами в коде. Внезапно понадобилось переходить. Шанс обысно мизерный, но если такое случится, сложно представить сколько человеко-часов придется затратить. В таком случае лучше использовать сразу какой-нибудь Zend_Query, заодно у вас будет единая точка для запросов куда можно воткнуть профилирование, кеширование и прочая. Менджмент рисков никто не отменял.
Небольшой оффтопик — когда я нахожусь в списке задач по тегу и добавляю несколько, один из них оказывается выделенным, и когда я ввожу текст в верхний инпут для создания нового задания, то нажатие пробела изменяет статус завершенности той самой выделенной задачи. Ubuntu, Chrome.
Я вот работал на одни чаевые в штатах. вся зп целиком уходила в налоги (в техасе 30% налог на чаевые, но нельза заплатить больше, чем заработал за это время зарплатой, поэтому и зп была около 2-х баксов в час). Так вот, получал я около 10-15 в час за счет чаевых, и скажу я вам, если бы мне эти деньги платили зарплатой, хрен бы я так жопу рвал обслуживать.
Стараюсь всякие файндеры и прочую «статику» держать в сервисе, а отдавать — объект CActiveRecord. В методы модели стараюсь выносить всякие простые вещи вроде $article->getTopComments().
Насчет Domain Model это конечно уже к симфони + doctrine. Правда вот во всем этом кроется то, что мне не нравится в стаке PHP — все решения, перетянутые с JPA или рельсы выглядят громоздко. Субъективно, конечно.
Потому что хочется сохранить интерфейс нетронутым. Полиморфизм, знаете ли. Т.е.не клепать костыль при вызове, а изменить поведение, оставив интерфейс прежним.
>> Зачем мешать логику реестра и ектив рекорд?
Звучит как «зачем мешать mvc и?
Я стараюсь сделать Service Layer, который как бы прослойка между контроллерами и моделями, и стараюсь не вызывать апи ActiveRecord кроме как из Service Layer, а из контроллера вызываю что-то типа $articleService->getLastArticles(5). Если память начнет быстро уходить или запросы станут тяжелыми, я всегда могу внутри метода сервиса переписать джоин через активрекорд на чистый sql или сделать кеширование в переменную.
Именно по причине тяги к энтерпрайз паттернам меня смущают виджеты, которые лезут в базу (помоему это противоречит даже MVC) и наличие знаний о базе и о маппинге в самой модели.
Угу, причем если вдруг понадобится, будь добр имей ссылку на этот объект, потому что выборка этих объектов повторно через ActiveRecord наплодит еще копий.
Так нету потому что для связей сложно, или потому что «чтобы убедится, что результат более-менее актуален. Или для того, чтобы получить чистый объект, а не тот, с которым мы, ещё не сохранив, поработали»? Ведь чистый объект или обновленный можно решить простым методом в модели.
Identity Map нужен, чтобы без проблем вызывать всякие $user->getArticles() несколько раз не кешируя в переменную, да и просто вызывать ->findByPk($item_id) зная, что не будет лишнего запроса. Почему-то JPA, Hibernate, Entity Framework, Rails Activerecord этого придерживаются, но Yii упирается рожками.
Чистый объект можно получить через какой-нибудь getClean() от объекта, а обновить объект через, допустим, reload(). Вместо этого фреймворк выделяет память под два объекта, да еще и делает два запроса.
Еще было бы неплохо использовать UnitOfWork, но вряд ли это впишется в текущию концепую, да и в ActiveRecord в часности
Немного относительно темы: сейчас облака предоставляют и вычислительные мощности, т.е. обработка разных данных удаленно, не загружая вашу машину. Что интересно, уже появляются первые ростки шифрованной обработки, т.е. в теории удаленный сервис не будет знать что он обрабатывает и как он обрабатывает, но тем не менее будет это делать. На данный момент все упирается в скорость, т.е. настолько упирается, что это скорее дело близкого будущего, нежели завтрашнего дня.
С тем же успехом можно сказать, что ему помогли бы знания в лингвистике при написании компилятора или автоматического перевода. На самом деле математика и программирование софта связаны лишь в определенных местах. Та же теория графов не менее полезна.
Был какраз этот случай. С мускуля на постгрес через несколько лет разработки с plain sql запросами в коде. Внезапно понадобилось переходить. Шанс обысно мизерный, но если такое случится, сложно представить сколько человеко-часов придется затратить. В таком случае лучше использовать сразу какой-нибудь Zend_Query, заодно у вас будет единая точка для запросов куда можно воткнуть профилирование, кеширование и прочая. Менджмент рисков никто не отменял.
Насчет Domain Model это конечно уже к симфони + doctrine. Правда вот во всем этом кроется то, что мне не нравится в стаке PHP — все решения, перетянутые с JPA или рельсы выглядят громоздко. Субъективно, конечно.
>> Зачем мешать логику реестра и ектив рекорд?
Звучит как «зачем мешать mvc и?
Именно по причине тяги к энтерпрайз паттернам меня смущают виджеты, которые лезут в базу (помоему это противоречит даже MVC) и наличие знаний о базе и о маппинге в самой модели.
Еще было бы неплохо использовать UnitOfWork, но вряд ли это впишется в текущию концепую, да и в ActiveRecord в часности