POJO или DTO подход - PullRequest
       26

POJO или DTO подход

3 голосов
/ 03 ноября 2011

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

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

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

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

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

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

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

Ответы [ 2 ]

4 голосов
/ 03 ноября 2011

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

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

0 голосов
/ 03 ноября 2011

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

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

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

...