Как я могу разработать веб-приложение Java без ORM и без встроенного [закрытого] SQL

Почему, ох, почему индустрия так привязана к этой катастрофической концепции? Ни один из предыдущих ответов адекватно не решает проблемы @ johnny. Все они - наполовину выдуманные оправдания, которые избегают конкретных проблем, с которыми сталкиваются программисты баз данных.

Ответ @ TheTXI типичен для ответов, которые я получаю, когда задаю тот же вопрос: разделение слоев. Что это должно значить? Почему я хочу, чтобы разделял мои слои? Или, что более важно, какая польза от создания дополнительного уровня, который отличается от реляционного уровня и при этом должен быть каноническим отображением этого уровня?

Кроме того, (пока что оставшийся без ответа вопрос @johhny ) как это защищает нас от изменений? Если база данных изменится, уровень ORM почти наверняка последует этому примеру. Фактически, практика по умолчанию, при которой не моделируются таблицы соединений на уровне объекта, делает это еще хуже, потому что, когда таблица неизбежно вырастает несколько дополнительных столбцов, вы не только добавляете некоторые дополнительные поля в объектную модель, но также меняете ее топологию и принудительно куча кода переписать! Это катастрофа для управления изменениями и классический пример того, как ошибочный взгляд на отношения (думая, что они представляют собой объекты) приводит к катастрофе. Этого просто не произошло бы, если бы вы просто сопоставили реляционную базу данных непосредственно с совпадающими понятиями в языке программирования (подумайте о LINQ-to-SQL, а не , а не LINQ-to-EF).

Самый большой вопрос без ответа в этом пространстве - слон в комнате - это: какую проблему должна решить ORM? И не говорите «объектно-реляционное несоответствие импеданса». Это просто очередной размахивая руками. Объясните, почему существует несоответствие импеданса и почему именно база данных должна обращаться к языку, а не языку, передаваемому в базу данных. Мое объяснение состоит в том, что большинство языков программирования плохо справляются с выражением реляционных данных и работой с ними, но это историческая реальность, которая начинает ускользать (LINQ-to-SQL был первым маленьким шагом в этом направлении), а не фундаментальный принцип на которой основывается звуковая архитектура.

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

(Я полностью ожидаю, что этот ответ будет полностью отвергнут. Но, пожалуйста, оставьте комментарий, когда вы это сделаете. Я не возражаю, если мне скажут, что я неправ, если я знаю почему.)

РЕДАКТИРОВАТЬ : Спасибо, @Chris, за то, что нашли время прокомментировать. Это дает мне несколько конкретных вопросов ...(Обратите внимание, что, хотя я часто обращаюсь к @Chris ниже, я не пытаюсь дать ему конкретную задачу; его ответы типичны для тех комментариев, которые я слышу все время при обсуждении темы. Поэтому я надеюсь, что он не принимает мои критика как личное оскорбление; они не предназначены для этого, и я искренне ценю время, которое он потратил на ответ.)

Прежде всего, позвольте мне прояснить некоторые заблуждения, очевидные в комментариях и ответе @Cris.

1. Я не защищаю необработанный SQL в коде по всем очевидным причинам, а также по некоторым не столь очевидным (например, SQL не является ни алгеброй, ни исчислением, что делает функциональную декомпозицию практически невозможной).
2. Я не сторонник монолитного проектирования приложений. Слои - это вообще хорошо.
3. Я не защищаю загрязнение объектных моделей большим количеством линейных помех, таких как специальные поля, методы и атрибуты. Честно говоря, это пустяк, поскольку модели предметной области / объекта существуют только во вселенной ORM. Теперь я знаю, что в LINQ-to-SQL есть все эти классы с большим количеством «зашумленных» битов, но они всего лишь за кадром; вы не редактируете этот код и, как правило, не должны даже смотреть на него.

Теперь некоторые возражения против возражений:

1. Утверждение, что приложения могут быть построены независимо от базы данных, необоснованно. По большому счету, ORM - это просто каноническое отображение на уровень данных (таблицы Foo и Bar становятся классами Foo и Bar, а таблица FooBar становится своего рода жарким делом между классами Foo и Bar).В этом сопоставлении не так много места для маневра, поэтому любое изменение модели данных почти наверняка потребует соответствующего изменения объектной модели. На мой взгляд, это хорошо, поскольку объект, радикально отличающийся от соответствующей модели базы данных, стал бы не чем иным, как дополнительной головной болью при обслуживании для всех заинтересованных сторон.
2. Когда иллюзия о том, что ORM порождают независимость от модели данных, отбрасывается, все протесты о вреде прямого связывания с моделью данных становятся спорными. Но я хотел бы продолжить это немного дальше, чем просто отклонить это. Сцепление - важная особенность конструкции системы. В какой-то момент должны быть сделаны решения и предположения. Вы не можете запрограммировать все, используя одну таблицу «Вещи». Вы должны решить, что ваш домен содержит определенные конкретные концепции, а затем создать схемы и код, которые уважают эти концепции, обращаться с ними как с первоклассными гражданами, жестко их кодировать. Идея о том, что приложения должны быть независимыми от базы данных, ошибочна. База данных является (или должна быть) наиболее чистым представлением бизнес-знаний (я знаю, что это не всегда так, и я расскажу об этом позже). Связывание с этим представлением должно обеспечить самую надежную гарантию устойчивости, поскольку такая модель данных будет меняться только тогда, когда сам бизнес претерпевает некоторые внутренние изменения. Короче говоря, привязка к хорошо спроектированной схеме базы данных - это очень хорошо.
3. Наслоение не является самоцелью. Это хорошо, потому что достигает определенной цели. Предыдущие пункты показывают, что разделение на уровни между базой данных и приложением, как это делает ORM, не является ни эффективным, ни необходимым для достижения реальной цели устойчивости к изменениям. Это достигается за счет хорошего дизайна базы данных.
4. @Chris утверждает, что позволяя базе данных диктовать вещи, объектно-ориентированный дизайн блокируется. Это верно, но это интересно только в том случае, если объектно-ориентированный дизайн - лучший способ моделирования знаний.Практически полный отказ ООСУБД на рынке указывает на то, что это не так. Реляционная модель, основанная на логике предикатов, обладает той же выразительной силой, что и объектно-ориентированный дизайн, но при этом не требует теоретико-графических сложностей объектно-ориентированных моделей.
5. Возражения @ Криса против реляционной модели на том основании, что она не решает сегодняшних проблем (отсюда движение NoSQL), совершенно неуместны. NoSQL означает «Нет SQL», а не «Нет реляционной модели». К сожалению, даже сторонники движения NoSQL кажутся совершенно невежественными в этом отношении. SQL имеет глубокие недостатки, многие из которых объясняются его радикальным отходом от реляционной модели. Сказать, что мы должны отказаться от реляционной модели, потому что SQL - отстой, - это довольно вопиющий случай выбросить ребенка вместе с водой из ванны.
6. Отказ от использования ORM не утроит усилия по созданию приложения. Это смехотворное утверждение, и даже @Chris, кажется, держит заднюю дверь открытой, делая обратный комплимент альтернативе кодогенерации. Инструменты кодогенерации, такие как sqlmetal из LINQ-to-SQL, являются идеальным решением для всех, кто не придерживается догмы о том, что модель данных приложения обязательно должна отличаться от модели данных базы данных.

Мой собственный опыт работы с ORM показал, что они отлично работают в обучающих программах и вызывают бесконечную боль и разочарование в реальном мире. Поскольку LINQ-to-SQL устраняет многие проблемы, которые изначально мотивировали ORM, я не вижу причин подвергать себя таким пыткам.

Остается одна серьезная проблема: нынешний урожай баз данных SQL не предлагает какой-либо значимой степени контроля над разделением физического и логического уровней. Отображение таблицы на содержимое диска в значительной степени фиксировано и полностью находится под контролем СУБД SQL. Это не входило в план реляционной модели, которая явно разделяла эти две модели и позволяла определять согласованное логическое представление данных, которые могли бы храниться на диске в совершенно иной структуре, чем предполагалось в логической модели. Например, система (или dba) может физически денормализовать - по соображениям производительности - сильно нормализованную логическую модель. Поскольку механизмы SQL не допускают такого разделения задач, обычно денормализует или иным образом искажает логическую модель по чистой необходимости. В результате логические модели не всегда могут быть точно такими, какими должны, и поэтому идеал использования базы данных как наиболее чистого представления знаний не может быть полностью реализован. На практике, однако, дизайнеры в любом случае обычно придерживаются канонического отображения базы данных в модель предметной области, потому что все остальное слишком болезненно поддерживать.