Какие проекты веб-разработки выигрывают от использования ORM?

10

Я начну с того, что 95% своей базы данных я выполнил, используя SQL. Недавно я провел некоторое исследование различных ORM, таких как NHibernate и Doctrine.

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

Поскольку я очень комфортно пишу на SQL и, видимо, не осознаю часто преподносимых преимуществ использования ORM, мой вопрос для пользователей ORM:

Какие проекты веб-разработки получают наибольшую выгоду от использования ORM?

— Фред Уилсон
источник

3

Ответ: «Все они». Но это, вероятно, не то, что вы хотите знать. Вы можете уточнить свой вопрос, чтобы задать более конкретную информацию.

— S.Lott

1

Для меня SQL в настоящее время легче производить, но это только из-за моей акклиматизации (или незнания). Я читал, что ORM не всегда лучший выбор, потому что он медленнее, чем обычный SQL; однако многие разработчики заявляют, что это обычно не важно. Меня больше всего интересуют проекты, которые лучше всего подходят для ORM. Я вижу, что большинство ответов, вероятно, будут «все», и это тоже хорошо. Я не ищу конкретного ответа. :)

— Фред Уилсон

Если вы не попросите более подробную информацию, вы не будете много учиться.

— S.Lott

5

(Почти) все приложения получают выгоду от ORM.

Во-первых, я не согласен с перечисленными вами преимуществами для ORM .

Использование ORM не обязательно означает, что вам не нужно знать SQL. Знание SQL поможет понять, что на самом деле делает инструмент ORM, что особенно полезно при отладке. Более того, SQL может фактически потребоваться для разработки сложных запросов, выходящих за пределы возможностей выбранного вами ORM.
И, как вы говорите, портативность редко вызывает беспокойство в реальной жизни.

Вместо этого настоящие преимущества ORM:

ORM экономит время программиста, потому что он экономит на написании тонны CRUD-логики в SQL
многие ORM содержат сложную логику кеширования и т. д., которые сложно написать и отладить. Помимо экономии времени это может повысить надежность и удобство обслуживания вашего приложения (или, по крайней мере, сэкономить время, которое потребуется для достижения тех же результатов)
У лучших ORM есть сообщество пользователей, которые активно разрабатывают, поддерживают и поддерживают продукт. Сообщество вокруг пользовательского SQL в лучшем случае несколько менее сосредоточено на проблемах, которые нам нужно решить.

Как вы прокомментируете, один недостаток ORM - это потеря производительности. Однако это обычно можно компенсировать, потратив больше оборудования.

Как правило, время программиста дороже, чем аппаратное обеспечение, поэтому ORM - это вообще хороший вариант вместо ручного кодирования SQL.

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

Приложения, которые нуждаются в небольшом / нулевом доступе к базе данных.
Приложения, которые в значительной степени зависят от сложных запросов и очень мало простой CRUD-логики
Ситуации, когда производительность критична, но нет возможности развернуть более быстрое оборудование

По моему опыту, такие ситуации редки. Отсюда и мой ответ.

— Kramii
источник

«Использование ORM не обязательно означает, что вам не нужно знать SQL». - Это точно. Одним из преимуществ, которые я вижу в командной среде, является то, что мы можем сконцентрировать набор навыков SQL, чтобы не каждый разработчик, работающий на бизнес-уровне, был экспертом.

— Фред Уилсон

1

Для сложных запросов вы всегда можете вернуться к SQL и написать запрос SQL.

— harsimranb

4

Мне удобно писать и SQL. Мне также гораздо удобнее вообще не писать SQL, а также не беспокоиться о подключении, отключении, пуле и т. Д. К базе данных.

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

— Otávio Décio
источник

+1: я тоже считаю себя очень опытным в sql, но все же предпочитаю OR / M. На самом деле, я бы сказал, что вам определенно нужно иметь дескриптор sql, чтобы эффективно использовать OR / M, иначе, когда будет получена утечка, вы никогда не найдете проблему. «не нужно много знать SQL» - это не особенность. На мой взгляд, все дело в повышении производительности и в том, что компилятор обнаруживает проблемы, а не время выполнения и OR / M (особенно в этом есть новинка на основе generics / linq).

— Брук

@ Брук - я искренне согласен. Использование OR / M не означает, что знание SQL необязательно.

— Otávio Décio

2

Основываясь на моем опыте работы с ASP.NET WebForms, я бы предложил, чтобы веб-проекты, использующие веб- фреймы с сохранением состояния, извлекали наибольшую выгоду из использования ORM.

В инфраструктуре с отслеживанием состояния разметка создается автоматически за кулисами на основе иерархии активных серверных элементов управления. Соблазнительно заставить эти элементы управления загружаться и автоматически сохранять их состояние в базе данных. Вот где ORM помогает.

Вы как бы абстрагируете конец конвейера (вывод HTML), и он, естественно, приглашает работать с началом (источником данных) таким же образом, чтобы вы оставались только в рамках своей бизнес-логики в коде приложения.

Не то чтобы я не говорил, что это хороший способ сделать что-то. Это просто, где ORM подходит естественно.

2

В приложениях, где у вас есть большая, очень связанная объектная модель, ORM избавляет вас от необходимости писать одни и те же объединения снова и снова.

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

— Пол Санвальд
источник

1

Я считаю, что вы путаете ORM с DBAL .

Концепция, на которую вы ссылаетесь - это уровень абстракции базы данных (DBAL), который позволяет вам писать переносимый «sql», который не зависит от базовой системы баз данных.

ORM с другой стороны (который (почти?) Всегда построен поверх DBAL):

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. This creates, in effect, a "virtual object database" that can be used from within the programming language. (Википедия)

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

— Craige
источник

Спасибо за разъяснение. Основная причина для меня перейти на ORM - больше сосредоточиться на ООП и отойти от написания как можно большего количества SQL, если это имеет смысл для некоторых проектов.

— Фред Уилсон

1

Проекты, которые не выиграют от ORM, будут:

те, которые не являются объектно-ориентированными;
те, которым не нужно сохранять данные;
те, которые используют объектно-ориентированную БД, поэтому не нуждаются в дополнительном слое отображения;
те, которые используют нереляционное решение NoSQL;

— Vartec
источник