Comments 31
Рад, что есть ещё люди, способные совершенствовать велосипеды :)
Скажите, а зачем один фреймворк подключать к другому? Какая была у вас реальная задача?
Doctrine это не фреймворк, а ORM.
CodeIgniter — MVC-фреймворк, Doctrine — это ORM, вещи совсем разные.
Doctrine, грубо говоря, — один из возможных вариантов для «M» в «MVC».
Doctrine, грубо говоря, — один из возможных вариантов для «M» в «MVC».
А я думал, что MVC и ORM — это такие концепции в программировании и построении приложений. А фреймворк — это такой набор библиотек и инструментов для построения приложений, вне зависимости от концепции, которую этот фреймворк реализует.
Вы немного (хм… ну ладно, вру, ужасно!) ошибаетесь. Это можно поправить даже прогуглив эти аббревиатуры. И, кстати, в том, что один фреймворк нужно/можно подключать к другому — тоже ошибаетесь. Вот, к примеру, Symfony 1.1+ позволяет использовать классы ZendFramework и ezComponents с их человеческой автозагрузкой (никаких include_once костылей) — очень даже ничего, к примеру, повзаимствовать у ez классы для построения графов… мм…
Ну хоть один нормальный ответ. Я обращаюсь к википедии:
ru.wikipedia.org/wiki/ORM
ru.wikipedia.org/wiki/Model-View-Controller
Из прочитанного я понимаю, что и ORM и MVC — это концепции работы с данными и построения архитектуры приложений. Так? Или я читаю не там (реально не могу понять за что минусы ставят)?
И почем нельзя назвать фреймворком Doctrine — реализацию ORM на php? Не понятно, может хоть вы проясните, ну пожалуйста.
ru.wikipedia.org/wiki/ORM
ru.wikipedia.org/wiki/Model-View-Controller
Из прочитанного я понимаю, что и ORM и MVC — это концепции работы с данными и построения архитектуры приложений. Так? Или я читаю не там (реально не могу понять за что минусы ставят)?
И почем нельзя назвать фреймворком Doctrine — реализацию ORM на php? Не понятно, может хоть вы проясните, ну пожалуйста.
Нэд.
MVC ( Модель-вид-представление ) — одна из моделей архитектур всего приложения в целом, где у вас в одном месте контроллеры, в другом классы моделей (бизнесс-логика, да) и в третьем — шаблоны страниц.
CodeIgnitor — MVC фреймкорк.
ORM — Object Relational Mapping (мэппинг объектов) — это такая модель работы с базой, в которой каждой таблице в базе каким-то образом ставится в соответствие класс модели данных в вашем приложении. То есть разметка (мэппинг) ваших обэектов в таблицы базы.
Doctrine, Propel, Sequel, Active record — все это ORM фреймворки / библиотеки.
ORM касается только работы приложения с базой. MVC — архитектура всего приложения.
MVC ( Модель-вид-представление ) — одна из моделей архитектур всего приложения в целом, где у вас в одном месте контроллеры, в другом классы моделей (бизнесс-логика, да) и в третьем — шаблоны страниц.
CodeIgnitor — MVC фреймкорк.
ORM — Object Relational Mapping (мэппинг объектов) — это такая модель работы с базой, в которой каждой таблице в базе каким-то образом ставится в соответствие класс модели данных в вашем приложении. То есть разметка (мэппинг) ваших обэектов в таблицы базы.
Doctrine, Propel, Sequel, Active record — все это ORM фреймворки / библиотеки.
ORM касается только работы приложения с базой. MVC — архитектура всего приложения.
Ну как же так? Вы говорите «нет», а потом сами называете Doctrine — ORM фреймворком. Я не понимаю где я ошибаюсь в таком случае.
ORM, MVC — паттерны.
ORM — паттерн, относящийся к работе с данными.
MVC — к всему приложению в целом.
Реализации и того и другого можно назвать фреймворком, но это совершенно разные фреймворки.
ORM — паттерн, относящийся к работе с данными.
MVC — к всему приложению в целом.
Реализации и того и другого можно назвать фреймворком, но это совершенно разные фреймворки.
Ну так да, я же тоже самое и написал — полностью с вами согласен. А меня все (digger, kmike, NaTTs) дружно пытаются убедить что я не прав. Бред какой-то. Еще и в карму насрали :\
Самое обидное — так и не получил внятного ответа на свой первый вопрос: для какой задачи понадобилось использовать ORM.
Самое обидное — так и не получил внятного ответа на свой первый вопрос: для какой задачи понадобилось использовать ORM.
Вообще ORM удобен для работы с данными, а такой ORM, как Doctrine вдвойне удобен. Если логика приложения по работе с данными (модели) реализуется Doctrine, это получается на порядок удобнее, чем встроенный AR CodeIgniter.
Для простых задач, где запутиться тяжело, или очень требовательных к производительности проектов, конечно же, лучше использовать SQL напрямую, не пользуясь даже AR CodeIgniter.
Для простых задач, где запутиться тяжело, или очень требовательных к производительности проектов, конечно же, лучше использовать SQL напрямую, не пользуясь даже AR CodeIgniter.
Cовмещение MVC фреймворка cо сторонним ORM — дело обычное. Например Symphony использует ORM Propel
CI в отличие от CakePHP, Symphony и т. п. не имеет встроенного ORM. За это его похоже и любят. И ровно по этой причине в него постоянно пытаются воткнуть какой-нибудь ORM.
CI в отличие от CakePHP, Symphony и т. п. не имеет встроенного ORM. За это его похоже и любят. И ровно по этой причине в него постоянно пытаются воткнуть какой-нибудь ORM.
Мне кажется, CakePHP и Ci на ранних стадиях не любят потому, что они PHP4-based.
Мне, к примеру, очень непонравилось в описании про «чтобы сделать метод класса приватным, назовите его с символа подчеркивания». Бррр…
Это было год назад, затем я за судьбой проекта не следил, если я ошибаюсь — можете щелкнуть по лбу)
Мне, к примеру, очень непонравилось в описании про «чтобы сделать метод класса приватным, назовите его с символа подчеркивания». Бррр…
Это было год назад, затем я за судьбой проекта не следил, если я ошибаюсь — можете щелкнуть по лбу)
спасибо за статью.
У меня еще идея доработать CI'шный профайлер, чтоб он doctrine'овские данные выводил в статистику запросов.
Надо будет собраться написать :)
У меня еще идея доработать CI'шный профайлер, чтоб он doctrine'овские данные выводил в статистику запросов.
Надо будет собраться написать :)
Насколько Doctrine более тормозной по сравнению с орм от CodeIgniter? Просто, есть версия, ч то использование данного орм убивает одно из основных преимуществ CI — скорость
[offtop]
меня, как пользователя cakephp, как-то удручает запись вида:
[/offtop]
меня, как пользователя cakephp, как-то удручает запись вида:
$userTable = Doctrine::getTable('User');
$user = $userTable->findOneByUsername('zYne-');
вместо
$user = new User();
$foundUser = $user->findOneByUsername('zYne-');
[/offtop]
при генерации классво есть параметр отвечающий за генерацию тэйблов
'generateTableClasses' => true
точно не помню, но тогда будет что-то вроде
$user = new UserTable();
$foundUser = $user->findOneByUsername('zYne-');
хотя мне больше нравится запись $user = Doctrine::getTable('User')->findOneByUsername('zYne-');
а кэйк, кажись, до сих пор поддерживает совместимость с 4-м пыхом? если да, то тогда там так низя.
моё знакомство с orm началось как раз с cake
'generateTableClasses' => true
точно не помню, но тогда будет что-то вроде
$user = new UserTable();
$foundUser = $user->findOneByUsername('zYne-');
хотя мне больше нравится запись $user = Doctrine::getTable('User')->findOneByUsername('zYne-');
а кэйк, кажись, до сих пор поддерживает совместимость с 4-м пыхом? если да, то тогда там так низя.
моё знакомство с orm началось как раз с cake
Вопрос — как обстоят дела с производительностью? Не упала?
Ну конечно упала =) Причем значительно… Примерно раза в 2 на моем предыдущем ноутбуке (C2Duo 1.8, 2GB RAM) относительно нативного ORM CI. Однако, гибкость получаемая при разработке с Doctrine лично для меня покрывает все издержки производительности. В конечном счете, мы просто выбираем между производительностью и гибкостью разрабатываемой системы…
Так и предполагал, спасибо =)
Думаю, приоритетным фактором должна быть производительность, хотя, если взять ту же Symfony (ветка 1.1.x) с Propel на борту и взглянуть на их официальный сайт, который очень шустро работает, то есть к чему стремиться =)
Думаю, приоритетным фактором должна быть производительность, хотя, если взять ту же Symfony (ветка 1.1.x) с Propel на борту и взглянуть на их официальный сайт, который очень шустро работает, то есть к чему стремиться =)
На крупном проекте производительность рано или поздно все-равно упрется в крышку сервера и вот тогда Doctrine или Propel будут более выгодно выглядеть за счет своей гибкости и масштабируемости в сравнении с менее развитыми решениями. А в мелком проекте вообще не стоит заострять внимание на производительности. IMHO
А чем данный метод не подходит?
blog.medryx.org/2008/10/04/codeigniter-and-doctrine/
На 1.7.1 именно он завелся.
Метод описанный здесь не заработал, библиотечка не подключилась. Позвала в дебри fw…
На 1.7.1 именно он завелся.
Метод описанный здесь не заработал, библиотечка не подключилась. Позвала в дебри fw…
Эммм, ну раз вы размышляете в таком ключе, то засовывать Doctrine в system/database/ мне кажется нелогичным, следовало ложить все в application/libraries.
Ну вот к примеру, как к CI один человек подключает Zend'овский функционал: Ы.
Я правда не сильно спец в CI, поправьте, если я не прав. Просто на будущее хочу попробовать использовать именно CI в связке с Doctrine.
Еще не решил для себя лучше ли чем-то Kohana, ORM там к сожалению слабоват, очень не хватает Database Schema Generation и задания Mapping Information в PHP (самый удобный лично для меня способ)
Кстати, может заодно кто посоветует php фреймворк где есть что-то типа автоматически генерируемых по доп. информации в модели Django'вских admin pages с широкими возможностями кастомизации форм (желательно на уровне элементов форм)? И чтоб это ориентировано было именно на использование в продакшн, а не для разработкт/отладки. (Скафолдинг в CI — это не то).
Пока видел такое только модулем от сторонних разработчиков под RoR, с пыхом к сожалению ваще глухо, а вещь коллосально экономит время разработки.
Ухх, какой комментарий жирненький получился :) Жаль, мало кто прочитает, топик ведь старый…
Ну вот к примеру, как к CI один человек подключает Zend'овский функционал: Ы.
Я правда не сильно спец в CI, поправьте, если я не прав. Просто на будущее хочу попробовать использовать именно CI в связке с Doctrine.
Еще не решил для себя лучше ли чем-то Kohana, ORM там к сожалению слабоват, очень не хватает Database Schema Generation и задания Mapping Information в PHP (самый удобный лично для меня способ)
Кстати, может заодно кто посоветует php фреймворк где есть что-то типа автоматически генерируемых по доп. информации в модели Django'вских admin pages с широкими возможностями кастомизации форм (желательно на уровне элементов форм)? И чтоб это ориентировано было именно на использование в продакшн, а не для разработкт/отладки. (Скафолдинг в CI — это не то).
Пока видел такое только модулем от сторонних разработчиков под RoR, с пыхом к сожалению ваще глухо, а вещь коллосально экономит время разработки.
Ухх, какой комментарий жирненький получился :) Жаль, мало кто прочитает, топик ведь старый…
Sign up to leave a comment.
Правильная интеграция Doctrine в CodeIgniter