Ну это понятно, можно вообще без синатры обойтись и сделать такой-же роут, верно? Я-то говорю про другое - про простоту использования, удобство написания роутов и пр.



Согласен. Но пока все-равно не возникло желание юзать рельсы ).



Путаешь с CakePHP, похоже. Kohana ни капли на руби не похожа ;)



Имел в виду генераторы padrino. Datamapper, sequel и пр. он-же поддерживает. ;)



Не поверишь - документация. Я, например, не нашел описания структуры приложения. Подскажешь где посмотреть?



С каких пор попытка превратить реляционную базу в объектную - best practices? Если я работаю с реляционной базой, мне проще написать нормальный, более-менее оптимизированный запрос, а не использовать кучу оберток над базой только для того, чтобы написать тот же запрос, но использую сторонний синтаксис. Я многих просил показать преимущества orm, например. Особенно, если база денормализована. Поможешь понять? )

Ну в плане удобства нет особой разницы с примером, который ты привёл из 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, разработку и отладку которого под конкретный проект должен будет оплатить заказчик.

Ну теперь я хотя-бы знаю, почему говорят руби - подразумевают рельсы ))


Это 2-я версия такая была. 3-ка совсем другая, значительно приятнее и удобнее.


Ну вот видишь, теперь и ты заставляешь генератором пользоваться ))). А я не хочу. Серьезно.


Спорное утверждение, на мой скромный взгляд.


В том-то и суть, что данные - это не программа. И совсем не факт, что данные в виде объектов могут быть, в каких-то случаях, удобнее плоских данных. Да и вообще, это полностью проблема модели, в каком виде возвращать данные, т.к. сами данные могут быть где угодно, помимо локального хранения. Вплоть до генерации этих самых данных. Мне вот намного удобнее работать с данными как с массивом, т.е. в плоском виде.


Ну я не говорил про запросы в контроллерах и, тем более, во вьюхах ). Я говорил про то, что переводить данные из одного типа в другой только для того, чтобы прочитать их - не лучший подход.


Тоже не факт. Пример - pdo в php. Сам по себе исключает большинство возможных проблем, не создавая дополнительных сущностей и оверхеда. Кроме того, обертки бывают разные. ORM - это не обертка, это именно конвертер методов в запрос и результатов в объекты. И оверхед делает совсем не слабый, по моему опыту.

Ну это только в части веб-разработки. По сути Rails - основной веб-фреймворк. Остальные стараются продвинуть другие идеологии, поэтому взять веб-фреймворк на Ruby, но не Rails, и пытаться работать на нём как в Rails - выглядит странно.


Так я думал, что ты изначально говорил про генераторы контроллеров, моделей, тестов и т.д., а создание приложения - это уже даже не ассоциируется с генератором, хотя формально им является. Зачем этого избегать? 
Ведь в том же Kohana ты делаешь тоже самое, только BDSM способом: зайти на сайт, скачать, распаковать, начать работу в директории application. В данном же случае генератор просто сразу создаёт аналог директории application.


Проблема модели - в каком виде получать данные, а возвращать надо придерживаясь принятого в проекте API модели. Для MVC-проектов - это в 99% проектов будет объект.
Можно, конечно, уходить в андеграунд и плевать на общепринятые концепции, но это для случая когда программирование выступает в роли способа самовыражения или хобби, если же программирование выступает в роли ремесла, то плыть против течения - тупо не выгодно.


Ну ты мне не оставил других вариантов... Ведь если ты получаешь данные в модели, то ты либо используешь ORM... либо не используешь ООП, что для Ruby нонсенс. 


Преждевременная оптимизация - корень всех зол. Ну сэкономишь ты пару мс в среднем на страницу, а кода в моделях будет в разы больше, причём большая часть будет в строковом представлении. Ничего хорошего тут нет. Особенно если ты работаешь не в гордом одиночестве.
Я сам иногда использую SQL-запросы, но только когда это оправдано. Обычно получается не более 1 raw-SQL запроса на 1000 LOC проекта.

Ну так я не хочу как в rails, хочу так, как мне удобно. Пусть и похоже, но это разные вещи.


По нескольким причинам. Начиная с того, что я недолюбливаю *nix (но и без него никуда, к сожалению) и заканчивая тем, что генератор делает что-то помимо меня, заставляет лезть в консоль и пр. Не поверишь, скорее всего, но до руби у меня никогда не было необходимости лезть в консоль. Хотя опыт работы в вебе достаточно большой.


Верно. Но делается это с помощью браузера и ftp-клиента. Все! И это правильно, на мой взгляд...


Не-не-не... Взаимосвязь контроллер-модель - отдельный вопрос. Я сторонник тонких моделей. А вот возвращать надо исходя из api приложения, а не платформы. Где-то, объектная модель будет только на пользу, а где-то только во вред. Второй случай - большие объемы данных, зависимость от скорости обработки и т.п.


А вот это уже заблуждение. Точнее - привычки разработчиков. Но это судя по моему опыту, который у каждого свой...


Выгодно - когда удобно, а не модно, верно? Простой пример - на работе делаем довольно крупные и нагруженные проекты на php. Так вот в коде нет НИ ОДНОГО ОБЪЕКТА. Вообще. Только статичные классы. И я тоже плевался, когда впервые увидел. Но проанализировав плюсы и минусы могу смело сказать, что это оправдано и удобно (хотя и не везде в проекте). Так и тут - я не вижу никаких плюсов в orm, не вижу удобств - так зачем оно мне?


Стоп-стоп-стоп! С чего бы это получение данных в модели сразу становится завязанным на orm? o_O Не понимаю данной логики. Еще раз - данные и организация кода - это совсем разные вещи. И как не извращайся (при использовании mysql, например) - данные всегда будут в плоском виде. А код - ООП. Что не так?


Аааабсолютно верно! Но ты же не пишешь сначала плохой код, а потом переписываешь на нормальный? Так и тут - если известны проблемы, то они обходятся сразу и сложно это считать оптимизацией. Простой пример из мира php: если в for использовать count - цикл выполняется, примерно, на 50% дольше. Зная это, вряд ли будешь использовать count в for, верно? Разве-ж это оптимизация? )


А вот это как-раз зло. Экономия пары мс ничего не значит, но экономия сотен мс на страницу значит очень много. И еще раз повторю - кода в модели у меня будет довольно мало (в основном, сами запросы), а вот в контроллерах будет достаточно.


Значит ты сможешь дать внятные примеры, когда это НЕ оправдано? Правда, ведь? )

Еще вопрос, если можно. Что в данном коде не так?


Это сообщение отредактировал(а) aktuba - 8.6.2012, 01:14

Ну т.е. другими словами тебя просто поработила привычка работать мышкой. В таком случае ты можешь поставить 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 есть хэши.

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

Так я этого и не писал.. Я писал про 99% MVC-проектов. А MVC - это ООП паттерн.


Сами запросы при этом изменились по сравнению с теми, которые генерировал ORM? 
Если да, то проблема была не в ORM, а в кривых руках программистов, его применявших. Если нет, то никаких ускорений в разы быть не может.


Мои слова проверены личным опытом и профайлером.    


Тяжёлый случай   
Ты даже наличие модели предметной области считаешь минусом. Хотя MVC по определению подразумевает, что никто кроме модели не знает откуда и какие данные она получает.


Требования меняются всегда. Это аксиома любого проекта с внешним заказчиком. Если дизайн затрудняет внесение изменений, то он плох.



Ну это конечно зависит от реализации ORM, но в целом неправда. Как я уже писал выше, случаи когда сложно написать оптимальный запрос с помощью ORM очень редки. И в этих случаях как раз оправдано применение raw SQL.


1. Структуру БД тоже рефакторить надо периодически. А то ты своими примерами сейчас выдашь ещё и хреновый дизайн БД. ;)
2. Зависит от конкретной ситуации, от представления в СУБД до plain-SQL запроса в модели. Использовать ORM в 100% запросов также глупо как не использовать ORM совсем.


Ну я не видел ещё ни одного проф. разработчика не пользующегося абстракциями, а вот новичков видел сотни. Так что всё наоборот. Необходимость изоляции деталей реализации приходит с опытом.


Ну зачем дурачка то включать? Не смешивать sql и код, работающий с моделью. 

P.S. Пора закруглять оффтопик, каждый кулик волен оставаться в своём болоте. Я лишь хотел направить на Ruby-way, т.к. с твоими убеждениями успешно программировать на Ruby вряд ли получится. Это для тебя будет, что называется, роль на сопротивление.

Ну раз заканчиваем, тогда коротко:


С чего-бы? index.php © + data.php (M) + view.php (V) - уже не MVC? Какая разница, что и как у них внутри, если MVC - это паттерн организации проекта, а не кода?


Конечно менялись, ради этого и отказались от orm. И нет, дело не в кривых руках программистов, а в кривых руках разработчиков ORM, который не позволял использовать фичи базы, использую только основной функционал. Почти во всех реализациях ORM дело обстоит так же.


На простых запросах? )


Не-не-не, не правда )). У меня запросы в модели, полностью огорожены от приложения. И только модель знает про данные. Сама модель - плюс, а ORM (пока еще) - минус.


Возможно поэтому мне и не понятно требование юзать orm. Я очень редко работаю на внешнего заказчика и еще реже меняются требования к проекту. Хотя нет, даже при таких аксиомах - orm лишний блок в приложении.


Вот как-раз на моей практике все иначе. Проф.разработчики почти не пользуются orm (только когда достается код других людей). А новички, увидев верхушку айсберга, начинают использовать везде. И да, это приходит с опытом )))


Возможно. Но раз можно пользоваться plain-sql в ruby - все не так уж и плохо ;)

Строго говоря, да. index.php - максимум тянет на FrontController, а для полной реализации MVC этого маловато.
Хотя смотри, как забавно получается... MVC ты готов трактовать гибко, хотя это достаточно конкретный паттерн, хоть и с приличным кол-вом интерпретаций. А ORM, которая является лишь техникой работы с БД, ты трактуешь в очень узких рамках библиотечных реализаций.


Ну вот ты и сформулировал границы применимости ORM: использовать его для всех запросов, для которых не нужны фичи СУБД, несовместимые со стандартом ANSI SQL, которые не поддерживаются ORM из коробки. С этим я полностью согласен, но как я писал выше, нестандартных запросов, как правило, очень мало. 


Ты так пишешь, как будто каждый второй запрос сложный. Сложных - от силы 2-3%, остальное - это довольно банальные запросы (тут главное не путать сложные и длинные ;). Если в проекте каждый десятый или ещё больше запросов полагается на специфичные для СУБД фичи, то я склонен считать, что в дизайне БД есть серьёзные проблемы. Сложные запросы я сам пишу на SQL, но необходимость в них возникает крайне редко.


Ну тут уже вопрос определений. Лично я считаю модель, изолирующую все запросы от остального приложения, реализацией ORM. Разница только в том, будет у неё базовый класс для распространённых запросов, либо нет.

Эмм... А с каких пор 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. Конечно, удивило твое терпение. Честно.

C MVC вообще ситуация сложная. В эту аббревиатуру входит огромное число схожих, но существенно разных паттернов. Т.е. если уж совсем строго, то примера правильного MVC в природе не существует, т.к. нет консенсусного мнения о том, что именно считать эталонным образцом MVC. 
MVC образца 1979-го года в веб-программировании конечно не применяется, применяются его потомки. А ООП было, Smalltalk гораздо раньше появился. Впрочем, это вообще не суть важно   


Ну мы как бы в подфоруме о Ruby. А в Ruby всё завязано на ООП.


В этом нет, но это определение к ORM не имеет ни малейшего отношения, оно больше похоже на одну из базовых идей ООП, чем на определение ORM. 
ORM - это техника работы с реляционными базами данных из объектно-ориентированной программы, заключающаяся в отображении данных из реляционной базы данных (и ничего другого, curl не катит) на объекты. А что касается Ruby, то тут и хэши, и массивы, и строки, и числа, всё есть объекты, т.е. как ты ни увиливай, а всё равно получится ORM.   


Попробуй. Не всё так просто...

Это уже интересно. А что еще входит в 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? ;)


Неа, не получится. Данные-то все-равно плоскими остаются ;)

Ничего. Но нет единого понимания, что должна делать каждая из этих составляющих. Например, наиболее популярная интерпретация считает что контроллеры должны быть тонкими, а модели жирными. А ты считаешь наоборот. Можно сказать, что твой подход - не MVC, а можно сказать, что это другая реализация паттерна. В зависимости от одно- или двунаправлености связей между M,V,C можно ещё выделить несколько паттернов.. и т.д. и т.п... некоторые реализации удостаиваются даже отдельных аббревиатур типа MVP, MVVM, HMVC. Но академической точки зрения в этом вопросе как не было, так и нет.



Ну википедия, в данном случае, не лучший proof-link. Не хватает ссылки на автора этого определения.
Да и вся последующая статья про базы данных и SQL. Судя по всему имеет место просто неудачная правка определения, изначально там было 




Да, я считаю, что это не ORM. И де-факто отрасль так считает.. посмотреть хоть списки популярных ORM реализаций.. все работают с реляционными базами данных.
Причём, если посмотреть к примеру на майкрософтский LINQ, то он работает с произвольными источниками данных, но в списке ORM встречается только LINQ to SQL.
Почему LINQ to XML не считается реализацией ORM по мнению той же википедии, на которую ты ссылался?


Ну да ладно, возможно в твоих моделях не будет связей с другими моделями, тогда действительно будет не совсем ORM, а чёрти что и с боку бантик.  Но в этом случае в целом слоя предметной области как такового не будет.