Гибернация нескольких пользователей, динамически меняется - PullRequest
3 голосов
/ 22 сентября 2011

Технически здесь два вопроса, но они тесно связаны:)

Я использую Hibernate в новом проекте.Это POS проект.Он использует базу данных Oracle.

Мы решили использовать Hibernate, потому что проект большой, и потому что он предоставляет (самые популярные) возможности ORM.

На данный момент Spring не используется.Вопрос - причина в том, что проект является клиент-серверным приложением Swing, и это добавляет ненужную сложность.Кроме того, Spring, как предполагается, очень голоден на аппаратных ресурсах.

Существует возможность выбросить Hibernate и использовать JDBC.Зачем?Требование проекта точное взаимодействие с базой данных .Это означает, что мы должны иметь полный контроль над соединениями, сеансами и транзакциями (и, да, такими же низкими, как неоптимизированные запросы).

Первый вопрос: каково ваше мнение об использовании упомянутой заявки??

Второй вопрос касается Hibernate.

Мы разработали простой пилотный проект Hibernate.Другое требование проекта - один пользователь базы данных / одно соединение на пользователя / один сеанс на пользователя / транзакции являются гибкими (мы можем завершить их, когда захотим, как сеансы) . Несколько пользователей могут одновременно войти в приложение .

Мы достигли чего-то подобного.Чтобы быть точным, мы достигли полной описанной функциональности без требования для нескольких пользователей .

Теперь, рассматривая доступные ресурсы, я пришел к выводу, что если мы хотим, чтобы несколько пользователей включалибазу данных (в той же схеме) мы в конечном итоге будем использовать несколько SessionFactory , реализуя динамический ConnectionProvider для новых пользовательских подключений.Почему?

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

Второй вопрос - можно ли сделать это немного проще?кажется странным, что Hibernate не поддерживает такие конфигурации.

Спасибо.

Ответы [ 2 ]

1 голос
/ 23 сентября 2011

Если вы размышляете о погоде, чтобы использовать Hibernate или JDBC, честно, перейдите на JDBC.Если модель вашего домена не слишком сложна, вы действительно не получите много преимуществ от использования hibernate.С другой стороны, использование JDBC значительно повысит производительность, поскольку вы лучше контролируете свои запросы и получаете НАМНОГО меньше использования памяти, не тратя все накладные расходы на Hibernate.Сбалансируйте это, сделав максимально подробный первый эскиз вашей модели.Если вы можете сделать все это с самого начала (нет частей, которые можно сильно изменить в течение всего проекта), и если указанная модель не заинтересована, JDBC станет вашим другом.

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

В качестве последнего замечания, если вы действительно придерживаетесь решения ORM (по любой причине), если возможно, выбрал реализацию EclipseLink JPA2.В JPA2 больше возможностей, чем в спящем режиме, а реализация Eclipselink менее глючна, чем в спящем режиме.

0 голосов
/ 04 октября 2011

Итак, что касается Hibernate, я до сих пор не знаю, был ли единственный способ динамически изменить пользователей базы данных (изменить соединения с базой данных) - создать несколько фабрик сессий, но я предполагаю, что это так.

Мы имеемпонизил наши требования и решил использовать Hibernate, использовать только одного пользователя в базе данных (одно соединение), один сеанс на пользователя (несколько сеансов / несколько «логических» пользователей).Мы создали пару классов Java, чтобы обернуть эту функциональность.Ресурсы, как это можно сделать, можно найти здесь .

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

Например, если у меня естьGUI, который должен сохранить страницу, сначала я должен получить все статьи страницы, а затем, после сохранения страницы, обновить все статьи FK на эту страницу.Обратите внимание, что я говорю существительными (объектами), и я не вижу другого способа обернуть страницу / статьи, , кроме использования глобального состояния .Это единственное, что я не хотел бы видеть в своем приложении, и мы, в конце концов, используем Java, язык ОО.

Когда у нас уже есть преобразователь ORM, который можно настроить (принудительным будетболее точное слово, которое нужно использовать в этом конкретном примере), чтобы обработать саму вещь, зачем программировать ее?

Кроме того, мы решили использовать google Guice - это намного быстрее, безопаснее иможет значительно упростить нашу разработку / обслуживание / тестирование.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...