Обсуждаем ORM

[Кувалдыч ТС]

Ты её прочитал?

Зачем? Это ж реклама книги несостоявшегося программера

то, что ORM отбрасывает разработчиков назад.

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

А что используют во фронтенде для доступа к БД?

Н И Ч Е Г О.
Ибо фронтенд не может иметь доступа к БД в пряморукой архитектуре.
Он иеет доступ только к уровню сервисов. Обычно через JSON или XML представляющим из себя сериализованые DTO (дейта траснфер обжект, объект обмена данными) модели, либо отрендеренные страницы на сервере опять же с использованием DTO моделей..
Сервисы реализуют интерфейсы с клиентами и нвнешними приложениями, обращаются к уроню бизнес-логики для выполнения описываемых сервисами операций.  Они посредники которые изолируют приложение от клиентов.
Бизнес-логика к уровню данных. Вот тут и живет ORM. Посредством ORM бизнес-логика общается с уровнем данных.

[Paramedic]

Зачем? Это ж реклама книги несостоявшегося программера

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

Ярлыки поклеили, на личности автора книги перешли. А по существу? С какими положениями статьи не согласен? Почему?

Для тех, кто не в теме, напомню ссылку: http://habrahabr.ru/company/piter/blog/165327/

Обычно через JSON или XML представляющим из себя сериализованые DTO

Откуда приложение будет получать этот JSON или XML?

[Кувалдыч ТС]

Откуда приложение будет получать этот JSON или XML?

Он иеет доступ только к уровню сервисов.

DTO формируется как результат взаимодействия клиента с приложением на уровне сервисов.

[Кувалдыч ТС]

Почему?

потому что я не читаю авторов имеющих перлы типа этого:

Недостаток знаний РСУБД пытаются заместить дополнительными уровнями абстракций.

Когда человек путает красное с кислым - нет никакого смысла его читать.

[Paramedic]

DTO формируется как результат взаимодействия клиента с приложением на уровне сервисов.

Т.е. если я пишу движок форума, то кто-то должен написать и запустить сторонний сервис? Я правильно понимаю?

И это называется упростить и ускорить разработку?

Когда человек путает красное с кислым - нет никакого смысла его читать.

Кхм. А что не так во фразе: "Недостаток знаний РСУБД пытаются заместить дополнительными уровнями абстракций"? Я вот вижу на форумах вопросы задают: что лучше изучать: ORM или SQL.

[Кувалдыч ТС]

Я правильно понимаю?

Кому что делать это вообще вопрос к руководителю проектов и графику проекта, а не к программистам или архитекторам.

И это называется

Распаралеливание задач проекта.

А что не так во фразе:

Это ж очевидно.
Абстракциями занимается архитектор, кторый не обязан знать РСУБД.
А РСУБД занимается программер и админ, кторые не обязаны разбираться в абстракциях.
Поэтому недосток одних знаний не возможно заменить другими знанями, просто работу нужно поручать правильному специалисту и все. Это вопрос руководителя проектов. А не технологий.
Автор такой фразы просто бульварный писака, кторый об айти слышал видимо только по телевизору и понятия не имеет о том что пишет.

что лучше изучать: ORM или SQL.

А что лучше изучать - кулинарию или как готовить яичницу?

[Кувалдыч ТС]

напомню ссылку: http://habrahabr.ru/company/piter/blog/165327/

там по ссылке ничего интересного нет, даже про автора или книгу не понятно, хоть и ее анонс.
Отрывок книги есть тут: http://www.ozon.ru/context/detail/id/28328516/
Намного больше по размерам, про атора опять ничего...  зато с десяток страниц околохудожественного произведения, бесполезного с технической точки зрения, но как жвачка на ночь сойдет, но лучше поспать чем это читать - пользы больше будет.

З.Ы. непрограммерам и любителям начной фоантастики - рекомендую. Про всякие аббревиатуры там мало что, больше похоже на фантастическое околонаучное произведение о жизни программеров и айтииндустрии, кто такие гуру и кто лохи, как менялись различные взгляды в айти и тп. В общем живо, художественно описано. Для тех кто не связан с айти, атишникам выглядит так же убого как в кино взлом паролей операцией ping или его подбора с угадыванием побуквенно

[Кувалдыч ТС]

Кому интересно, как оно в айти все делается, пример разработки продукта можно обрисовать на примере:

Т.е. если я пишу движок форума, то кто-то должен написать и запустить сторонний сервис?

Как продукт делается с нуля, кто когда за что твечает и чем занимается и т.п. Но это все долго описывать, особенно с нюансами и подробностями. Тем более что в айти как методики создания проуктов, управления проектами, так и технологий - просто туча. Здесь нет как в кулинарии или заводе четкого и выверенного подхода. Даже просто чтобы начать аткой проект существует множиство научных и околонаучных (научно-практических) техник и практик. Не говоря уже о инструментарии. И это мы еще близко не подошли даже к кодингу.


Единственная достоверно известная и неоспоримая вещь в айти, это то, что в айти все является открытыми системами, "машинами состояний" состояние которых конечное множество, и состояния могут изменяться под действием внутренных и внешных факторов, при этом эти факторы являются неограниченным множеством.

Поэтому в айти все сводится к разработке таких систем, т.е. понять где и как будет существовать система, кем и как использоваться, с кем взаимодействовать, какие состояния может имкть, какие в ней живуь сущности и как они помгут взаиодействовать друг с другом и с внешними раздражителями.

Поэтому лоюбой продукт начинается с заказичка и его"Хочу такую вот хрень." Как известно, проект - это ограничеанная по времени и ресурсам деятельность. Соотвесвенно ка ктолько к "Хочу" заказчик добвит "Через месяц" и "за 1000р", образуется и проект. В который назначается отвественный за все происходящее инепроисходящее лицо - руководитель проекта. Это такое лицо которое виновато во всем когда "Хочу Через. За" не совпало с ожидаемым. А он не совпадет, так как что в теории что в практике, из трех составляющих прокта выполнить можно только два любых условия, при этом за счет третьего.

Руководитель проекта умеет управлять временем, ресурсами и рисками. Делать "такую хрень" он не обязан уметь, а так же знать как это ыглядит и счем ее едят, к тому же заказчик сам ен знает что это. Руководитель проекта просто должен передать ее закзчику не позже установленного срока и затратив не более чем выделено ресурсов.

Поэтому начинается второй этап проекта. Руководитель берет архитектора и идет к заказчику. Кстати, мимо руководителя проектов никто не обшается. По причине того, что ему за все отвечать. Работа архитектора заключается втом, чтобы превратить "хрень" из одног слова в набор предложений - "требований". Исходя из изучения предметной области заказчика, архитектор строит "модель" системы. По сути она отражает ту деятельность с теми сущностями для которых разрабатывается продукт.

Т.е.... и далее...

Фух... как все сложно рассказывать то... даже поверхностно

[Paramedic]

Фух... как все сложно рассказывать то... даже поверхностно

Так я тебе уже предлагал, куда проще. Рассмотреть движок форума. Давай рассматривать. Что, кроме геморроя и тормозов может привнести в разработку ORM?

[Paramedic]

Да, и причём здесь ORM? В течении твоего повествования ORM не было упомянуто ни разу. И что мешает использовать в описываемой тобой технологии SQL подход?

[Кувалдыч ТС]

кроме геморроя

Какого?

и тормозов

Каких?
Тут что, так часто меняются сущности? Они вообще почти не меняются. Так что тормозов на уровне данных просто быть не может.

может привнести в разработку ORM?

Форум слишком примитивная система чтобы использовать ORM.
Предметная область форумов практически неизменна.

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

[Paramedic]

Для тех кто не связан с айти, атишникам выглядит так же убого как в кино взлом паролей операцией ping или его подбора с угадыванием побуквенно

Нормально выглядит. Ты общался с ORMщиками? Они используют давно забытый навигационный подход, тот самый, который использовался в Клиппере. Они генерят неоптимильный код. И их самый любимый вопрос на форумах: как переложить SQL запрос на ORM.

Патамушта нынешний недопрограммер думает, что вот он сейчас модельки опишет, ORM создаст для него БД, а он будет с объектами работать, извлекать из базы, и класть их в базу.

[Кувалдыч ТС]

В течении твоего повествования ORM не было упомянуто ни разу.

Так ы еще не дошли... ты ж сам ушел далеко от ОРМ спросив кто должен делать уровень сервиса.

И что мешает использовать в описываемой тобой технологии SQL подход?

Я еще не описывал технологию программирования. Даже близко не дошел.

Не мешает никто. Это вопрос лишь архитектурного подхода.


Смысла ORM на форуме нет никакого ибо:
1. предметная область практически не изменна
2. источник данных единственный и определяется самим разработчиком.

[Кувалдыч ТС]

ORMщиками?

Есть такая специальность???

их самый любимый вопрос на форумах: как переложить SQL запрос на ORM.

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

ORM создаст для него БД, а он будет с объектами работать, извлекать из базы, и класть их в базу.

Да, это задача ОРМ, для этого он и используется.

недопрограммер думает

Так поручите программеру. Кторый сумеет правильно запрограммить ORM а не просто взять у архитектора описание структур и закодить их на выбранном языке программирования.

[Paramedic]

Какого?

Да самого обычного. Вот простейший пример, когда ORMщики вместо работы ищут ответы на свои вопросы:

https://forum.kohanaframework.org/discussion/11574/orm-uncompress-vo-vremya-izvlecheniya-Иli-voobsche-

Как видишь, в ORM засунули костыли в виде прямого обращения к БД. Причём опять же сделали это через жопу. Вместо того, чтобы написать красивый, мнемонически понятный запрос, он у них конструируется через вызовы методов объекта DB.

Это и есть геморрой.

Каких?

Каких тормозов? Да я уже постил ссылку. Повторюсь: http://habrahabr.ru/post/148044/

Статья называется "Откуда тормоза в ORM".

И да, ORM генерирует тормозной, неэффективный SQL код, с избыточным обращением к метаданным. Вызванный тем, что моделям требуется знать атрибуты таблицы.

Тут что, так часто меняются сущности? Они вообще почти не меняются. Так что тормозов на уровне данных просто быть не может.

Дело не сущностях, а в их количестве. На таблицах с сотнями тысяч записей ORM вообще поперхнётся.

Форум слишком примитивная система чтобы использовать ORM.

Так я не понял? ORM это удобная технология? Чем же не угодил движок форума?

Предметная область форумов практически неизменна.

Т.е. ORM технология не годная?

В данном движке проблема не в уровне данных,

Так мы не про данный движок. А про движок вообще.

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

А можно примеры задач с хорошей изоляцией? И, чтобы за два дня написать с использованием ORM клиента?