Комментарии 68
Подсветите пожалуйста код, спасибо.
Интересно конечно будет на это посмотреть :) подсветка кода тут делается обычно сторонними ресурсами:
quickhighlighter.com/
s-c.me/
habrasyntax.fractalizer.ru/
Есть еще Хабраредактор www.bankinform.ru/habraeditor/
Кстати а где можно ваш ORM скачать и потыкать палочкой? :)
Документация присутствует какая нибудь?
quickhighlighter.com/
s-c.me/
habrasyntax.fractalizer.ru/
Есть еще Хабраредактор www.bankinform.ru/habraeditor/
Кстати а где можно ваш ORM скачать и потыкать палочкой? :)
Документация присутствует какая нибудь?
Блин, дружище, бросай ты свой еще один никому не нужный виласипет )
Почему не нужный, вроде везде много чего нового появляется. ПХП вроде не умирает пока =)
Потому что объективно твой не хуже, он ХУЖЕ. Лучше потрать время на разбирательство с каким-нибудь хорошим существующим ORM. Потому что написать свой ORM — это титанический труд, сродни написательству компилятора; там нужно уметь программировать, а не писать скрипты на php.
Все начинается с простого. Я его вывел в свет с надеждой найти соавторов. Даже специально репозиторий завел. Понимаю у всех плохое отношение к велосипедостроительству. Но ведь иначе не было бы общего развития =)
Вы как-то не на мой вопрос отвечаете. Я же нигде не спорил, что все начинается с простого.
Дело не в велосипедах, дело в том, что это не пойдет на пользу ни вам, ни остальным — вы себе
1) загадите мозги
2) будете уверены, что ОРМ кроме как по-вашему, по-другому не делаются.
3) синдром второй системы, все дела
…
N) не профит!
Вот вы чем руководствовались, когда принимали проектные решения — на выпуклый военно-морской глаз прикидывали?
Дело не в велосипедах, дело в том, что это не пойдет на пользу ни вам, ни остальным — вы себе
1) загадите мозги
2) будете уверены, что ОРМ кроме как по-вашему, по-другому не делаются.
3) синдром второй системы, все дела
…
N) не профит!
Вот вы чем руководствовались, когда принимали проектные решения — на выпуклый военно-морской глаз прикидывали?
Оглядывался на один из .Net фреймворков.
Ок. А в каком из них вы увидели это
$mes->message->value->recipient->value->country->value->name->value;
и это
$mikron->EntityManager->search("")
и это
$mikron->Modules->LoadModule('slidewindow');
?
$mes->message->value->recipient->value->country->value->name->value;
и это
$mikron->EntityManager->search("")
и это
$mikron->Modules->LoadModule('slidewindow');
?
Зато есть такое: />
В принципе например этого не обязательно писать: $mikron->Modules->LoadModule('slidewindow');
Можно обойтись добавлением записи в конфигурационный файл.
<?xml version=«1.0»?>
sample
/>
/>
/>
…
В принципе например этого не обязательно писать: $mikron->Modules->LoadModule('slidewindow');
Можно обойтись добавлением записи в конфигурационный файл.
<?xml version=«1.0»?>
sample
/>
/>
/>
…
ой, код пропал =(
<?xml version="1.0"?>
<data name="Mikron configuration file">
<attr name="default_site">sample</attr>
<list name="loadable_modules">
<data name="paginator" />
<data name="rtfgen" />
<data name="html_table" />
...
Т.е. ваш ответ можно читать как «ни в каком». Окэ. А как же вы тогда оглядывались на что-то — Или тоже придумали?
Что за фреймворк вам послужил примером в таком случае? Почему именно он?
Что за фреймворк вам послужил примером в таком случае? Почему именно он?
О, несогласные подвалили. Видимо, из тех, что пишут ORMы на пхп на завтрак и одной левой.
А как обстоят детали с автодополнением полей в IDE?
Генератор классов есть?
Генератор классов есть?
Вот можно потыкаться. bitbucket.org/sciner/mikron-php-orm/
Установка:
ВАЖНО!
Во избежания неожиданностей в виде потери своих данных
и всяких связанных с этим ко мне претензий
рекомендую использовать чистую базу данных.
Документация располагается здесь: /mikron/admin/help/mikron_orm.doc
1) Файлы должны лежать в DOCUMENT_ROOT
2) Отредактировать файл доступа к БД — /mikron/admin/sites/sample/private/access.inc
3) Указанная БД должна существовать
4) Открыть в браузере адрес: адрес.сайта/mikron/admin/schema.php
на открывшейся страничке кликнуть на ссылке «Обновить схему»
6) Открыть в браузере адрес.сайта/mikron/admin/export.php
на открывшейся страничке кликнуть на ссылке «Выполнить»
7) Готово. Теперь можно перейти на главную страницу сайта. Удачи.
Установка:
ВАЖНО!
Во избежания неожиданностей в виде потери своих данных
и всяких связанных с этим ко мне претензий
рекомендую использовать чистую базу данных.
Документация располагается здесь: /mikron/admin/help/mikron_orm.doc
1) Файлы должны лежать в DOCUMENT_ROOT
2) Отредактировать файл доступа к БД — /mikron/admin/sites/sample/private/access.inc
3) Указанная БД должна существовать
4) Открыть в браузере адрес: адрес.сайта/mikron/admin/schema.php
на открывшейся страничке кликнуть на ссылке «Обновить схему»
6) Открыть в браузере адрес.сайта/mikron/admin/export.php
на открывшейся страничке кликнуть на ссылке «Выполнить»
7) Готово. Теперь можно перейти на главную страницу сайта. Удачи.
До Propel вам очень далеко.
Далее по тексту:
Где генерация классов? Предлагаете в PHP, где нет нормально FastCGI, каждый раз XML парсить?
Причем тут ORM и модули?
А как делать морфологический моиск только по некоторым типам сущеностей?
Сравните ваше: $mikron->Queries->Query('MESSAGE_LINK' <...>
с: MessageLinkPeer::doSelect
Когда пишешь в нормальном IDE, это очень сильно ускоряет работу.
«Чтение сущности из БД зная ID» — в таком виде нельзя так делать. Обращаться в конструкторе в базу — излишне. Надо получить объект из базы по ID? — Создайте статический метод.
$mes->message->value->recipient->value->country->value->name->value;
это пипец
Короче, может, система и неплохая, но есть огромное кол-во бесяцих мелочей, которые постоянно будут разражать разработчиков.
Также есть вопросы по поводу проектирования классов, как, к примеру, шаблонизатор, встроенный в ORM.
Далее по тексту:
Где генерация классов? Предлагаете в PHP, где нет нормально FastCGI, каждый раз XML парсить?
Причем тут ORM и модули?
А как делать морфологический моиск только по некоторым типам сущеностей?
Сравните ваше: $mikron->Queries->Query('MESSAGE_LINK' <...>
с: MessageLinkPeer::doSelect
Когда пишешь в нормальном IDE, это очень сильно ускоряет работу.
«Чтение сущности из БД зная ID» — в таком виде нельзя так делать. Обращаться в конструкторе в базу — излишне. Надо получить объект из базы по ID? — Создайте статический метод.
$mes->message->value->recipient->value->country->value->name->value;
это пипец
Короче, может, система и неплохая, но есть огромное кол-во бесяцих мелочей, которые постоянно будут разражать разработчиков.
Также есть вопросы по поводу проектирования классов, как, к примеру, шаблонизатор, встроенный в ORM.
1) Генератор классов есть =)
2)
>Обращаться в конструкторе в базу — излишне.
>Надо получить объект из базы по ID? — Создайте статический метод.
Если просто создается объект, например $user = new T_USER(); то никакого обращения к БД в конструкторе не делается.
2)
>Обращаться в конструкторе в базу — излишне.
>Надо получить объект из базы по ID? — Создайте статический метод.
Если просто создается объект, например $user = new T_USER(); то никакого обращения к БД в конструкторе не делается.
3) Причем тут ORM и модули?
Это немного больше чем просто ОРМ, это смесь ORM с CMS.
4)
>$mes->message->value->recipient->value->country->value->name->value;
>это пипец
Почему-же? Все логично, а разве можно короче?
Это немного больше чем просто ОРМ, это смесь ORM с CMS.
4)
>$mes->message->value->recipient->value->country->value->name->value;
>это пипец
Почему-же? Все логично, а разве можно короче?
А можно отвечать одним комментарием?
1) Раз есть, то почему он никак не описан тут? Генератор — одна из важнейших частей.
2) Я говорю о конструкторе с параметром. Он не должен обращаться в базу. Точка.
3) Давайте все в одно место напихаем? А как же низкая связанность компонентов? Или вы считаете, что вам оно не нужно?
4) К примеру, так: $mess->getRecipient()->getCountry()->getName()->name
Уже по одной этой статье сразу видно, что вы сделали что-то, а потом, при добавлении новых плюшек, не пытаетесь нормально все спроектировать, а просто пихаете все подряд во что ни попадя. Нельзя мешать ORM с системой модулей. Нельзя мешать ORM с шаблонизатором.
Добавляете новый функционал? — Задумайтесь не потребует ли он рефакторинга.
1) Раз есть, то почему он никак не описан тут? Генератор — одна из важнейших частей.
2) Я говорю о конструкторе с параметром. Он не должен обращаться в базу. Точка.
3) Давайте все в одно место напихаем? А как же низкая связанность компонентов? Или вы считаете, что вам оно не нужно?
4) К примеру, так: $mess->getRecipient()->getCountry()->getName()->name
Уже по одной этой статье сразу видно, что вы сделали что-то, а потом, при добавлении новых плюшек, не пытаетесь нормально все спроектировать, а просто пихаете все подряд во что ни попадя. Нельзя мешать ORM с системой модулей. Нельзя мешать ORM с шаблонизатором.
Добавляете новый функционал? — Задумайтесь не потребует ли он рефакторинга.
Видимо я неверно обозначил класс приложения. Mikron — инструмент создания и управления сайтами. Модули, это его неотъемлемая часть. Все модули так или иначе созданы для облегчения программирования администраторской панели. И только во вторую очередь для использования на стороне посетителя сайта.
1) Описан, возможно пропустили, вот же: В итоге все сущности единовременно компилируются, т.е. создаются маппинги на БД и классы. Все классы наследуются от базового, в котором реализованы основные методы.
1) Описан, возможно пропустили, вот же: В итоге все сущности единовременно компилируются, т.е. создаются маппинги на БД и классы. Все классы наследуются от базового, в котором реализованы основные методы.
Извиняюсь, что опять разорвал ответ. Это не по моей вине =(
2) Какая проблема не использовать конструктор? Помоему это очень удобно, разве не так?
4) В вашем случае генератор класса должен еще и функции генерировать? А ведь каждая функция будет лишнюю память занимать, разве не так?
Не согласен, я каждый день что-то перепроектирую, на данный момент уже достигнут хороший результат. Какие-то переделки очень редко меняют саму архитектуру.
2) Какая проблема не использовать конструктор? Помоему это очень удобно, разве не так?
4) В вашем случае генератор класса должен еще и функции генерировать? А ведь каждая функция будет лишнюю память занимать, разве не так?
Не согласен, я каждый день что-то перепроектирую, на данный момент уже достигнут хороший результат. Какие-то переделки очень редко меняют саму архитектуру.
1) Они компилируются во время обработки HTTP запроса? Если да, то это бесполезно. Если предварительно, при создании сайта, — то что нужно.
2) Потому что конструктор должен только инициализировать поля. Все. Коннект к базе — дополнительная логика, которую надо выносить из конструктора.
4) Посмотрите на Propel ( propel.phpdb.org/ ). Возможно, кто-то скажет, что это не лучший ORM для PHP, но просто лично я его лучше всегда знаю.
Поймите, что ваш код уже пахнет («code smells»). Дальнейшие «улучшения» будут его только ухудшать. Слишком был плох этап проектирования.
Вы пока только на начальном этапе. У вас явно не было никакого проектирования. В вашем случае переделывать архитектуру придется раз в неделю.
А довести CRM с нуля до первого релиза — огромное кол-во человеко-часов. Это количество измеряется тысячами. И 90% времени программистов уйдет на проектирование, документирование и планирование. А без всего этого писать серьезный проект можно только для себя, никому никогда его не показывая.
2) Потому что конструктор должен только инициализировать поля. Все. Коннект к базе — дополнительная логика, которую надо выносить из конструктора.
4) Посмотрите на Propel ( propel.phpdb.org/ ). Возможно, кто-то скажет, что это не лучший ORM для PHP, но просто лично я его лучше всегда знаю.
Поймите, что ваш код уже пахнет («code smells»). Дальнейшие «улучшения» будут его только ухудшать. Слишком был плох этап проектирования.
Вы пока только на начальном этапе. У вас явно не было никакого проектирования. В вашем случае переделывать архитектуру придется раз в неделю.
А довести CRM с нуля до первого релиза — огромное кол-во человеко-часов. Это количество измеряется тысячами. И 90% времени программистов уйдет на проектирование, документирование и планирование. А без всего этого писать серьезный проект можно только для себя, никому никогда его не показывая.
1) Да, именно при создании сайта
2) Думаю, это кому как удобно, не хочешь, не пиши в конструктор, есть другой способ загрузки: $user = $mikron->Queries->QueryOne('T_USER', 1, new Criteria(...)); Вернет либо объект, либо null.
Я уже прошел этап перепроектирования, я его перепроектировал даже не раз в неделю, а по несколько раз в сутки =) И начальная документация тоже кстати имеется уже, лежит в /mikron/admin/help/mikron_orm.doc
Посмотрите чуть ниже, я привел список сайтов, которые уже написаны на нем.
2) Думаю, это кому как удобно, не хочешь, не пиши в конструктор, есть другой способ загрузки: $user = $mikron->Queries->QueryOne('T_USER', 1, new Criteria(...)); Вернет либо объект, либо null.
Я уже прошел этап перепроектирования, я его перепроектировал даже не раз в неделю, а по несколько раз в сутки =) И начальная документация тоже кстати имеется уже, лежит в /mikron/admin/help/mikron_orm.doc
Посмотрите чуть ниже, я привел список сайтов, которые уже написаны на нем.
«Кому как удобно» — не аргумент. А вот «от конструктора обычно ожидается только инициализация полей» — аргумент.
Не должен конструктор объединяться с запросом в базу. Слишком разные это задачи. Делать это надо отдельными методами. Самый удобный и логичный вариант — static метод.
Почитайте классиков, например Макконнелла «Совершенный код». По-другому станете смотреть на собственный код.
Очень странно, что наступая по много раз на одни и те же грабли «перепроектирования» вам не пришло в голову проектирование на бумаге/UML/как еще угодно.
Одно только "$mikron->Queries->QueryOne" сразу заставляет «принюхаться». Просто потому что не пишут так.
Попробуйте расписать чем ваша система лучше других. Можно просто для себя. Привести примеры использования, use-case'ы и т.п. Это может очень сильно помочь.
Не должен конструктор объединяться с запросом в базу. Слишком разные это задачи. Делать это надо отдельными методами. Самый удобный и логичный вариант — static метод.
Почитайте классиков, например Макконнелла «Совершенный код». По-другому станете смотреть на собственный код.
Очень странно, что наступая по много раз на одни и те же грабли «перепроектирования» вам не пришло в голову проектирование на бумаге/UML/как еще угодно.
Одно только "$mikron->Queries->QueryOne" сразу заставляет «принюхаться». Просто потому что не пишут так.
Попробуйте расписать чем ваша система лучше других. Можно просто для себя. Привести примеры использования, use-case'ы и т.п. Это может очень сильно помочь.
1) «Совершенный код», уже пол книжки прочитал =) и продолжаю читать.
2) $mikron->Queries->QueryOne — объектный подход, не спорю, это частый момент, можно наверно дописать MikronQueries::Query()? Правильно?
2) $mikron->Queries->QueryOne — объектный подход, не спорю, это частый момент, можно наверно дописать MikronQueries::Query()? Правильно?
>Не должен конструктор объединяться с запросом в базу. Слишком разные это задачи. Делать это надо отдельными методами. Самый удобный и логичный вариант — static метод.
Это ли не короткий метод загрузки объекта без использования непонравившегося Вам $mikron->Queries->QueryOne?
Это ли не короткий метод загрузки объекта без использования непонравившегося Вам $mikron->Queries->QueryOne?
Согласен. Пересмотрел логику. Как насчет такого метода?
$user = T_USER::Load($id);
$user = T_USER::Load($id);
Если что, в Mikron SQL-запросы генерируется автоматически.
Кстати при использовании метода $qr = $mikron->Queries->Query(...); используется ленивая загрузка.
Каждый объект подгружается только при обращении к нему, например в цикле while
while($user = $users->fetch())
{…
}
Кстати при использовании метода $qr = $mikron->Queries->Query(...); используется ленивая загрузка.
Каждый объект подгружается только при обращении к нему, например в цикле while
while($user = $users->fetch())
{…
}
Поверьте, это уже далеко не сырой продукт, я его уже пол-года пишу.
В общем я и выложил то все сюда, с целью послушать комментарии, советы, возможно даже кто-то поправит меня где-то, предложит что-то лучшее.
Расскажите пожалуйста про целесообразность использования xml настроек конкретно в вашем проекте.
XML описания сущностей или конфигурационного файла Mikron?
описание сущностей
Наличие средств разбора, валидации, преобразования. Легко модифицировать в любом текстовом редакторе. Хотел в начале сделать описание на самом PHP, но потом решил, что всетаки файл настроек должен легко читать используя любой язык программирования, а не только PHP.
просто у меня с некоторого времени небольшое отвращение к xml для описания сущностей. ведь всегда можно получить структуру из таблицы, связи через внешние ключи. на крайний случай добавить возможность генерации xml файлов из готовой бд
Здесь наоборот, из XML автоматически генерируется и модифицируется таблица БД.
А зачем? Обычно я рисую uml диаграммы и по ним генерится sql скрипт для создания БД. Зачем мне еще и xml писать, если есть красивая диаграмма?
Так ведь на основе этого XML еще и классы генерируются?
из базы?
На основе XML генерируются таблицы БД + php классы этих самых сущностей
но что мне делать если есть уже готовая база и которую менять нельзя? зачем мне напрягаться и писать xml конфиги?
Таблицы может и есть, но ведь в них нет той информации, которая требуется для описания самой сущности, это просто таблицы. ORM не обладает искусственным интеллектом, который может случайные таблицы БД превратить в сущности и догадаться какое поле за что отвечает, как называется по русски и что туда еще можно записать. Mikron как раз позволяет спроектировать такую упорядоченную структуру.
почему нет? есть поля с типами и есть foreign keys. остаеться описать только связи типа has_many, has_one, belongs_to и т.д. описывать еще раз поля нет желания и необходимости.
P.S. Convention over configuration.
P.S. Convention over configuration.
А как же русскоязычные имена полей, справочники для некоторых полей, описание типов данных, для возможности построения автовалидаторов?
в конце концов Вы можете оставить ваши таблицы в покое и описать в схеме Mikron сущность совпадающую по имени с названием таблицы, а также поля совпадающие по именам =)
Вся суть именно в том, что описывается в ORM. Разве другие ORM поступают иначе?
Вся суть именно в том, что описывается в ORM. Разве другие ORM поступают иначе?
Реализовал 4 метода вычитки объекта из БД.
Какой оставить, никак не решусь… Помогите плиз с решением.
- $user = new T_USER($id);
- $menu = T_USER::Load($id);
- $menu = $mikron->Queries->QueryOne('T_USER', $id);
- $menu = MikronBaseObject::getInstance('T_USER', $id);
Какой оставить, никак не решусь… Помогите плиз с решением.
Никакой.
Про первый я уже писал.
Второй должен быть заменен на два: byPrimaryKey и byCriteria
Третий жутко неудобен
Четвертый… «getInstance» — создание экземпляра класса? Банальный вызов конструктора? Вы сами пытаетесь понять какие мысли придут в голову работающим с вашим кодом людям?
Еще раз советую посмотреть Propel.
Про первый я уже писал.
Второй должен быть заменен на два: byPrimaryKey и byCriteria
Третий жутко неудобен
Четвертый… «getInstance» — создание экземпляра класса? Банальный вызов конструктора? Вы сами пытаетесь понять какие мысли придут в голову работающим с вашим кодом людям?
Еще раз советую посмотреть Propel.
Kohana-orm
$user = ORM::factory('user', $id);
// здесь еще не было никаких обращений к базе. данные достанут либо при первом обращении к объекту $user->id; либо ручным вызовом метода $user->reload();
$user = ORM::factory('user', $id);
// здесь еще не было никаких обращений к базе. данные достанут либо при первом обращении к объекту $user->id; либо ручным вызовом метода $user->reload();
Не забросили? Как продвигается разработка?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Mikron. PHP ORM