Выборка данных с ORM — это просто! Или нет?

[JustDont]

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

Превращать реляционные данные в объекты — это не «нужно», это всего лишь «хочется». Драйвером ORM всегда было желание получить плюшки БД в свой уютненький ООП, не покидая его, и, желательно, сильно не задумываясь над процессом. Итог закономерен — за получение удобной абстракции придётся заплатить очень большой ценой по памяти и производительности. Это не всегда имеет значение (и поэтому, действительно, ORM едва ли куда-то денется, хайлоад не всем нужен), но всегда присутствует в объективной реальности.

[EvgeniiR]

ORM — отличный инструмент чтобы при проектировании сущностей думать об их поведении, и удобненько инкапсулировать в них бизнес логику, не беспокоясь о том, как это всё будет храниться в БД и исключить любые зависимости от persistance слоя. Сохранять, обновлять и доставать из хранилища сущности для обновления, чтобы получить основные плюшки тяжеловесных ORM типа UoW и Identity Map.

Выборка данных и ORM — вещи не совместимые, потому что «данные» и «объект» по определению разные вещи.

С подходом описанным в статье, наши сущности постепенно превращаются в наборы данных, внутрь просачивается логика помогающая лишь отображать их пользователю (привет getNameLowercase(), да и геттеры в принципе), данные группируются по принципу того что они вместе отображаются а не изменяются, бизнес логика растекается по системе.

Возможно это приемлемый вариант когда логики в системе минимум, а в качестве ORM выступает простенький Active Record / Row data gateway / Table data gateway, но я не считаю такой подход удачным в ентерпрайз приложениях, о которых ведётся речь в статье.

[a_belyaev]

Есть разные подходы. Кто-то предпочитает «анемичные» сущности и бизнес-логику вынести в сервисы, кто-то старается добавить в сущности сложную логику и поведение.

Я не очень понял, почему вы решили, что бизнес-логика растекается по системе. Мы ограничиваем доступ к атрибутам, исходя из того, что именно нужно для реализации того или иного бизнес-кейса, который как раз реализован в классе-сервисе. А кейс может обрабатываться как в UI, так и в классе, которому выдана только необходимая ему проекция сущности. Этот подход хорошо работает, если у вас в сущностях большое количество атрибутов.

[manyakRus]

в языке 1С вообще нет проблем с ORM,
оно там уже есть жёстко связано по умолчанию.
1С в 100 раз лучше насчёт этого :)

[atelizhenko]

А как же этот баг :)