МСУНе понимаю, всё же. В чём тяжелость и избыточность хибера? Нужно переключиться на другую БД (например, Oracle) - переключаем провайдер в конфиге. Нужно развернуть базу по схеме в инсталляторе - вызываем метод, который по схеме все сделает.

большинство проектов, о которых я знаю, либо никогда не меняли базу, либо делали это исключительно ради оптимизации (например, переход с sql на nosql). Нельзя тупо поменять базу, ничего не поменять в коде и получить +500% в скорости. Так что ИМХО смена базы — проблема и, соответственно, выгода, сильно надуманы. Да, ты сейчас скажешь что ORM позволит оставить бОльшую часть кода как есть, но тот же переход sql->nosql требует заодно и смены подхода к работе с данными. А количество кода, которое необходимо будет переписать, зависит не от факта использования ORM, а от наличия первоначальной абстракции DAL и BL.

В хибере очень много всего, что нужно настроить, чтобы заработало. Более высокий порог вхождения. А если внезапно начнет глючить в неумелых руках, то ошибки можно искать долго и упорно. Особенно коварны транзакции и кэш. В некоторых случаях кэш вообще нафиг не нужен, а он есть. А если несколько серверов — появляется ещё и проблема репликации кэша. Я не говорю что это отмазки ламеров чтобы не использовать. Пожалуйста, если это все нужно и умеешь работать. Но если нет — то хибер крайне избыточен и потери CPU внутри на все перделки при большой нагрузке становятся сильно заметны.

Например, мне нужно делать выборки актуальных данных по вроде бы простым динамическим критериям. Нужно делать очень быстро, много и на большом объеме данных. Хибер не в состоянии это закэшировать, просто нет таких алгоритмов. Он хорошо справляется с поиском по ключу, но сложнее — проходит мимо. Лучше взять инструмент проще и эффективнее, например mybatis, и получить то, что мне нужно, сразу и без танцев.


МСУНо так или иначе, самое ценное в ORM - это типизация хранилища, как следствие родной человеческий интелиссенс, с которым одно удовольствие работать. Рутинные же SELECT FROM WHERE в прошлом.

Ну ты уж определись, тебе чтобы код быстрее писать, или чтобы написанный код быстрее работал. Иногда приходится чем-то жертвовать.
Селекты бывают рутинные только если ты работаешь с таблицами данных по типу простых CRUD по ключу, и это не обязательно должно работать сверхбыстро. Тут да, я уже писал, ORM пожалуйста. Ну а в остальных случаях те же селекты, фром, вэрэ, куда ж без них :) но уже в других ракурсах.

Enomayиспользуя ORM, я пропишу это условие в одном месте и все запросы будут работать правильно. в вашем случае вы будете тупым поиском пересматривать все текстовые запросы и хранимые процедуры. а если добавится еще условие? будете лазить еще и еще. при этом нет никакого контроля, что вы не сломали нигде ничего. ведь тестами это покрыть вы не можете.


Я не очень понимаю, как ты представляешь себе архитектуру приложения с ORM и без? Почему, если нет ORM, то обязательно все будет раскидано по разным частям кода? Ну вот просто как-то не понимаю :)
Enomayиспользуя ORM, я могу наследовать логику, а значит и запросы к базе. в вашем случае, вам придется использовать динамический SQL, который привнесет дополнительный ад в проект.

а с ORM, если нужно делать выборки по динамическим критериям, не нужно будет писать динамический запрос на одном из этих самых языков запросов? sql-подобный как в хибернейте или какие-нибудь конструкторы критериев? это не как АД выглядит? :) что за предрассудки?

LelouchЕсли под динамическими критериями подразумевается то что запрос меняется в зависимости от условий то на LINQ это спокойно пишется без SQL, Entitu SQL , etc.
да спасибо что глаза открыл, я этого и не отрицал. Я говорил что выглядит это по сути так же как составление динамического запроса на sql. Так что аргумент Enomay про какие-то там сложности мне не очень понятен.

кстати напиши мне без стороннего кода условие where с поиском по названию поля, переданному как аргумент, на linq
да ладно, можешь не писать, суть надеюсь понял. Задача стара как боян и существует с момента появления самого linq, и вроде как самой библиотекой она так и осталась нерешенной.

фуфуфу. конечно нет

LelouchНет, это выглядит совершенно по другому.)
а что другого-то? ты правде в глаза погляди, решение проблемы на большинстве предлагаемых инструментов выглядит одинаково +- пара букв.

http://www.mybatis.org/core/statement-builders.html
и хреначь в свое удовольствие.

SolYUtorВы часом не OLAP на хибер пытались навесить? Может быть пример очень быстро, много и на большом объеме данных приведёте? А то похоже на ситуацию "выбери любых два пункта"
Да и проекции в хибере никто не отменял, и выполняются они намного быстрее работы с сущностями.
нет, упаси меня от olap и кубов. Какой конкретный пример? Любой публичный сервис, задача которого — обрабатывать выборки хотя-бы со скоростью пару десятков тысяч запросов в секунду по базе размером, ну пусть от 50гигабайт, уже лучше давно пора начать избавлять от хибернейта и прочих монстров. Хотел привести социальную сеть, но неразумно — там можно много и яростно кэшировать и актуальность там не критична. Пусть будет какой-нибудь сервис для совместной работы людей над XXX в реальном времени. Выборки включают фильтрацию по правам, коллекциям и атрибутам XXX для отображения данных конкретному пользователю.

LelouchА если я в этом инструменте сначала вызову метод Where а потом Join? он переместит строку Join выше условия?

а если я с головой не дружу, компьютер мне поможет? :) в linq ты не можешь случайно переставлять все подряд местами, иначе получится что из базы выходит все, а фильтрует приложение.
LelouchПрям одно и тоже, особенно с типизацией и возможностью обработки noSQL (для EF достаточно найти провайдера. а для этой библиотеки что?)
Я уже писал выше свое отношение к смене сервера, нужно следить за дискуссией. Так что если нужен nosql, я буду сразу на нем писать. Кстати mybatis поддерживает только sql, впрочем как и linq to sql.