Java ORM, можно ли сопоставить Java-бин представлению - PullRequest
1 голос
/ 21 марта 2012

У нас очень большая таблица, мы используем ее для хранения информации о контрактах по различным типам бизнеса.

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

Если мы создали представления для этой таблицы с различными типами бизнеса, могут ли эти представления использоваться в

в любой среде Java Java ORM?

Ответы [ 4 ]

0 голосов
/ 26 марта 2017

ActiveJDBC работает с представлениями, как если бы они были обычными таблицами.Выезд на http://javalite.io.

0 голосов
/ 21 марта 2012

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

Вот простой пример:

@Entity
@Table("myTable")
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(name = "type", discriminatorType=DiscriminatorType.STRING)
public class Common {
    // Common fields, including ID
}


@Entity
@DiscriminatorValue("special1")
public class Specialized1 extends Common {
    // Specialized fields here
}

В приведенном выше примере у вас есть общая таблица со столбцом 'type', которая используется для определения того, какие поля действительны для сопоставленных классов ORM.

В Интернете довольно много хороших учебников. Здесь является одним из них.

0 голосов
/ 21 марта 2012

Уровень ORM по сути просто генерирует SQL, поэтому я думаю, что использование VIEW будет работать, если весь SQL можно будет применить к VIEW, а не TABLE.Только UPDATE s и INSERT s могут иметь проблемы.Если вы можете обновить через представление, все должно быть в порядке;будет ли это возможно, будет зависеть от VIEW и СУБД.

0 голосов
/ 21 марта 2012

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

Но я лично не считаю, что это лучшее решение.Я считаю, что БД должна делать то, что знает: хранить нормализованные данные в таблицах.Бизнес-уровень (в нашем случае написанный на java) должен отвечать за всю логику, включая фильтрацию данных из БД.Это означает, что упомянутое вами представление должно быть "реализовано" на уровне бизнеса.Например, вы можете обернуть свой DAO аспектом, который добавляет некоторые дополнительные условия к предложению WHERE, так что вы получите эффект «представления», реализованный в Java.Это дает вам множество преимуществ, таких как гибкость и т. Д.

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