JPA, шаблон или анти-шаблон: иметь как плоские, так и связанные наборы отображений? - PullRequest
2 голосов
/ 05 июля 2011

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

Базовый сценарий состоит в том, что существует сущность, давайте назовем ее Aчто многие стороны отношений с сущностью B. Таким образом, в базе данных A есть поле внешнего ключа, и если мы видим полную объектную модель (упрощенная, удаленные получатели / установщики)

   public Class A {
        public int aKey;
        public B;
        // more attributes 
   }

   public Class B {
        public int bKey;
        public List<A> collectionOfA;
        // and more
   }

Один конкретный сценарийобработка поступления в систему нового As.Они приходят из какого-то внешнего в виде, скажем, текстовых файлов.код вставки должен

   for each CVS record
         get the bKey from the record
         find the B, or manage any error
         create the A, setting the B
         persist

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

В качестве альтернативы я мог бы (и фактически создали) второе отображение для таблицы A

  public Class Ainserter {
        public int aKey;
        public int bKey;
        // more attributes 
   } 

Теперь я просто установил два значения и сохранил.Это предполагает, что БД будет иметь ограничения ссылочной целостности, но с использованием инструментов, которые я использую, это так.В этой и во многих унаследованных системах БД уже существует, и к ней можно обращаться как из нового кода JPA, так и из другого, даже не Java-кода.Поэтому я не вижу смысла ставить проверку ссылочной целостности в коде JPA в таких простых случаях.

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

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

Есть еще мысли?

Редактировать:

От axtavt есть предложение использовать EntityManager.getReference (B.class, bkey) для получения экземпляра B.Насколько я понимаю, что если я сделаю это, то для того, чтобы должным образом соответствовать модели программирования JPA, я должен установить обе стороны отношения, поэтому мне нужно будет посетить объект «ссылка» B и добавить свой A в его коллекцию.

Повторно отредактировано:

Я был обеспокоен тем, что посещение B приведет к поиску в базе данных, поэтому с точки зрения производительности я не получу выигрыш.У меня есть очень хороший авторитет, что, по крайней мере, OpenJPA, на самом деле не нужно будет «раздувать» B, если мы получим доступ только к ключу B и к коллекции As - и поэтому getReference () - хорошее предложение.Мне кажется разумным, что хорошо спроектированная реализация JPA будет иметь такую ​​оптимизацию.

1 Ответ

3 голосов
/ 05 июля 2011

JPA имеет метод EntityManager.getReference(), который в основном объединяет подходы, которые вы описываете.

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

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