POJO или DTO подход

Question

POJO или DTO подход

Я разрабатываю новое веб-приложение с Struts2, Spring и Hibernate в качестве основных строительных блоков.

Мы создали классы POJO относительно файлов отображения hibernate.Там будут некоторые входные данные от пользователей, которые должны быть обновлены в базовой базе данных

Например, регистрация или обновление.

У нас есть несколько вариантов, таких как создание новых POJO/DTO для классов действий, которые будут заполнены Struts2, и мы можем перенести их на уровень сервиса, где мы можно преобразовать эти DTO в Уважаемый hibernate POJO, иначе мы можем выставить тот же POJO struts2, чтобы фреймворк мог заполнить их пользовательским вводом, и нам не нужно делать работу по преобразованию и созданию дополнительного набора классов.

Приложение будет небольшим по размеру и будет иметь тег приложения среднего размера.

Мой вопрос заключается в том, как лучше всего передать этот пользовательский ввод в базовый слой hibernate для выполнения конкретной работы с базой данных.

Заранее спасибо

585 2

java hibernate architecture pojo dto

2 ответов:

Comments

Ничего не найдено.

Thomas · Accepted Answer · 2011-11-03 11:35:38

Я бы предпочел подход " DTO " в этом случае, так как вы можете сначала проверить входные данные и запускать обновления только при необходимости.

Тем не менее, вы можете использовать отсоединенные объекты в качестве DTO и присоединять их снова, когда вы хотите создать или обновить их. Если вы не хотите, чтобы веб-часть вашего приложения зависела от Hibernate и / или JPA, вам может потребоваться создать другой набор классов (если вы не используете одну аннотацию).

Dave Newton · Accepted Answer · 2011-11-03 11:38:47

Вы получите оба ответа на этот вопрос.

С распорками 2 я склонен использовать нормальные свойства действия S2 для сбора значений формы/и т. д. и используйте BeanUtils, чтобы скопировать их в объекты Hibernate. Проблема с выставлением объектов Hibernate в виде, как с ModelDriven и т. д. это то, что вам нужно определить белые/черные списки, если у вас есть столбцы, которые должны Не быть установлены непосредственно пользователем. (Или решить проблему по-другому.)

Тем не менее, я не принципиально против к идее, как и многие люди, и они, возможно, правы.