Тогда вы неправильно назвали/начали пост. Если бы написали что-то вроде «предлагаю способ как интуитивно понимать поля, в частности гравитационное», тогда придраться можно было бы только к тому зачем вы вообще описываете своё представление. Но вы вполне чётко написали «построим свою теорию единого поля».
Предлагаете теорию — будьте добры приложить кило формул
Можно придумать десяток аналогий, которые как-то более интутитивно-понятно будут объяснять различные физические явления (ту же гравитацию), однако чтобы иметь хоть какой-то шанс на существование, такая аналогия должна в нормальных условиях сводиться к ньютоновской механике. Не умозрительно, а по формулам. Следующий шаг — объяснение релятивистских эффектов, таких как прецессия орбиты меркурия. Если и эта вершина покорена, но то грех не попытаться объяснить ускоренное вращение галактик и расширение вселенной.
Вообще, сейчас есть бесчисленное множество явлений, который уже объяснены существующей теорией. Предлагать какое-то иное видение мира, не показав что, путь не все, но основные явления вписываются в это видение, просто смешно.
Он пришёл в веб-программирование из настольных приложений и доказал свою эффективность в новой сфере применения.
В этом предложении есть неоднозначность, т.к. веб-программирование — очень широкое понятие. Веб-программированием можно назвать как создание backend, так и создание frontend. При этом MVC для backend действительно проявил себя в новой сфере, если конечно то что используется на стороне сервера можно назвать MVC. Программирование же пользовательского интерфейса на стороне клиента не стало новой сферой применения для архитектурного подхода с названием MVC, т.к. SPA по сути являются теми же desktop приложениями, просто запускаются в runtime в виде браузера.
Модель в этом шаблоне проектирования занята исключительно работой с JSON или объектами, которые поступают с сервера.
А вот это уже антипаттерн. Модель это больше чем просто объектная обёртка к данным. Это ещё и управление состоянием приложения, а оно, отнюдь, не сосредоточено на данных. Например, отображаемая в данный момент вкладка (tab), а точнее информация о том какая вкладка должна быть показана — тоже часть состояния приложения. А концентрация на работе с данными ведёт к тому, что работа с состоянием размазывается по контроллеру.
Контроллер должен играть роль посредника, не заботясь о деталях реализации других компонентов.
О деталях реализации вообще никто заботиться не должен. Но в контексте разделения ответственности между Моделью, Представлением и Контроллером ваше заявление в корне неверно и противоречит вашему же примеру. Как раз наоборот — именно контроллер «знает» за какие ниточки дёргать модель, а за какие представление.
Согласен. Но тогда получается, что люди выбирают не столько ORM, сколько хорошо притёртый набор библиотек в составе ORM. Что же тогда отличает ORM от набора библиотек?
Я не говорю что через ORM нельзя выполнять миграции. Кроме того я не говорю что надо писать механизм миграций с нуля. Но возможность выполнять миграции это не то что нам даёт ORM.
Это не тот плюс ORM ради которого стоит выбрать ORM вместо библиотеки, которая заточена только под миграции.
ORM, а точнее популярные ORM-библиотеки всё же делают упор на работу с графами объектов данных и соответственно на генерацию DML запросов.
Генерация же DDL запросов, как и их применение к базе это задача механизма миграций.
Это заслуга не столько ORM, сколько того, что вы заранее ввели абстракцию в виде интерфейса.
Того же эффекта можно было добиться и без ORM, главное тут — чтобы клиентский код обращался строго к интерфейсу и не знал подробности того как этот интерфейс работает внутри.
Вы путаете набор библиотек для работы с БД и коллекциями, и ORM, основной задачей которого является поддержание консистентного состояния объектов в памяти приложения в соответствии с данными в БД.
Этим я хочу сказать, что ни работа с коллекциями, ни удобное подключение к базе, ни сахар при работе с БД не являются киллер-фичами ORM. Да, они есть в ORM, но также их можно заполучить просто используя отдельные библиотеки.
Так что же полезного в самом ORM?
По поводу документации. Так или иначе, сущности и логику работы приложения как-то описать надо, не важно, используете ли вы ORM или пишете запросы руками. Слой абстракции не подразумевает создание собственного сложного фреймворка для доступа к данным, достаточно писать запросы не в самом объекте предметной области, а в отдельном классе, названия методов которого вполне самодокументируемы по названию. Что может быть непонятного в методе findNewsByTitle(title) внутри которого одной-двумя строчками делается запрос и отдаётся массив объектов? Для этого не требуется обширной документации.
Ну и напоследок про sql через ORM.
Всё-таки ORM сам по себе является слоем абстракции. Работа с базой должна быть скрыта в этом слое. А когда мы пишем sql через ORM — мы вытаскиваем работу с базой наружу.
Когда вы используете ORM и пишете SQL код в сложных случаях, вы теряете независимость от конкретной СУБД, т.е. один из «плюсов» использования ORM.
В случаях, когда вам необходимо абстрагироваться от СУБД, вам придётся вводить слой абстркации. Да и без такой необходимости, выделение работы с базой делает код чище.
«Фишки ORM» совсем не фишкки ORM:
indexBy — работа с коллекциями
подключение к базе — фишка драйвера, такого как PDO, ну или библиотеки, облегчающей работу с базой
параметры запроса — аналогично
то есть нужно писать документацию
Да ладно? Вы считаете что это оверхед? А ничего что документация должна быть в любом случае?
Вложенные циклы устраняются не использованием ORM, а использованием объектов для выстраивания структуры обрабатываемых данных.
Не думать как там называется таблица можно введя дополнительный слой абстракции над слоем, который выполняет запросы к базе. Более того, выделение слоя, который выполняет запросы к базе, позволяет таки… выполнять запросы к базе. Т.е. ты пишешь sql запрос, и тебя совесть не мучает за то что ты делаешь хак в обход ORM.
Мне кажется, лучше руками писать простые запросы и иметь возможность так же быстро написать сложный, чем экономить время на простых запросах и безбожно тратить его на сложных.
Миграции к ORM отношения не имеют. Механизм миграций может быть реализован в рамках ORM, как и построитель запросов (для сахара, да и для защиты от дурака), но это не значит, что они не могут жить отдельно от него.
ORM позволяет абстрагироваться от конкретной базы, но не от хранилища данных в целом. Вот только совместимые различия баз, вероятнее всего можно сгладить просто используя QueryBuilder, который будет переводить унифицированные запросы в специфичные.
По поводу маппинга на объекты, а точнее управления их состоянием, может быть, вот только польза от этого видна лишь в stateful приложениях. На PHP, где 90% эндпоинтов либо только читают из базы, либо только пишут в неё, держать пул объектов и следить за их идентичностью (IdentityMap) бесполезно.
Конечно, бывают случаи повторного чтения/записи, сам с таким сталкивался. Но бывает это редко, и наверное оно не стоит того чтобы постоянно иметь немалый оверхед от ORM.
Да, ORM предлагают красивое решение для простых случаев. Но как только начинается что-то посложнее, начинается борьба с ORM, когда ты понимаешь как можно написать запрос на sql, но ORM заставляет тебя совать друг в друга лямбды, которые строят куски запросов с помощью того-же QueryBuilder'a.
А вот интересно, какие вообще плюсы от использования ORM?
Абстрагирование от конкретной БД в них так себе, да и кому оно надо? Т.е. я понимаю, что это мифическая возможность без головной боли менять СУБД как перчатки. Но это работает только когда приложение не использует специфику СУБД.
Маппинг строк таблицы на объекты? Ну тоже не оч. Зачастую бизнес-сущность хранится сразу в нескольких таблицах, и вместо того чтобы оперировать одним объектом, который мы вручную написали как нам надо, мы жуём кактус, состоящий из типовых объектов-строк.
Возможность не знать SQL? да ладно? Его надо знать в любом случае.
Процедурный подход не выдерживает конкуренции с функциональным и объектно-ориентированным, разве что в случаях где важна производительность (я про программы написанные на си).
И вы немного не правы. не «Классы-процедуры», а объекты, которые ни в коем случае не процедуры, т.к. объекты можно динамически связывать, в отличие от процедур.
Вообще то классы, да и вообще ООП было придумано как ещё один способ структурирования кода.
Не совсем. Парадигмы программирования, такие как ФП и ООП придуманы для работы с кодом на более высоком уровне абстракции. А для структурирования придумали современные управляющие конструкции (if,while,for..) и модульность.
Имеет ли смысл делать папку всего с одним вложенным листочком?
Имеет. Объект в ООП, как и функция в ФП, это способ динамического связывания кода.
Предлагаете теорию — будьте добры приложить кило формул
Вообще, сейчас есть бесчисленное множество явлений, который уже объяснены существующей теорией. Предлагать какое-то иное видение мира, не показав что, путь не все, но основные явления вписываются в это видение, просто смешно.
В этом предложении есть неоднозначность, т.к. веб-программирование — очень широкое понятие. Веб-программированием можно назвать как создание backend, так и создание frontend. При этом MVC для backend действительно проявил себя в новой сфере, если конечно то что используется на стороне сервера можно назвать MVC. Программирование же пользовательского интерфейса на стороне клиента не стало новой сферой применения для архитектурного подхода с названием MVC, т.к. SPA по сути являются теми же desktop приложениями, просто запускаются в runtime в виде браузера.
А вот это уже антипаттерн. Модель это больше чем просто объектная обёртка к данным. Это ещё и управление состоянием приложения, а оно, отнюдь, не сосредоточено на данных. Например, отображаемая в данный момент вкладка (tab), а точнее информация о том какая вкладка должна быть показана — тоже часть состояния приложения. А концентрация на работе с данными ведёт к тому, что работа с состоянием размазывается по контроллеру.
О деталях реализации вообще никто заботиться не должен. Но в контексте разделения ответственности между Моделью, Представлением и Контроллером ваше заявление в корне неверно и противоречит вашему же примеру. Как раз наоборот — именно контроллер «знает» за какие ниточки дёргать модель, а за какие представление.
Это не тот плюс ORM ради которого стоит выбрать ORM вместо библиотеки, которая заточена только под миграции.
Генерация же DDL запросов, как и их применение к базе это задача механизма миграций.
Того же эффекта можно было добиться и без ORM, главное тут — чтобы клиентский код обращался строго к интерфейсу и не знал подробности того как этот интерфейс работает внутри.
Этим я хочу сказать, что ни работа с коллекциями, ни удобное подключение к базе, ни сахар при работе с БД не являются киллер-фичами ORM. Да, они есть в ORM, но также их можно заполучить просто используя отдельные библиотеки.
Так что же полезного в самом ORM?
По поводу документации. Так или иначе, сущности и логику работы приложения как-то описать надо, не важно, используете ли вы ORM или пишете запросы руками. Слой абстракции не подразумевает создание собственного сложного фреймворка для доступа к данным, достаточно писать запросы не в самом объекте предметной области, а в отдельном классе, названия методов которого вполне самодокументируемы по названию. Что может быть непонятного в методе findNewsByTitle(title) внутри которого одной-двумя строчками делается запрос и отдаётся массив объектов? Для этого не требуется обширной документации.
Ну и напоследок про sql через ORM.
Всё-таки ORM сам по себе является слоем абстракции. Работа с базой должна быть скрыта в этом слое. А когда мы пишем sql через ORM — мы вытаскиваем работу с базой наружу.
В случаях, когда вам необходимо абстрагироваться от СУБД, вам придётся вводить слой абстркации. Да и без такой необходимости, выделение работы с базой делает код чище.
«Фишки ORM» совсем не фишкки ORM:
Да ладно? Вы считаете что это оверхед? А ничего что документация должна быть в любом случае?
Не думать как там называется таблица можно введя дополнительный слой абстракции над слоем, который выполняет запросы к базе. Более того, выделение слоя, который выполняет запросы к базе, позволяет таки… выполнять запросы к базе. Т.е. ты пишешь sql запрос, и тебя совесть не мучает за то что ты делаешь хак в обход ORM.
Мне кажется, лучше руками писать простые запросы и иметь возможность так же быстро написать сложный, чем экономить время на простых запросах и безбожно тратить его на сложных.
По поводу маппинга на объекты, а точнее управления их состоянием, может быть, вот только польза от этого видна лишь в stateful приложениях. На PHP, где 90% эндпоинтов либо только читают из базы, либо только пишут в неё, держать пул объектов и следить за их идентичностью (IdentityMap) бесполезно.
Конечно, бывают случаи повторного чтения/записи, сам с таким сталкивался. Но бывает это редко, и наверное оно не стоит того чтобы постоянно иметь немалый оверхед от ORM.
Да, ORM предлагают красивое решение для простых случаев. Но как только начинается что-то посложнее, начинается борьба с ORM, когда ты понимаешь как можно написать запрос на sql, но ORM заставляет тебя совать друг в друга лямбды, которые строят куски запросов с помощью того-же QueryBuilder'a.
Абстрагирование от конкретной БД в них так себе, да и кому оно надо? Т.е. я понимаю, что это мифическая возможность без головной боли менять СУБД как перчатки. Но это работает только когда приложение не использует специфику СУБД.
Маппинг строк таблицы на объекты? Ну тоже не оч. Зачастую бизнес-сущность хранится сразу в нескольких таблицах, и вместо того чтобы оперировать одним объектом, который мы вручную написали как нам надо, мы жуём кактус, состоящий из типовых объектов-строк.
Возможность не знать SQL? да ладно? Его надо знать в любом случае.
И вы немного не правы. не «Классы-процедуры», а объекты, которые ни в коем случае не процедуры, т.к. объекты можно динамически связывать, в отличие от процедур.
Не совсем. Парадигмы программирования, такие как ФП и ООП придуманы для работы с кодом на более высоком уровне абстракции. А для структурирования придумали современные управляющие конструкции (if,while,for..) и модульность.
Имеет. Объект в ООП, как и функция в ФП, это способ динамического связывания кода.