Доменные приложения без ORM - PullRequest
6 голосов
/ 03 февраля 2011

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

Это заставляет меня спросить: так ли устроено большинство приложений? Смысл - да, ОО - это хорошо, но мне трудно поверить, что при всех проблемах, связанных с этим несоответствием объектов, это лучший способ для создания приложений? Альтернативный подход, который я могу придумать, состоит в том, чтобы отказаться от ORM и просто моделировать предметную область, и писать собственные запросы SQL напрямую и равномерно вручную. Я хотел бы знать, существуют ли на самом деле программные системы достаточного размера, построенные таким образом.

Извините, если я говорю n00bish - но я новичок и хотел бы знать, какие есть другие подходы.

Ответы [ 2 ]

3 голосов
/ 03 февраля 2011

Не извиняйся за признание очевидного.Те, у кого гораздо больше опыта, часто совершенно не понимают, что у вас есть: ORM - это плохая инженерия, именно по тем причинам, которые вы укажете.Аргументы против использования встроенного SQL варьируются от стилистического: «я не хочу, чтобы этот мусор был в моем коде», до… стилистического, «SQL уродлив».Но это работает, это быстро, и это хорошая инженерия.

2 голосов
/ 04 февраля 2011

Можно использовать оба.

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

Для всего остального король - простой SQL.

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

...