PHP Framework и ORM против хранимых процедур

Question

Я нахожусь в процессе выбора PHP-фреймворка для запускаемого веб-приложения. В прошлом я никогда не использовал фреймворк, но в этом проекте есть большая потребность.

Я спорил между обычными подозреваемыми; CakePHP, Zend Framework и Symfony. Я ходил взад и вперед о том, какие рамки будут работать лучше для меня и этого проекта. Я склоняюсь к CakePHP, но я все еще исследую.

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

Мне нужны отзывы об использовании ORM или Doctrine от CakePHP с Zend или Symfony для сохранения всего в хранимых процедурах. Я знаю, что хранимые процедуры будут быстрее, но что еще я потеряю, если не использую ORM? Я понимаю, что ORM даст мне абстракцию базы данных, но, на мой взгляд, это просто помогает людям, которые не пишут SQL. Я также знаю, что недостаточно знаю об ОРМ.

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

Спасибо за любую помощь заранее.

Answer 1

0) Удар за усилие

Ключевым преимуществом ORM является то, что вы не тратите столько времени на работу со слоем постоянства. Предварительно написанный ORM (я работал с EclipseLink) предоставит массу вещей, которые вы, вероятно, не получите в пользовательских написанных хранимых процессах. Я думаю, стоит подумать о том, сколько времени вы хотите потратить на написание своего слоя персистентности.

1) Кеширование

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

2) Абстракция

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

3) Скорость

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

Answer 2

Марк Робинсон дает отличный ответ.Я просто собираюсь подтвердить то, что он говорит, поделившись нашим опытом работы с Doctrine2.

Я решил использовать Doctrine2 в качестве нашего ORM с Zend Framework некоторое время назад.Наш проект все еще разрабатывается, но выбор D2 был решением, о котором мы ни разу не пожалели.Несмотря на то, что вам все еще нужно много думать о своей архитектуре данных, D2 дает вам гибкость, чтобы иметь возможность изменить эту модель на более поздний срок, если потребуется.Это позволило нам быстро опробовать вещи на ранних этапах, а пространство для роста и изменения позже, когда мы решили, что все было не совсем правильно - это происходит.

По отношению к точке зрения Марка об абстракции.Еще одна вещь, которая мне нравится в D2, это то, что мы работаем с простыми старыми объектами PHP.Не стоит недооценивать способность мыслить с точки зрения объектов - как для людей, ответственных за моделирование данных, так и для разработчиков, которые работают с данными - это сделает вашу жизнь проще, поверьте мне.Также хорошо иметь встроенную документацию по отображению ORM (если вы выберете подход с докблоком).

Правильно, производительность.Как говорит Марк, есть способы и способы ускорить процесс, но всегда будут некоторые накладные расходы.Когда бы вы ни внедрили еще один программный уровень, произойдет некоторое снижение производительности, но это компромисс.Для нас компромисс - преимущества использования ORM по сравнению с производительностью - стоит того.Мы потратили бы больше времени на отладку кода, а не на выполнение задач без ORM.

В любом случае, D2 может помочь вам с кэшированием запросов, результатов и метаданных.Хотя вы, вероятно, просто хотите использовать кэш-массив во время разработки, замечательно, что есть средства для таких вещей, как APC, memcache и т. Д., Когда вы собираетесь тестировать и развертывать.Вы можете даже разработать свой собственный, если вы смелый.

http://www.doctrine -project.org / docs / orm / 2.0 / en / reference / caching.html

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

Answer 3

Фреймворк реализует в основном три вида функций:

1. поток между «получением запроса» и «отображением страницы». Вот куда вы положили такие вещи как MVC, роутер и т.д ...
2. способ управления вашей моделью и ее постоянство. Вот где вы видите такие сокращения, как ORM, DBAL, DAO
3. Компоненты. Особенности, часто работающие также автономно. Как разбор XML, обработка i18n, генерация PDF ...

Когда вы выбираете структуру, это означает, что вы выбираете 1). Это то, что вам, безусловно, придется придерживаться, это поток вашего приложения. 2) и 3)? Вы можете интегрировать те, которые вы предпочитаете. В качестве примера я нахожусь на Zend Framework с большинством его компонентов, но использую Doctrine ORM 2 и инъекцию зависимости Symfony. Мой друг работает в Symfony 2, также использует Doctrine ORM, но выполняет генерацию PDF и управление почтой с помощью связанных с Zend компонентов.

Еще одна вещь, которую вам нужно знать, если в настоящее время существует «второе поколение» фреймворков / orm php, (пере) написанное для использования преимуществ новых функций php 5.3 и / или для решения общей производительности / сцепление выпуски у них (почти) все были. Некоторые из них готовы к производству, некоторые еще находятся в стадии разработки:

• Учение ОРМ 2 (готово к производству)
• Symfony 2 (готов к производству)
• CakePhp 2 (в RC 2 в настоящее время, но к тому времени, когда ваш проект будет готов, он должен быть стабильным)
• Zend Framework 2 (все еще в активной разработке, но обычно не так долго)
• FLOW 3 (бета2, скоро тоже будет готов)

Для части ORM я рекомендую использовать одну, особенно Doctrine. @Mark и @ iainp999 прекрасно объяснили почему.

Answer 4

ORM предназначены для программистов, которые не «зацикливаются» на SQL!

Да ORM упрощают (или, по крайней мере, требуют меньше строк кода) написание простых элементов CRUD, но когда вы переходите к более сложнымЭто все равно что пытаться писать SQL с кусочком мокрой спагетти на расстоянии десяти футов.

Так что придерживайтесь SQL.

Стоит посмотреть на что-то вроде «SQLMap», то есть ORM, начиная с«R» - относительная сторона отображения (большинство пытается отобразить объект «O» на таблицу).Это позволит вам самостоятельно написать SQL и сгенерировать соответствующие «вспомогательные» классы для легкого доступа к результатам в вашей программе.