Я вот считаю что абстрагироваться от СУБД и таблиц вообще несомненно нужно, но DQL — далеко не самое красивое решение. Почему это просто не реализовать классами/методами с цепочками вызовов? Было бы намного естественней с таким работать.
В DQL был бы смысл, если бы его использовали к примеру различные библиотеки причем на различных языках программирования — вот тогда да, возможно стоило бы ввести отдельный язык… и то очень сомнительно.
То есть, речь не о том, что DQL в Doctrine не нужен вовсе, речь в том, что возможно стоило бы это реализовать так, как я писал выше. Что вы думаете по этому поводу?
Еще хотел заметить что мне кажется немного неоправданным полный переход на php5.3, docBlock ведь можно было парсить еще с выходом пятерки. В данный момент это может немного оттолкнуть начинающих разработчиков, у которых хостеры не поддерживают php5.3
Получается что они это сделали только из-за нейм-спейсов и __callStatic (ну какие есть еще в php5.3 фишки, полезные для Doctrine и используемые там, чтобы ради них отказаться от совсестимости с 5.2 веткой?)
Могу сказать что код там менее интуитивный(имхо), структура документации тоже не тек хороша(имхо) (хотя и у Doctrine совсем не шоколад), зато ее там больше чем для Doctrine 2.0 в данный момент.
Возможно кому-то Propel больше понравится в этом плане, но я не отношусь к числу этих людей.
Так же насколько я знаю, там нет возможности задавать мета-данные для меппинга в комментариях и нет поддержки YAML (а вот XML есть и там и там).
Я бы сказал отличия в основном в немного разных подходах и мелочах, но в общем можно сказать что Doctrine немного богаче в плане альтернативных способов выполнить одни и те же действия.
Оу, я прочел ваши мысли еще до того как вы написали этот комментарий и сразу начал писать ответ :)
Если знаете ORM для PHP получше Doctrine — советуйте и аргументируйте, буду очень признателен, т. к. у самого манечка с пристрастием копаться в различных библиотеках в поисках наиболее архитектурно правильных и красивых решений.
Лично мне очень нравятся идеи RedBean (вот реализацию как по мне можно было бы сделать покрасивее), хотя это не совсем ORM, и очень нравится Recess php framework (Это вообще MVC фреймворк, извиняюсь за оффтоп), но не своим ORM, я предвкушаю, что на нем получается очень высокая скорость разработки.
А вообще мне нравится Django (RoR конечно же тоже нравится, но Django нравится больше потому что: native механизм adminpages, шаблоны проще (хотя мой идеал шаблонов далек и от джанги), нет привязки к Javascript библиотекам (ура! Да здравствует JQuery!), python популярнее и на данный момент если не ошибаюсь — быстрее (синтаксис ruby честно говоря больше нравится чем python)
Ноооо… что-то меня понесло… в общем, вот такое у меня мировоззрение веб-разработчика, а мы сейчас говорим об ORM для PHP :)
Вот что меня смущает — я не уверен, правильно ли говорить, что Doctrine — самый мощный PHP ORM. Возможно это субъективные впечатления, подкрепленные субъективными мнениями веб-разработчиков из близких мне Интернетов.
Собственно для справки: Из ORM для PHP я имел дело только с Doctrine, Propel, RedBean(если это можно сюда отнести), и ORM из Kohana Framework.
Возможно вы знаете какие-то менее популярные, но очень хорошие ORM(и близкие по идеологии) библиотеки для PHP — Welcome, делитесь! :)
Эммм, ну раз вы размышляете в таком ключе, то засовывать Doctrine в system/database/ мне кажется нелогичным, следовало ложить все в application/libraries.
Ну вот к примеру, как к CI один человек подключает Zend'овский функционал: Ы.
Я правда не сильно спец в CI, поправьте, если я не прав. Просто на будущее хочу попробовать использовать именно CI в связке с Doctrine.
Еще не решил для себя лучше ли чем-то Kohana, ORM там к сожалению слабоват, очень не хватает Database Schema Generation и задания Mapping Information в PHP (самый удобный лично для меня способ)
Кстати, может заодно кто посоветует php фреймворк где есть что-то типа автоматически генерируемых по доп. информации в модели Django'вских admin pages с широкими возможностями кастомизации форм (желательно на уровне элементов форм)? И чтоб это ориентировано было именно на использование в продакшн, а не для разработкт/отладки. (Скафолдинг в CI — это не то).
Пока видел такое только модулем от сторонних разработчиков под RoR, с пыхом к сожалению ваще глухо, а вещь коллосально экономит время разработки.
Ухх, какой комментарий жирненький получился :) Жаль, мало кто прочитает, топик ведь старый…
Ну да, вот Shared hosting у freehost.com.ua к примеру не держит нормально тот же вордпресс (памяти на поток не хватает).
Это я к тому что Shared hosting тоже бывает разный.
Так и хочется крикнуть «Идиот!»
Я искренне благодарен автору этого топика за то что он делает. Вы очень, очень не правы. Извиняюсь, ну вскипело просто. Можете не приводить свои аргументы, я вам просто скажу — где-то вы ошибаетесь. Так мало хорошей документации на русском и тут еще такие комментаторы.
Автор, переводите еще. Плюсы вам везде куда можно.
Спасибо. А может где-то еще есть переводы официальной документации по Django? Не то чтоб английский вызывал какие-то затруднения, но на русском читать приятней
В DQL был бы смысл, если бы его использовали к примеру различные библиотеки причем на различных языках программирования — вот тогда да, возможно стоило бы ввести отдельный язык… и то очень сомнительно.
То есть, речь не о том, что DQL в Doctrine не нужен вовсе, речь в том, что возможно стоило бы это реализовать так, как я писал выше. Что вы думаете по этому поводу?
Получается что они это сделали только из-за нейм-спейсов и __callStatic (ну какие есть еще в php5.3 фишки, полезные для Doctrine и используемые там, чтобы ради них отказаться от совсестимости с 5.2 веткой?)
Возможно кому-то Propel больше понравится в этом плане, но я не отношусь к числу этих людей.
Так же насколько я знаю, там нет возможности задавать мета-данные для меппинга в комментариях и нет поддержки YAML (а вот XML есть и там и там).
Я бы сказал отличия в основном в немного разных подходах и мелочах, но в общем можно сказать что Doctrine немного богаче в плане альтернативных способов выполнить одни и те же действия.
Если знаете ORM для PHP получше Doctrine — советуйте и аргументируйте, буду очень признателен, т. к. у самого манечка с пристрастием копаться в различных библиотеках в поисках наиболее архитектурно правильных и красивых решений.
Лично мне очень нравятся идеи RedBean (вот реализацию как по мне можно было бы сделать покрасивее), хотя это не совсем ORM, и очень нравится Recess php framework (Это вообще MVC фреймворк, извиняюсь за оффтоп), но не своим ORM, я предвкушаю, что на нем получается очень высокая скорость разработки.
А вообще мне нравится Django (RoR конечно же тоже нравится, но Django нравится больше потому что: native механизм adminpages, шаблоны проще (хотя мой идеал шаблонов далек и от джанги), нет привязки к Javascript библиотекам (ура! Да здравствует JQuery!), python популярнее и на данный момент если не ошибаюсь — быстрее (синтаксис ruby честно говоря больше нравится чем python)
Ноооо… что-то меня понесло… в общем, вот такое у меня мировоззрение веб-разработчика, а мы сейчас говорим об ORM для PHP :)
Собственно для справки: Из ORM для PHP я имел дело только с Doctrine, Propel, RedBean(если это можно сюда отнести), и ORM из Kohana Framework.
Возможно вы знаете какие-то менее популярные, но очень хорошие ORM(и близкие по идеологии) библиотеки для PHP — Welcome, делитесь! :)
Ну вот к примеру, как к CI один человек подключает Zend'овский функционал: Ы.
Я правда не сильно спец в CI, поправьте, если я не прав. Просто на будущее хочу попробовать использовать именно CI в связке с Doctrine.
Еще не решил для себя лучше ли чем-то Kohana, ORM там к сожалению слабоват, очень не хватает Database Schema Generation и задания Mapping Information в PHP (самый удобный лично для меня способ)
Кстати, может заодно кто посоветует php фреймворк где есть что-то типа автоматически генерируемых по доп. информации в модели Django'вских admin pages с широкими возможностями кастомизации форм (желательно на уровне элементов форм)? И чтоб это ориентировано было именно на использование в продакшн, а не для разработкт/отладки. (Скафолдинг в CI — это не то).
Пока видел такое только модулем от сторонних разработчиков под RoR, с пыхом к сожалению ваще глухо, а вещь коллосально экономит время разработки.
Ухх, какой комментарий жирненький получился :) Жаль, мало кто прочитает, топик ведь старый…
Много очень правильных мыслей.
Думать головой — это прекрасно ))) Приятно, что есть все-таки люди, которые думают головой )
Это я к тому что Shared hosting тоже бывает разный.
Я искренне благодарен автору этого топика за то что он делает. Вы очень, очень не правы. Извиняюсь, ну вскипело просто. Можете не приводить свои аргументы, я вам просто скажу — где-то вы ошибаетесь. Так мало хорошей документации на русском и тут еще такие комментаторы.
Автор, переводите еще. Плюсы вам везде куда можно.