Как избежать дублирования кода модели с JSF и JPA

Question

Я новичок в JSF, и мне интересно, правильно ли я понял. Предположим, у меня простая CMS, которая позволяет писать страницы.

Во-первых, я определяю сущность JPA под названием Page:

@Entity 
public class Page { 

    @Id 
    @GeneratedValue(strategy = GenerationType.AUTO) 
    @Column 
    private Long id; 

    @Column private String title; 

    @Column private String content; 

    // getters & setters ... 

} 

Тогда я хотел бы в целях создания страницы-х годов. Для этого, похоже, мне нужен какой-то компонент страницы. Сейчас я обращался вещи, как это:

@Model 
public class PageBean { 

    private Page page = new Page(); 

    public String getTitle() { 
     return page.getTitle(); 
    } 

    public void setTitle(String title) { 
     page.setTitle(title); 
    } 

    // rest of properties & getters & setters ... 

    public void save() { 
     // persist using EntityManager 
    } 
} 

Мой вопрос заключается в следующем: учитывая, что моя JPA модель сущности и модель, которую я хочу использовать в представлениях являются большой частью времени точно так же, есть способ избежать необходимости создания партии геттеров & сеттеров в PageBean?

Я где-то читал, что вы не должны использовать один и тот же компонент в качестве объекта JPA и JSF-модели (поскольку JSF выполняет повторные вызовы для геттеров, которые могут повлиять на JPA), но я действительно задаюсь вопросом, нет ли более простого способа, который помог бы избегая такого рода дублирования кода. Особенно, когда у вас есть приложение с большой моделью и во многих случаях не требуется ничего особенного в представлении beans, похоже, что это может стать довольно громоздким.

Answer 1

[...] учитывая, что моя модель сущности JPA и модель, которую я хочу использовать в представлениях, в большинстве случаев точно такие же, есть ли способ избежать создания партии геттеров & сеттеры в PageBean?

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

Я где-то читал, что вы не должны использовать один и тот же компонент, как JPA сущность и JSF модель боб (потому что JSF делает последовательные вызовы добытчиков, которые могут повлиять на JPA)

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

Только в том случае, какие-то дополнительные ресурсы:

• EclipseLink/Examples/JPA/JSF Tutorial

Answer 2

Это не дублирование кода. Алгоритмы не дублируются. Бизнес-логика все еще находится в одном месте.

Что делает ваш bean-компонент, это просто подключение модели View to Domain. Это хорошо, это часть шаблона MVC.

Если вы использовали свой объект JPA как свой бэк-бэк, вы нарушаете шаблон MVC. Например, если в один прекрасный день вместо отображения простого String вам нужно будет добавить Date к этому String, потому что для представления требуется так (например, требования к интерфейсу), собираетесь ли вы писать эту логику представления внутри класса JPA? Это не имеет смысла, смешивая модель домена и модель представления.

С другой стороны, почему представление должно знать о том, как домен реализован? Что делать, если формат значений домена изменяется? (Например, вы сохраняете временную метку String вместо класса даты в базе данных по соображениям производительности). Все, что вам нужно сделать, это просто переписать метод в bean-компоненте, это займет метку времени и адаптировать ее к дате, чтобы все было так, как было раньше. Только одно изменение за пределами класса JPA. Если бы у вас было это в классе JPA, вы бы закончили поддерживать обе логики только в одном классе (логика интерфейса и логика домена).

Что делать, если вы хотите разработать новый вид (например, для мобильной версии)? Собираетесь ли вы добавить еще один код в класс JPA? Было бы лучше сохранить JPA как есть и создать еще один Bean (который расширяет общий компонент для обоих представлений) для мобильной версии.

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

#{myBean.page.title} 

все, что вам нужно, это getPage() внутри опорного компонента.