jpa в настольном приложении SWING

Question

Я разрабатываю настольное приложение для моно пользователей, используя SWING.У меня был небольшой опыт работы с такого рода приложениями, в которых я использовал API Java.QL и понял, что это совсем не удобно ...

В своем новом приложении я впервые пытаюсь использовать JPA, я прочитал много уроков, которые помогли мне понять почти все, что мне нужно, но не нашел хорошего примера для реальногонастольные приложения java.

Я думаю об использовании следующей архитектуры, но не знаю, прав ли я ...

Я думаю о создании класса MyPersistenceUnit:

    public class MyPersistenceUnit {
        private static EntityManagerFactory factory;
        private static EntityManager entityManager;

        public static void initiate(){
            factory=Persistence.createEntityManagerFactory("PU_Name");
            entityManager=factory.createEntityManager();
        }

        public static EntityManager getEntityManager() {
            return entityManager;
        }

        public static void close(){
            entityManager.close();
            factory.close();
        }

    }

метод initiate () будет вызван первым, а метод close () будет вызван при закрытии приложения.

Во время работы приложения все транзакции будут выполняться через экземпляр getEntityManager (), который доступен в любом месте приложения.Если я правильно понимаю приложения JSE, полученный диспетчер сущностей имеет расширенный контекст персистентности, который будет держать все сущности в управляемом состоянии, пока диспетчер сущностей не закрывается, и это заставило меня так думать ...

Я не знаю, пропустил ли я что-то, поэтому любой совет будет оценен

Обратите внимание, что я использую поставщика eclipselink со встроенной базой данных derby.Спасибо

Answer 1

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

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

Были различные дискуссии, где об этом говорили более опытные люди, вы можете следить за этим здесь: для и counter аргумент наэтот SO вопрос - Управление сессиями с использованием Hibernate в приложении Swing

Также см. this по той же теме.

Здесь образец настольного приложения, созданного коммиттером hibernate.Он немного староват, вы можете понять это.

И, наконец, , эта - отличная статья для понимания общих концепций JPA для настольных приложений.

Answer 2

Переосмыслив свой дизайн, я решил изменить его следующим образом:

• создать «постоянный» EM при запуске приложения и держать его открытым до его закрытия.ПостояннаяEM будет использоваться для поиска / обновления сущностей при необходимости (например, для извлечения ленивых отношений ...).Чтобы обеспечить эффективное управление памятью с помощью WEAK refrence-mode, я буду избегать постоянных ссылок на управляемые объекты постоянного EM.
• создайте «временный» EM для загрузки «постоянных» данных, которые необходимыдля начала приложения.После загрузки данных закройте временный EM, чтобы отсоединить все данные, загруженные в память.
• создайте новый «временный» EM для каждой транзакции persist / merge / remove и закройте его после фиксации транзакции.

Answer 3

вы смотрели на http://docs.jboss.org/hibernate/core/4.0/manual/en-US/html/transactions.html#transactions-basics-issues. Я думаю, было бы целесообразно прочитать документацию там, прежде чем продолжать использовать объект сеансов в течение слишком длительного времени. Я полагаю, что лучше всего использовать сессию для выполнения простой единицы работы (например, операции CRUD).

Надеюсь, это поможет !!.

Привет.

Answer 4

Поскольку это приложение SE, вы можете использовать встроенную базу данных.Я знаю, что H2 обычно разрешают одно посещение потока, поэтому, если вы находитесь в одной и той же среде разработки и хотите избежать контроля одновременности объекта при головной боли.

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

не разрешать другим потокам использовать сущности, а затем определить интерфейс доступа к данным, который может передавать данные от сущности к другим объектам в надлежащей структуре данных.

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