Действительно ли это - хорошая идея использовать CodeIgniters Активная Фонотека для управления базами данных MySQL, или я должен просто использовать SQL?
Я начинаю справляться с CodeIgniter и столкнулся, это - поддержка Активного Рекордного шаблона.
Мне нравится то, что это генерирует код SQL для Вас поэтому по существу, можно получить, обновить и вставить данные в к базе данных, не связывая приложение с определенным механизмом базы данных.
Это делает простые запросы очень простыми, но мое беспокойство - то, что это делает сложные запросы более сложными если не невозможный (например, если потребность в механизме определенные функции).
Мои вопросы
Каково Ваше мнение об этом шаблоне особенно относительно реализации CodeIgniters?
Есть ли какие-либо проблемы скорости с обертыванием базы данных в другом слое?
Это (логика) становится грязным при попытке создать очень сложные запросы?
Преимущества путь недостатки?
2 ответа
Хорошо, в первую очередь 99% ваших запросов будут простыми: выбрать / вставить / обновить / удалить. Для этого активная запись отлично подходит. Он обеспечивает простой синтаксис, который можно легко изменить. Для более сложных запросов вы должны просто использовать метод запроса. Вот для чего это нужно.
Во-вторых, он обеспечивает экранирование и безопасность для этих запросов. Признайтесь, ваше приложение, вероятно, будет иметь сотни, если не тысячи мест, где выполняются запросы. Вы обязаны облажаться и забыть как следует сбежать от некоторых из них. Активная запись не забывает.
В-третьих, по моему опыту, производительность не сильно пострадала. Конечно, но это, вероятно, около 0,00001 на запрос. Я думаю, что это вполне приемлемо для дополнительных проверок безопасности и работоспособности, которые он выполняет за вас.
Наконец, я думаю, очевидно, что преимуществ гораздо больше, чем недостатков. Иметь безопасные запросы, которые сможет понять даже самый младший разработчик, - это здорово.
Каково ваше мнение (sic) об этом шаблоне, особенно в отношении реализации CodeIgniters?
Не могу много сказать о реализации CI . Обычно я избегаю AR для чего угодно, кроме простейших приложений. Если таблица не соответствует 1: 1 моим бизнес-объектам, я не использую AR, так как это затруднит моделирование приложения. Мне также не нравится идея связать уровень сохраняемости с моими бизнес-объектами. Это нарушение разделения интересов. Почему Продукт должен знать, как спасти себя? Дальнейшее чтение: http://kore-nordmann.de/blog/why_active_record_sucks.html
РЕДАКТИРОВАТЬ после комментария @kemp я просмотрел Руководство пользователя CI, чтобы узнать, как они реализовали AR:
Как вы можете видеть в PoEAA , AR - это объект, который обертывает строку в таблице или представлении базы данных, инкапсулирует доступ к базе данных и добавляет логику домена к этим данным. Но это не то, чем занимается CI.Он просто предоставляет API для построения запросов. Я понял, что существует класс Model, который расширяет AR и который можно использовать для создания бизнес-объектов, но тогда он был бы больше похож на Row Data Gateway . Обратитесь к PHPActiveRecord для альтернативной реализации.
Есть ли проблемы со скоростью при переносе базы данных на другой уровень?
Каждый раз, когда вы абстрагируете или переносите что-то во что-то еще, вы можете быть уверены, что это сказывается на производительности по сравнению с выполнением этого необработанного. Вопрос в том, приемлемо ли это для вашего приложения. Единственный способ узнать это - провести сравнительный анализ. Дополнительная литература: https://stackoverflow.com/search?q=orm+slow
РЕДАКТИРОВАТЬ В случае простого API построения запросов CI, я бы предположил, что влиянием на производительность можно пренебречь. По логике, сборка запросов займет больше времени, чем просто передача необработанной строки SQL адаптеру db, но это должно быть только микросекунды. И, насколько я видел в Руководстве пользователя, вы также можете кэшировать строки запроса. Но если сомневаетесь, бенчмарк.
Становится ли (логика) беспорядочной при попытке построить очень сложные запросы?
Зависит от ваших запросов. Я видел довольно запутанные SQL-запросы. Они не становятся красивее, когда выражаются через объектно-ориентированный интерфейс. В зависимости от API вы можете найти запросы, которые не сможете выразить через него. Но опять же, это зависит от ваших запросов.
Преодолевают ли преимущества недостатки?
Это решать только вам. Если это облегчает вашу жизнь программиста, то почему бы и нет. Если это соответствует вашим программным потребностям, да.Ruby on Rails в значительной степени построен на этой концепции (AR), так что это не может быть так уж плохо (хотя мы тоже можем спорить об этом :))