|
|
|
aktuba |
|
|||
Смышленный Профиль Группа: Завсегдатай Сообщений: 1915 Регистрация: 24.4.2006 Где: Планета Земля Репутация: нет Всего: 38 |
Доброго времени суток. Изучаю ruby и уперся в какую-то не понятную, для меня, проблему. Не могу разобрать yaml-файл. Содержимое такое:
Подскажите, люди добрые, как из этого получить массив? yaml.to_a не работает, говорит "undefined method `bytesize' for #<Array:0x000000058cbdd8> file: utils.rb location: bytesize line: 281" (( -------------------- |
|||
|
||||
source777 |
|
|||
Эксперт Профиль Группа: Завсегдатай Сообщений: 1878 Регистрация: 12.3.2007 Репутация: 6 Всего: 56 |
Массив какого вида? Так то приведённые данные из yaml конвертируются явно в хэш, а не в массив.
-------------------- Если бы программистам платили за то, чтобы убирать код из программы вместо того, чтобы добавлять его, программы были бы намного лучше © Николас Негропонте |
|||
|
||||
aktuba |
|
|||
Смышленный Профиль Группа: Завсегдатай Сообщений: 1915 Регистрация: 24.4.2006 Где: Планета Земля Репутация: нет Всего: 38 |
Вот такого вида получаю данные. Задача - перебрать конфиг и найти подходящий роут и это не получается ( -------------------- |
|||
|
||||
source777 |
|
|||
Эксперт Профиль Группа: Завсегдатай Сообщений: 1878 Регистрация: 12.3.2007 Репутация: 6 Всего: 56 |
Такого вида получатся после hash.to_a, хотя с хэшем привычнее...
Непонятно, что из себя представляет "перебрать конфиг и найти подходящий роут". Какие варианты входных данных? -------------------- Если бы программистам платили за то, чтобы убирать код из программы вместо того, чтобы добавлять его, программы были бы намного лучше © Николас Негропонте |
|||
|
||||
aktuba |
|
||||
Смышленный Профиль Группа: Завсегдатай Сообщений: 1915 Регистрация: 24.4.2006 Где: Планета Земля Репутация: нет Всего: 38 |
В том-то и проблема, что to_a нету. Вот код:
Входные параметры в первом посте (.yml файл). Что хочется: взять возможные роуты из yml-файла, перебором найти подходящий под текущий запрос и вызвать нужный контроллер и action. -------------------- |
||||
|
|||||
source777 |
|
||||
Эксперт Профиль Группа: Завсегдатай Сообщений: 1878 Регистрация: 12.3.2007 Репутация: 6 Всего: 56 |
Не, я имел в виду входные параметры для поиск по роутам. Ну а как тогда? Может это конечно как-то от версий зависит, но скопировав в файл данные из первого поста у меня получается только так:
Впрочем, для перебора то какая разница, что хэш, что массив массивов.. всё едино:
-------------------- Если бы программистам платили за то, чтобы убирать код из программы вместо того, чтобы добавлять его, программы были бы намного лучше © Николас Негропонте |
||||
|
|||||
aktuba |
|
||||
Смышленный Профиль Группа: Завсегдатай Сообщений: 1915 Регистрация: 24.4.2006 Где: Планета Земля Репутация: нет Всего: 38 |
Пока никаких. По сути - request.path_info Код выше, ничего другого нет. Версии ruby и yaml такие же, как у тебя. Возможно дело в sinatra.
Так говорю-же, to_a не работает ("undefined method `bytesize' for #<Array:0x000000058cbdd8> file: utils.rb location: bytesize line: 281"), а перебор по Symbol не подходит, так как планируется нечто подобное:
Т.е., заранее не известны параметры роута. -------------------- |
||||
|
|||||
aktuba |
|
|||
Смышленный Профиль Группа: Завсегдатай Сообщений: 1915 Регистрация: 24.4.2006 Где: Планета Земля Репутация: нет Всего: 38 |
routes.inspect выдает тоже самое, как у тебя. Я до этого смотрел через p routes ( -------------------- |
|||
|
||||
aktuba |
|
||||
Смышленный Профиль Группа: Завсегдатай Сообщений: 1915 Регистрация: 24.4.2006 Где: Планета Земля Репутация: нет Всего: 38 |
Видимо я чего-то не понимаю в ruby или yaml... Переписал код в такой вид:
Вот yaml-файл:
На выходе ожидаю получить action в каждом роуте (т.е., '(login|logout|register|restore)index' ). Но, почему-то, на выходе получаю названия роутов, т.е. 'userdefault'. Что не так делаю? o_O -------------------- |
||||
|
|||||
source777 |
|
||||||
Эксперт Профиль Группа: Завсегдатай Сообщений: 1878 Регистрация: 12.3.2007 Репутация: 6 Всего: 56 |
Это ты не из puts получаешь, это блок each возвращает перебираемый массив, это т.н. fluent interface. А puts очевидно выводит тебе две пустых строки, т.к. ключа 'action' не существует. Вот :action есть, ты ж сам во входном файле символы используешь вместо строк:
Ну и в целом такой способ перебора кривоват, правильнее так:
У sinatra есть своя система роутинга, зачем писать велосипед? -------------------- Если бы программистам платили за то, чтобы убирать код из программы вместо того, чтобы добавлять его, программы были бы намного лучше © Николас Негропонте |
||||||
|
|||||||
aktuba |
|
||||
Смышленный Профиль Группа: Завсегдатай Сообщений: 1915 Регистрация: 24.4.2006 Где: Планета Земля Репутация: нет Всего: 38 |
Не, это я экспериментировал с routes.yml. В любом случае, проблема не в этом, см. дальше. Выдает "userdefault" Выдает:
Последний вариант сейчас виден на getnotify.ru. Дополнительно приложил все файлы, может в них что не так ( Потому что в синатре пипец какой не удобный роутинг (((. Для меня. Язык на полном ооп, а роуты на def (то бишь, фактически на функциях). P.S.: а еще мне в php, в kohana, нравятся роуты за такие конструкции:
Один-два роута и хватает на все приложение. В синатре так невозможно (( Это сообщение отредактировал(а) aktuba - 6.6.2012, 22:41 Присоединённый файл ( Кол-во скачиваний: 2 ) ruby.rar 3,37 Kb -------------------- |
||||
|
|||||
source777 |
|
|||
Эксперт Профиль Группа: Завсегдатай Сообщений: 1878 Регистрация: 12.3.2007 Репутация: 6 Всего: 56 |
Так ты результат в браузере что-ли смотришь!? puts ведь туда в принципе ничего не выводит, puts выводит только в консоль!
Браузер показывает тебе то, что возвращает метод execute. Замени перебор хэша на это:
И будет тебе и в браузере видно. -------------------- Если бы программистам платили за то, чтобы убирать код из программы вместо того, чтобы добавлять его, программы были бы намного лучше © Николас Негропонте |
|||
|
||||
source777 |
|
|||
Эксперт Профиль Группа: Завсегдатай Сообщений: 1878 Регистрация: 12.3.2007 Репутация: 6 Всего: 56 |
Насчёт невозможно - это ты конечно загнул. По сути это самый примитивный MVC-роутинг. Другой вопрос, что для MVC логичнее Rails использовать.. Область применения Sinatra в основном там, где MVC крайне нежелателен. Если уж очень хочется именно на Sinatra, то начни хотя бы с Padrino. Это сообщение отредактировал(а) source777 - 7.6.2012, 00:11 -------------------- Если бы программистам платили за то, чтобы убирать код из программы вместо того, чтобы добавлять его, программы были бы намного лучше © Николас Негропонте |
|||
|
||||
aktuba |
|
||||
Смышленный Профиль Группа: Завсегдатай Сообщений: 1915 Регистрация: 24.4.2006 Где: Планета Земля Репутация: нет Всего: 38 |
Блин, не знал про это. Thx. Помогло! Спс огромное, завтра буду дальше разбираться. Вернул веру в руби ))) Ну может совсем немного... Но в целом сказал как есть ;) Не поверишь - не хочу. Почитал про rails, посмотрел примеры, бенчмарки. Не хочу юзать рельсы )
Я когда-то кохану выбрал именно по той причине, что дает только основу и огромные возможности. С синатрой так же, по сути. А вот padrino не получилось заюзать. Уже не помню почему, но не работало у меня (( Да и наворочено лишнего. Например, я очень не люблю кодогенераторы. До сих пор не понимаю смысла миграций. В padrino отсутствует поддержка mysql2, насколько я помню, а orm/active record я обхожу стороной (правда, это из-за php, но не думаю что в руби с этим лучше будет). Ну и роуты в padrino тоже не блещут удобством )) P.S.: мечта - найти ko3 на руби. Пока не нашел ((( -------------------- |
||||
|
|||||
source777 |
|
||||||
Эксперт Профиль Группа: Завсегдатай Сообщений: 1878 Регистрация: 12.3.2007 Репутация: 6 Всего: 56 |
Да нет в роутинге Sinatra никаких ограничений, делай любой роут какой захочешь:
Для реального использования, конечно, надо получше продумать регулярку в части controller и action, но в качестве proof-of-concept и так сойдёт.
Да не всё так страшно, в рельсах только запуск приложения подтормаживает. В остальном всё ok. А бенчмарки - они как всегда забывают, что реальные приложения упираются прежде всего в кривые алгоритмы, медленные выборки из БД и т.п., по сути влияние фреймворка стоит во втором десятке факторов, влияющих на производительность. Кроме того бенчмарки никогда не сравнивают оптимальные для конкретной задачи решения. Т.е. для вывода "Hello world!" они непременно заюзают весь Rails-стек, вместо
Kohana - это ведь один из клонов Rails под PHP Если мечта добавлять нужное на основу, то есть rails-api Это как? Гем не подключен по умолчанию? Кто-то заставляет тебя их использовать? Хотя на стадии обучения кодогенераторы - вещь очень полезная, чтобы вникнуть в style guide конкретного фреймворка. Очень зря. Обходить best practices стороной из-за того что под PHP кривая реализация попалась весьма странно, под PHP нормальные реализации вообще редкость... Помню ActiveRecord в Code Igniter, так там от этого паттерна ничего кроме названия нет. -------------------- Если бы программистам платили за то, чтобы убирать код из программы вместо того, чтобы добавлять его, программы были бы намного лучше © Николас Негропонте |
||||||
|
|||||||
aktuba |
|
|||
Смышленный Профиль Группа: Завсегдатай Сообщений: 1915 Регистрация: 24.4.2006 Где: Планета Земля Репутация: нет Всего: 38 |
Ну это понятно, можно вообще без синатры обойтись и сделать такой-же роут, верно? Я-то говорю про другое - про простоту использования, удобство написания роутов и пр. Согласен. Но пока все-равно не возникло желание юзать рельсы ). Путаешь с CakePHP, похоже. Kohana ни капли на руби не похожа ;) Имел в виду генераторы padrino. Datamapper, sequel и пр. он-же поддерживает. ;) Не поверишь - документация. Я, например, не нашел описания структуры приложения. Подскажешь где посмотреть? С каких пор попытка превратить реляционную базу в объектную - best practices? Если я работаю с реляционной базой, мне проще написать нормальный, более-менее оптимизированный запрос, а не использовать кучу оберток над базой только для того, чтобы написать тот же запрос, но использую сторонний синтаксис. Я многих просил показать преимущества orm, например. Особенно, если база денормализована. Поможешь понять? ) -------------------- |
|||
|
||||
source777 |
|
||||||
Эксперт Профиль Группа: Завсегдатай Сообщений: 1878 Регистрация: 12.3.2007 Репутация: 6 Всего: 56 |
Ну в плане удобства нет особой разницы с примером, который ты привёл из Kohana. Различие, не считая синтаксиса, только в том в Sinatra роутинг не отделён от обработки, но это часть идеологии. Хочется изолированный роутинг - welcome to Rails. Да, их там столько что всех не упомнишь... На Ruby они все не похожи, т.к. у PHP синтаксис гораздо менее изящен. CakePHP - самый древний кажись.. копия ещё с Rails 1. Но есть же копии и с более свежих версий, типа Yii, Symfony, etc. А Kohana - это CI с нормальным MVC?
Ну для структуры приложения нужно только 1 раз 1 генератор запустить. В этом то ничего страшного нет. Просто выбор гемов, которые будут по умолчанию. Никто потом тебя не будет ограничивать только ими. А ненужные по твоему мнению компоненты можно пропустить передав none генератору.
Базу никто не трогает. Best practices - это не нарушать целостность концепции. В ООП программе всё есть объект, чтобы получить объекты на основе данных в БД и существует ORM. Плюс не забывай, что ActiveRecord - это самый простой ORM. Другой подход - работать с БД через хранимые процедуры и триггеры. Оба способа - best practices, всё что между ними (например, SQL-запросы в контроллере или в представлении) - плохой дизайн. Обертки в любом случае понадобятся, если это не единичные запросы. Иначе опечатки, шредингбаги и sql-инъекции будут в изобилии. Т.е. ты либо используешь готовую, хорошо протестированную библиотеку, либо просто напишешь свой mapper, разработку и отладку которого под конкретный проект должен будет оплатить заказчик. -------------------- Если бы программистам платили за то, чтобы убирать код из программы вместо того, чтобы добавлять его, программы были бы намного лучше © Николас Негропонте |
||||||
|
|||||||
aktuba |
|
||||
Смышленный Профиль Группа: Завсегдатай Сообщений: 1915 Регистрация: 24.4.2006 Где: Планета Земля Репутация: нет Всего: 38 |
Ну теперь я хотя-бы знаю, почему говорят руби - подразумевают рельсы )) Это 2-я версия такая была. 3-ка совсем другая, значительно приятнее и удобнее.
Ну вот видишь, теперь и ты заставляешь генератором пользоваться ))). А я не хочу. Серьезно. Спорное утверждение, на мой скромный взгляд.
В том-то и суть, что данные - это не программа. И совсем не факт, что данные в виде объектов могут быть, в каких-то случаях, удобнее плоских данных. Да и вообще, это полностью проблема модели, в каком виде возвращать данные, т.к. сами данные могут быть где угодно, помимо локального хранения. Вплоть до генерации этих самых данных. Мне вот намного удобнее работать с данными как с массивом, т.е. в плоском виде. Ну я не говорил про запросы в контроллерах и, тем более, во вьюхах ). Я говорил про то, что переводить данные из одного типа в другой только для того, чтобы прочитать их - не лучший подход. Тоже не факт. Пример - pdo в php. Сам по себе исключает большинство возможных проблем, не создавая дополнительных сущностей и оверхеда. Кроме того, обертки бывают разные. ORM - это не обертка, это именно конвертер методов в запрос и результатов в объекты. И оверхед делает совсем не слабый, по моему опыту. -------------------- |
||||
|
|||||
source777 |
|
||||||||
Эксперт Профиль Группа: Завсегдатай Сообщений: 1878 Регистрация: 12.3.2007 Репутация: 6 Всего: 56 |
Ну это только в части веб-разработки. По сути Rails - основной веб-фреймворк. Остальные стараются продвинуть другие идеологии, поэтому взять веб-фреймворк на Ruby, но не Rails, и пытаться работать на нём как в Rails - выглядит странно.
Так я думал, что ты изначально говорил про генераторы контроллеров, моделей, тестов и т.д., а создание приложения - это уже даже не ассоциируется с генератором, хотя формально им является. Зачем этого избегать? Ведь в том же Kohana ты делаешь тоже самое, только BDSM способом: зайти на сайт, скачать, распаковать, начать работу в директории application. В данном же случае генератор просто сразу создаёт аналог директории application.
Проблема модели - в каком виде получать данные, а возвращать надо придерживаясь принятого в проекте API модели. Для MVC-проектов - это в 99% проектов будет объект. Можно, конечно, уходить в андеграунд и плевать на общепринятые концепции, но это для случая когда программирование выступает в роли способа самовыражения или хобби, если же программирование выступает в роли ремесла, то плыть против течения - тупо не выгодно.
Ну ты мне не оставил других вариантов... Ведь если ты получаешь данные в модели, то ты либо используешь ORM... либо не используешь ООП, что для Ruby нонсенс. Преждевременная оптимизация - корень всех зол. Ну сэкономишь ты пару мс в среднем на страницу, а кода в моделях будет в разы больше, причём большая часть будет в строковом представлении. Ничего хорошего тут нет. Особенно если ты работаешь не в гордом одиночестве. Я сам иногда использую SQL-запросы, но только когда это оправдано. Обычно получается не более 1 raw-SQL запроса на 1000 LOC проекта. -------------------- Если бы программистам платили за то, чтобы убирать код из программы вместо того, чтобы добавлять его, программы были бы намного лучше © Николас Негропонте |
||||||||
|
|||||||||
aktuba |
|
||||||
Смышленный Профиль Группа: Завсегдатай Сообщений: 1915 Регистрация: 24.4.2006 Где: Планета Земля Репутация: нет Всего: 38 |
Ну так я не хочу как в rails, хочу так, как мне удобно. Пусть и похоже, но это разные вещи. По нескольким причинам. Начиная с того, что я недолюбливаю *nix (но и без него никуда, к сожалению) и заканчивая тем, что генератор делает что-то помимо меня, заставляет лезть в консоль и пр. Не поверишь, скорее всего, но до руби у меня никогда не было необходимости лезть в консоль. Хотя опыт работы в вебе достаточно большой. Верно. Но делается это с помощью браузера и ftp-клиента. Все! И это правильно, на мой взгляд...
Не-не-не... Взаимосвязь контроллер-модель - отдельный вопрос. Я сторонник тонких моделей. А вот возвращать надо исходя из api приложения, а не платформы. Где-то, объектная модель будет только на пользу, а где-то только во вред. Второй случай - большие объемы данных, зависимость от скорости обработки и т.п. А вот это уже заблуждение. Точнее - привычки разработчиков. Но это судя по моему опыту, который у каждого свой... Выгодно - когда удобно, а не модно, верно? Простой пример - на работе делаем довольно крупные и нагруженные проекты на php. Так вот в коде нет НИ ОДНОГО ОБЪЕКТА. Вообще. Только статичные классы. И я тоже плевался, когда впервые увидел. Но проанализировав плюсы и минусы могу смело сказать, что это оправдано и удобно (хотя и не везде в проекте). Так и тут - я не вижу никаких плюсов в orm, не вижу удобств - так зачем оно мне?
Стоп-стоп-стоп! С чего бы это получение данных в модели сразу становится завязанным на orm? o_O Не понимаю данной логики. Еще раз - данные и организация кода - это совсем разные вещи. И как не извращайся (при использовании mysql, например) - данные всегда будут в плоском виде. А код - ООП. Что не так? Аааабсолютно верно! Но ты же не пишешь сначала плохой код, а потом переписываешь на нормальный? Так и тут - если известны проблемы, то они обходятся сразу и сложно это считать оптимизацией. Простой пример из мира php: если в for использовать count - цикл выполняется, примерно, на 50% дольше. Зная это, вряд ли будешь использовать count в for, верно? Разве-ж это оптимизация? ) А вот это как-раз зло. Экономия пары мс ничего не значит, но экономия сотен мс на страницу значит очень много. И еще раз повторю - кода в модели у меня будет довольно мало (в основном, сами запросы), а вот в контроллерах будет достаточно.
Значит ты сможешь дать внятные примеры, когда это НЕ оправдано? Правда, ведь? ) -------------------- |
||||||
|
|||||||
aktuba |
|
|||
Смышленный Профиль Группа: Завсегдатай Сообщений: 1915 Регистрация: 24.4.2006 Где: Планета Земля Репутация: нет Всего: 38 |
Еще вопрос, если можно. Что в данном коде не так?
Это сообщение отредактировал(а) aktuba - 8.6.2012, 01:14 -------------------- |
|||
|
||||
source777 |
|
||||||||||||
Эксперт Профиль Группа: Завсегдатай Сообщений: 1878 Регистрация: 12.3.2007 Репутация: 6 Всего: 56 |
Ну т.е. другими словами тебя просто поработила привычка работать мышкой. В таком случае ты можешь поставить IDE типа Rubymine и продолжать работать как привык, ища нужный пункт в меню, либо осваивать прелести консоли. Просто в винде консоль - дохлая, если без power shell то вообще ни о чём. А у пользователей MacOS X и GNU/Linux консоль - это основное рабочее окно.
Ну так неудобно ведь! Не говоря уж о том, что такие проекты предоставляют только 1 вариант начального приложения. Тогда как проекты с генераторами начального приложения дают тебе гораздо больше свободы выбора. Ну правильно, привычка разработчиков. А заблуждение то где? Ведь это в первую очередь привычка разработчиков всех популярных веб-фреймворков.
Ну вот ты и сознался, что не используешь ООП. Нравится - пожалуйста, но это на PHP, где нормальной поддержки ООП никогда не было, и даже stdlib полностью в процедурном стиле. А на Ruby проекты без ООП если и существуют, то в пренебрежимо малом количестве. Основное заблуждение тут в том, что объекты что-то замедлили бы в вашем проекте, это не более чем самооправдание за плохой дизайн. Я видел много крупных, нагруженных проектов, но ни в одном из них создание объектов или ORM не были узким местом. Проблемы под нагрузкой у всех выплывают, но они совсем в другом. ORM - это по сути получение данных модели в изолированном классе. Если для каждой модели есть отдельный класс или экземпляр класса(O), в котором сосредоточена работа(M) с внешним реляционным хранилищем данных®, то имеет место ORM. Дальше уже вариации - самописный или библиотечный. Другими словами, если ты не используешь ActiveRecord, то это ещё не значит, что ты не используешь ORM. Посмотри, например, Sequel, совсем не похоже на ActiveRecord, но тоже ORM.
Хм, критерии нормальности не всегда очевидны, точнее они почти всегда субъективны, причём даже эта субъективность меняется со временем. В самом по себе в ORM нет ни одной объективной, широко известной проблемы. Могут быть проблемы с твоей т.з., но раз есть миллионы профессиональных разработчиков, которые не разделяют эту т.з., значит это сугубо субъективные проблемы. Понятно, что эгоцентризм - неотъемлемая часть человеческой природы, но иногда и по сторонам оглядеться бывает полезно.
Ну сотни мс - это хорошо, но фишка то в том, что отказом от ORM и 10 мс хрен выиграешь. Возможно тебе просто попадались случаи неумелого использования ORM, когда вместо одного запроса генерировалось N*(N+1). Но это проблема кривых рук, а не ORM. А личное представление об ORM из-за этого получилось искажённым.
По умолчанию это не оправдано. Писать "SELECT * FROM my_app_db.topics WHERE (deleted_at IS NULL) LIMIT 10" вместо Topic.active.limit(10) нет никакого смысла. Если у тебя поменяются критерии активности топиков, то достаточно будет изменить одну строчку scope :active в модели, а не переписывать каждый раз все запросы на выборку топиков по всему проекту. Другой плюс, что запись Topic.active.limit(10) короче и читабельнее, т.к. не требует переключения контекста на другой ЯП (SQL - это ведь тоже ЯП, хоть и DSL). Проще говоря, нужна очень весомая причина, чтобы впихнуть строчку на SQL в код на другом языке. А оправдано только в тех случаях, когда абстракция ORM затрудняет написание оптимального запроса, что бывает весьма редко по факту. И даже в таких случаях предпочтительнее написать хранимую процедуру, чтобы не смешивать SQL-запросы и код в одну кучу. Добавлено через 2 минуты и 57 секунд В Ruby нет ассоциативных массивов, как в пыхе. В Ruby есть хэши. -------------------- Если бы программистам платили за то, чтобы убирать код из программы вместо того, чтобы добавлять его, программы были бы намного лучше © Николас Негропонте |
||||||||||||
|
|||||||||||||
aktuba |
|
||||||||||||||||||||||||||
Смышленный Профиль Группа: Завсегдатай Сообщений: 1915 Регистрация: 24.4.2006 Где: Планета Земля Репутация: нет Всего: 38 |
RubyMine меня устраивает, хотя и в консоли (правда DOS), я в свое время поработал. Да как-раз наоборот - очень удобно. Что значит "1 вариант начального приложения" не совсем понял, но скорее всего имеется в виду, что нет возможности одной командой поставить кучу дополнений ). Если прав - нафиг не надо, т.к. часто либо в репах не последние версии, либо наоборот - последние, а нужны старые. Мне проще самому залить то, что надо и туда, куда мне удобно!
Заблуждение в процентах. Далеко не 99% разработчиков используют объектную модель данных. В том-же php я считаю подобное злом, т.к. создает только дополнительный оверхед, не давая взамен никаких (т.е. абсолютно никаких) дополнительных возможностей или удобств. Где? o_O Вообще-то, на работе я не программер, а вот свой код у меня только ООП - привычка из делфей осталась ;)
Ошибка. На данный момент мои программеры переписывают 2 проекта на новую платформу. Перед проектированием мы делали довольно обширные тесты. Результат - в вакууме (на hello world) объекты выигрывают по скорости, но проигрывают по объему. На реальных данных, в реальных условиях - объекты проигрывают по всем пунктам. В твоих словах видны лишь штампы, не проверенные ничем ;)
Могу назвать минимум 1 проект, где ORM стал узким местом. Переписывание на plain-sql решило проблему в разы. Конечно-же, можно сказать, что не ORM стало узким местом в нагруженном проекте, а используемое железо, но ведь это будет ложь ;)
Не-не-не... Не надо путать меня и других ;). ORM - это способ представления и работы с данными. И "класс" тут совсем не к месту. Более того - класса может не существовать вообще, если реализовать ORM на уровне драйвера к ЯП, например. ORM - это именно паттерн, с помощью которого пытаются превратить один тип данных в другой. Ни разу не так... ORM - виртуальная прослойка(Model) между кодом(Object) и данными(Relational mapping). С чего-бы вдруг данные подразумевают под собой объектность - мне не понятно. Как уже говорилось - данные могут быть не только в базе, они могут вообще не существовать до момента необходимости в них.
Не использую. Более того, я работаю с данными (в большинстве случаев) в том виде, в котором они представлены. Т.е, например, при работе с базой я работаю с таблицами и строками, при работе с документами - со страницами и т.д.
Смотрел, поэтому и выбрал mysql2 ;)
Миллион мух не могут ошибаться? Ну да, ну да... А если серьезно, то миллионы разработчиков используют php и знать-не знают про ооп, orm, тесты и пр. Значит ли это, что проблема в профессиональных разработчиках? ) Да и проблем у меня нет, просто я не понимаю смысла в использовании orm где-то, кроме самых простых проектов.
Повторюсь - в разы помогла смена orm на plain-sql. В цифрах примерно так: было 3 сервера с нагрузкой в 10-15%, осталось 2 с нагрузкой в 3-4%. Понимаю, что большая часть проблем в самой реализации orm в php, но все-же результат "на лицо", как говориться.
Я выше просил - покажи пример, когда orm полезен. Когда он действительно даст какую-то производительность труда (ведь именно этим прикрываются абсолютно во всех постах про orm) и пр.
Почему это "нет смысла"? Во-первых, в запросе я вижу откуда и какие данные получаю, связи, условия. А ты в orm не видишь, что значит active даже. Это может быть поле в таблице, условие в коде или то и другое вместе. И чтобы это знать, надо либо помнить, либо искать в коде/в базе. То ты говоришь про плохой дизайн, то вдруг у тебя меняются критерии данных... Ну ок, убедил - плюс orm в том, что вместо поиска по коду надо будет в 1-2-х местах поправить 1-2 строки. И ради этого плюса использовать всю обертку? Ну уж нет, спасибо. Я выше уже ответил на это. Минус это для начинающих разработчиков, для проф - это плюс. Кроме того, для описания схемы orm необходимо знать связи, структуру и, самое главное, принцип работы базы. Часто более-менее сложный запрос можно оптимизировать, использую определенные ключи или доп.запросы/подзапросы. Через ORM этого сложно добиться. Еще пример - как получить данные из 2-х таблиц, которые никак не связанны между собой, но в условиях запроса участвуют? Включать в orm sql-выражения? )
А еще, когда нужна скорость работы, например. Но я-то спрашивал другое - когда НЕ оправдано использовать plain-sql? Те плюсы, которые ты привел - это попытка объяснения когда оправдано использовать orm, а мне интересен другой момент ;) Если перефразировать: "sql не оправдано использовать, когда приходится часто менять критерии выборки данных". Но изменение критериев - редкий случай ;)
Эмм... Сорри, конечно, но это уже какой-то диагноз... Что значит "не смешивать sql и код"? ORM берет данные не использую sql? Или то, что спрятали запросы - они перестали существовать? Я использую plain-sql как-раз по той причине, что хочу видеть и контроллировать процесс работы приложения.
Разобрался, thx. Это сообщение отредактировал(а) aktuba - 9.6.2012, 14:20 -------------------- |
||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||
source777 |
|
||||||||||||||
Эксперт Профиль Группа: Завсегдатай Сообщений: 1878 Регистрация: 12.3.2007 Репутация: 6 Всего: 56 |
Так я этого и не писал.. Я писал про 99% MVC-проектов. А MVC - это ООП паттерн.
Сами запросы при этом изменились по сравнению с теми, которые генерировал ORM? Если да, то проблема была не в ORM, а в кривых руках программистов, его применявших. Если нет, то никаких ускорений в разы быть не может. Мои слова проверены личным опытом и профайлером.
Тяжёлый случай Ты даже наличие модели предметной области считаешь минусом. Хотя MVC по определению подразумевает, что никто кроме модели не знает откуда и какие данные она получает.
Требования меняются всегда. Это аксиома любого проекта с внешним заказчиком. Если дизайн затрудняет внесение изменений, то он плох.
Ну это конечно зависит от реализации ORM, но в целом неправда. Как я уже писал выше, случаи когда сложно написать оптимальный запрос с помощью ORM очень редки. И в этих случаях как раз оправдано применение raw SQL.
1. Структуру БД тоже рефакторить надо периодически. А то ты своими примерами сейчас выдашь ещё и хреновый дизайн БД. ;) 2. Зависит от конкретной ситуации, от представления в СУБД до plain-SQL запроса в модели. Использовать ORM в 100% запросов также глупо как не использовать ORM совсем. Ну я не видел ещё ни одного проф. разработчика не пользующегося абстракциями, а вот новичков видел сотни. Так что всё наоборот. Необходимость изоляции деталей реализации приходит с опытом.
Ну зачем дурачка то включать? Не смешивать sql и код, работающий с моделью. P.S. Пора закруглять оффтопик, каждый кулик волен оставаться в своём болоте. Я лишь хотел направить на Ruby-way, т.к. с твоими убеждениями успешно программировать на Ruby вряд ли получится. Это для тебя будет, что называется, роль на сопротивление. -------------------- Если бы программистам платили за то, чтобы убирать код из программы вместо того, чтобы добавлять его, программы были бы намного лучше © Николас Негропонте |
||||||||||||||
|
|||||||||||||||
aktuba |
|
|||
Смышленный Профиль Группа: Завсегдатай Сообщений: 1915 Регистрация: 24.4.2006 Где: Планета Земля Репутация: нет Всего: 38 |
Ну раз заканчиваем, тогда коротко:
С чего-бы? index.php © + data.php (M) + view.php (V) - уже не MVC? Какая разница, что и как у них внутри, если MVC - это паттерн организации проекта, а не кода? Конечно менялись, ради этого и отказались от orm. И нет, дело не в кривых руках программистов, а в кривых руках разработчиков ORM, который не позволял использовать фичи базы, использую только основной функционал. Почти во всех реализациях ORM дело обстоит так же. На простых запросах? ) Не-не-не, не правда )). У меня запросы в модели, полностью огорожены от приложения. И только модель знает про данные. Сама модель - плюс, а ORM (пока еще) - минус.
Возможно поэтому мне и не понятно требование юзать orm. Я очень редко работаю на внешнего заказчика и еще реже меняются требования к проекту. Хотя нет, даже при таких аксиомах - orm лишний блок в приложении. Вот как-раз на моей практике все иначе. Проф.разработчики почти не пользуются orm (только когда достается код других людей). А новички, увидев верхушку айсберга, начинают использовать везде. И да, это приходит с опытом ))) Возможно. Но раз можно пользоваться plain-sql в ruby - все не так уж и плохо ;) -------------------- |
|||
|
||||
source777 |
|
||||||
Эксперт Профиль Группа: Завсегдатай Сообщений: 1878 Регистрация: 12.3.2007 Репутация: 6 Всего: 56 |
Строго говоря, да. index.php - максимум тянет на FrontController, а для полной реализации MVC этого маловато. Хотя смотри, как забавно получается... MVC ты готов трактовать гибко, хотя это достаточно конкретный паттерн, хоть и с приличным кол-вом интерпретаций. А ORM, которая является лишь техникой работы с БД, ты трактуешь в очень узких рамках библиотечных реализаций.
Ну вот ты и сформулировал границы применимости ORM: использовать его для всех запросов, для которых не нужны фичи СУБД, несовместимые со стандартом ANSI SQL, которые не поддерживаются ORM из коробки. С этим я полностью согласен, но как я писал выше, нестандартных запросов, как правило, очень мало. Ты так пишешь, как будто каждый второй запрос сложный. Сложных - от силы 2-3%, остальное - это довольно банальные запросы (тут главное не путать сложные и длинные ;). Если в проекте каждый десятый или ещё больше запросов полагается на специфичные для СУБД фичи, то я склонен считать, что в дизайне БД есть серьёзные проблемы. Сложные запросы я сам пишу на SQL, но необходимость в них возникает крайне редко.
Ну тут уже вопрос определений. Лично я считаю модель, изолирующую все запросы от остального приложения, реализацией ORM. Разница только в том, будет у неё базовый класс для распространённых запросов, либо нет. -------------------- Если бы программистам платили за то, чтобы убирать код из программы вместо того, чтобы добавлять его, программы были бы намного лучше © Николас Негропонте |
||||||
|
|||||||
aktuba |
|
||||||||||||
Смышленный Профиль Группа: Завсегдатай Сообщений: 1915 Регистрация: 24.4.2006 Где: Планета Земля Репутация: нет Всего: 38 |
Эмм... А с каких пор MVC зависит от типа контроллера? Строго - как раз моя схема полностью MVC ;)
Я привел вполне конкретный пример правильного MVC, все остальное - расширение стандартной схемы. Впервые MVC была описана в 1979-м году, когда ООП не было и в природе-то ;)
ORM = Object-relational mapping, т.е. принцип отображения данных на объекты. Все верно? Т.е., берем данные в одном (плоском) формате и делаем из них объекты. При чем тут библиотечные реализации? Мне не понятна мода на постоянное конвертирования данные-объект-данные. Да это как-раз понятно. Не понятно, когда полезен ORM. Честно - не понятно. Плюсов ведь, кроме рефакторинга (да и то, ограниченного) нет, на мой взгляд. Основные запросы, чаще всего, либо составные, либо сумма простых. В первом случае ORM вреден, во втором бесполезен. Так для чего тогда? Хотя нет, для второго случая возможно будет безвреден, если запросы не критичны по скорости выполнения. Но вот засада - простые запросы делают тогда, когда нужна или скорость выполнения запросов, или распределенность данных физически (т.е., когда join не возможен). И в том, и в другом случае - ORM вреден.
Если до оптимизации - согласен. С другой стороны, те же фичи помогают ускорить работу приложения. Ну а перевод ORM на использование handle socket, например, я даже представить не могу, если честно. И да, я часто использую нормализацию данных, хотя и считаю, что это не совсем правильно. Советую почитать интервью с Олегом Буниным в хакере за июнь этого года. Там много правильного сказано как-раз про дизайн базы.
С чего вдруг? ) У меня работа идет с массивами данных (в основном), объектами и не пахнет. И да, у меня модель не знает о связях внутри базы, ее задача - получить запрос и отдать данные/выполнить действия. Это не ORM ни разу ;)
А при чем тут вообще базовый класс? o_O Вообще, меня удивили несколько моментов в этом диалоге: 1. Ты все завязываете на ООП. Даже если язык полностью ООП - остальные компоненты могут быть не ООП и пытаться их привести к ООП-виду, на мой взгляд, ошибка. Например, MVC - архитектурное решение по построению приложения. По сути, это сумма 3-х компонентов, имеющих между собой низкую связанность. При чем тут ООП? 2. Говоря ORM ты в 100% случаев имеете в виду базу данных. И это я "трактую ORM в очень узких рамках библиотечных реализаций" )). ORM - принцип представления данных в виде объектов. Нет в этом определении ни слова про базы, верно? Для пример, могу набросать ORM для curl ;) 3. Удивляет совместимость опыта и наивности. Возможно я все-таки "не дорос" до ORM. Но если мне реально будет удобно работать с объектами, а не с данными - я выберу mongodb, например. С другой стороны, если проект простой и нагрузка будет не значительной - возможно и есть смысл юзать ORM. Надо обдумать, в общем ) 4. Конечно, удивило твое терпение. Честно. -------------------- |
||||||||||||
|
|||||||||||||
source777 |
|
||||
Эксперт Профиль Группа: Завсегдатай Сообщений: 1878 Регистрация: 12.3.2007 Репутация: 6 Всего: 56 |
C MVC вообще ситуация сложная. В эту аббревиатуру входит огромное число схожих, но существенно разных паттернов. Т.е. если уж совсем строго, то примера правильного MVC в природе не существует, т.к. нет консенсусного мнения о том, что именно считать эталонным образцом MVC. MVC образца 1979-го года в веб-программировании конечно не применяется, применяются его потомки. А ООП было, Smalltalk гораздо раньше появился. Впрочем, это вообще не суть важно Ну мы как бы в подфоруме о Ruby. А в Ruby всё завязано на ООП.
В этом нет, но это определение к ORM не имеет ни малейшего отношения, оно больше похоже на одну из базовых идей ООП, чем на определение ORM. ORM - это техника работы с реляционными базами данных из объектно-ориентированной программы, заключающаяся в отображении данных из реляционной базы данных (и ничего другого, curl не катит) на объекты. А что касается Ruby, то тут и хэши, и массивы, и строки, и числа, всё есть объекты, т.е. как ты ни увиливай, а всё равно получится ORM.
Попробуй. Не всё так просто... -------------------- Если бы программистам платили за то, чтобы убирать код из программы вместо того, чтобы добавлять его, программы были бы намного лучше © Николас Негропонте |
||||
|
|||||
aktuba |
|
||||
Смышленный Профиль Группа: Завсегдатай Сообщений: 1915 Регистрация: 24.4.2006 Где: Планета Земля Репутация: нет Всего: 38 |
Это уже интересно. А что еще входит в MVC, помимо Model-View-Controller? Ну так дальше-же написано - MVC (Model-View-Controller) никак не связанно с ООП. Говорилось в этом ключе ;)
Да ладно? "Object-relational mapping (ORM, O/RM, and O/R mapping) in computer software is a programming technique for converting data between incompatible type systems in object-oriented programming languages." - это из википедии. А это уже реализация orm. То, что orm больше всего прижилось в базах данных (что не удивительно), не значит, что orm только на них и завязано. Или, по-твоему, если у меня все данные находятся в обычных файлах, но я реализовал обертку, которая превращает данные из файлов в объекты и позволяет с ними полноценно работать - уже не orm? ;)
Неа, не получится. Данные-то все-равно плоскими остаются ;) -------------------- |
||||
|
|||||
source777 |
|
||||
Эксперт Профиль Группа: Завсегдатай Сообщений: 1878 Регистрация: 12.3.2007 Репутация: 6 Всего: 56 |
Ничего. Но нет единого понимания, что должна делать каждая из этих составляющих. Например, наиболее популярная интерпретация считает что контроллеры должны быть тонкими, а модели жирными. А ты считаешь наоборот. Можно сказать, что твой подход - не MVC, а можно сказать, что это другая реализация паттерна. В зависимости от одно- или двунаправлености связей между M,V,C можно ещё выделить несколько паттернов.. и т.д. и т.п... некоторые реализации удостаиваются даже отдельных аббревиатур типа MVP, MVVM, HMVC. Но академической точки зрения в этом вопросе как не было, так и нет. Ну википедия, в данном случае, не лучший proof-link. Не хватает ссылки на автора этого определения. Да и вся последующая статья про базы данных и SQL. Судя по всему имеет место просто неудачная правка определения, изначально там было
Да, я считаю, что это не ORM. И де-факто отрасль так считает.. посмотреть хоть списки популярных ORM реализаций.. все работают с реляционными базами данных. Причём, если посмотреть к примеру на майкрософтский LINQ, то он работает с произвольными источниками данных, но в списке ORM встречается только LINQ to SQL. Почему LINQ to XML не считается реализацией ORM по мнению той же википедии, на которую ты ссылался? Ну да ладно, возможно в твоих моделях не будет связей с другими моделями, тогда действительно будет не совсем ORM, а чёрти что и с боку бантик. Но в этом случае в целом слоя предметной области как такового не будет. -------------------- Если бы программистам платили за то, чтобы убирать код из программы вместо того, чтобы добавлять его, программы были бы намного лучше © Николас Негропонте |
||||
|
|||||
aktuba |
|
||||||||||||||||
Смышленный Профиль Группа: Завсегдатай Сообщений: 1915 Регистрация: 24.4.2006 Где: Планета Земля Репутация: нет Всего: 38 |
Да какая разница, какие модели и контроллеры? MVC - это принцип построения системы и реализации вообще не при чем... И MVC имеет единственное значение: Model-View-Controller.
По мне - как-раз твое определение ошибочно. И считаю, что его правильно поправили. Данные - это не всегда база (и даже не 99%), а ORM - это обертка над данными (точнее, конвертер).
Снова ты за свое )))). Т.е., если я найду реализацию ORM над cron - смысл ORM сразу поменяется? Или ты просто скажешь, что это исключение? Популярные реализации работают над популярными решениями. Твоя фраза напоминает "популярные сайты сделаны на php - значит лучший в мире язык - php" ;). Ок, предположим (только предположим, т.к. потом разобьем миф ;)), что ты прав и orm работает только на базах. Значит схема, в которой ORM работает поверх враппера над базой - уже не ORM? А ORM в php вообще не может существовать, т.к. работает не с базой, а с драйверами, которые работают с базой... Причем, в данном случае, можно считать, что драйвер - тот же curl, который соединяется с базой и запрашивает что-то у нее, передавая команды. В чем отличие? А если база удаленная, да еще за балансером? Вывод - ORM не существует? ))))))
Если бы я знал что это такое - может и ответил бы. Но на-вскидку - причина простая. В LINQ to XML работа идет не с данными, а с оберткой, поэтому и нельзя назвать ORM. Классический пример ORM:
А вот LINQ to XML:
Как видишь - работа идет не с данными ;)
В моделях - не будет. В запросах - есть иногда ). И это точно не ORM.
О как... Мы снова возвращаемся к толстым/тонким моделям. И да, бизнес-логика у меня в контроллерах. P.S.: посмотрел список популярных ORM - улыбнулся. Есть CodeIgniter (в котором отродясь не было нормального ORM), но нету Kohana... А вообще, я согласен со следующим определением:
Этой фразе уже больше 4-х лет ;) Это сообщение отредактировал(а) aktuba - 18.6.2012, 00:57 -------------------- |
||||||||||||||||
|
|||||||||||||||||
source777 |
|
||||||
Эксперт Профиль Группа: Завсегдатай Сообщений: 1878 Регистрация: 12.3.2007 Репутация: 6 Всего: 56 |
Принципиальная Наличие 3 концептуальных сущностей - это ещё не паттерн, а то так можно докатиться до признания набора чашка+блюдце+ложка системой, построенной по паттерну MVC. Самое важное какие роли эти сущности выполняют и как друг с другом комуницируют. Меняешь роль хотя бы одной сущности - получаешь принципиально другой паттерн.
Ну так это ты считаешь, что написанное в википедии неоспоримо. На мой взгляд, то же определение ORM, которое там есть в данный момент, - это бред. А список ORM, местами усугубляя бредовость, доказывает несогласованность определения с остальной информацией в википедии на эту тему.
Не значит. База - это источник данных, способ их получения не имеет никакого значения. Да нет, работа идёт с данными, но с иерархическими(что лишь обуславливает небольшие синтаксические особенности), а не с реляционными. Т.е. логика тут проста до безобразия - раз работа идёт не с реляционной моделью данных, то это по определению не ORM. Теоретически можно построить реляционную модель данных на чём угодно, хоть на ini-файлах, но это не более, чем извращение, поэтому и непонятно почему ты так ратуешь за признание извращений достойной заменой реляционных СУБД.
Ну с этим утверждением я тоже согласен. В нём достаточно ясно указано, что реляционная модель данных - это такая же необходимая часть любого ORM, как и объектная модель. Ну а о том, что в теории РМД бывает не только в СУБД я написал выше, но это только в теории. Когда напишешь или найдёшь production-ready хранилище, поддерживающее РМД, но не являющееся СУБД, кинь ссылку мне в PM. Подивлюсь на это чудо в перьях. На радостях, что мы нашли хотя бы одно утверждение на тему ORM, с которым оба согласны, закрываю нашу флудильню, как окончательно отошедшую от общих вопросов по Ruby. Это сообщение отредактировал(а) source777 - 19.6.2012, 12:01 -------------------- Если бы программистам платили за то, чтобы убирать код из программы вместо того, чтобы добавлять его, программы были бы намного лучше © Николас Негропонте |
||||||
|
|||||||
Правила форума "Ruby: Общие вопросы" | |
|
Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, source777. |
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
0 Пользователей: | |
« Предыдущая тема | Ruby: Общие вопросы | Следующая тема » |
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |