Вопрос по – Использование объектов передачи данных в ejb3 считается лучшей практикой

12

Хотя очевидно, что не все сценарии могут быть охвачены одним проектом, обычно считается, что классы ORM должны передаваться туда и обратно между уровнем представления и бизнес-уровнем (локальным или удаленным), заменяя необходимость в объектах передачи данных? Насколько я вижу, использование классов ORM создает проблемы излишней загруженности, проблем с управлением контекстом и тесной связи, но также экономит много времени и делает вещи простыми. Есть ли сейчас стандартный подход, который обычно предпочитает один другому (для большинства ситуаций)?

Ваш Ответ

6   ответов
4

Это очень интересный вопрос, который я изучал и экспериментировал в течение двух лет.

Я думаю, что здесь действительно нет правильного или неправильного ответа. Я не думаю, что вы можете просто сказать, что я хочу одного над другим, потому что обычно вам может потребоваться гибрид в зависимости от того, какие у вас клиенты (веб-страница, ws, компьютер и / или локальный, удаленный).

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

Например:

  • If you were using SEAM, then you would want to avoid a heavily layered architecture because you have access to an extended persistence context. Other web technologies without this support tend to work better with a DTO which prepared the state upfront.
  • If you are sending a remote message the import thing is to keep it thin and lightweight, a DTO would typically work better here than a rich domain object. Here you can suppress transparently any ORM issues/behavior.
  • DTO pattern has the benefit of protecting your clients from domain changes. This is particularly important if your app is a web service, having a domain (entity) object which defines your contract might leave you unstuck at some point.

Оборачивая вашу систему в слои и тщательно обнажая и защищая их, вы можете создавать различные API для множества клиентов разных типов.

2

Тесная связь? Пожалуйста, объясни.

Что касается меня, DTO - это Anti-Pattern. EJB3 позволяет нам не использовать их. Вы можете просто принудительно выполнить ленивую инициализацию перед отправкой Entity клиенту.

Конечно, если вам нужно только два из 30 полей для отправки клиенту, вы просто отправляете их. Но если целые копии все время, как в моем текущем проекте - попытайтесь избавиться от этого DTO. Я не вижу причин использовать их. Вы отправляете бизнес-объект клиенту по запросу клиента. Зачем использовать обертку?

1

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

0

Я согласен с последним "оратором" зачем использовать обертку, когда в ejb3 ?? Мы строим довольно сложную систему без DTO, но с помощью Entities (JPA) это сработало. Было ясно ...

0

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

Такие ситуации могут наблюдаться, например, при попытке заполнить теги Spring MVC или аналогичные конструкции других компонентов GUI.

Кроме того, DTO являются очень хорошим местом для размещения дополнительных аннотаций, таких как аннотации валидации или JAXB и т. Д.

1

У меня есть несколько проблем против использования сущностей на уровне представления:

  • Lock-in: This eventually creates tight lock-in between your presentation and model. It becomes expensive to change either, in large projects, even impossible. Modern tools are not quite there yet.

  • Security: With model objects you easily transfer various database id information to your web pages. This is a clear security issue. Using dto:s you may hide these at the server with very simple session maps.

  • Difference of needs: GUI views are rarely direct lists of model objects. More often they are something more, combined beasts, guish. The needs of the GUI tend to creep-in to your model obscuring it.

  • Speed: With entities, every field is processed every time you read/write them. Since you are passing them directly to presentation layer you have a hard time trying to optimize your JPA -queries - almost impossible. I'm definitely going back to direct JDBC -access - like myBatis in future projects. Thus eliminating ORM.

У меня есть проблемы противDTO:s тоже:

  • Extra DAO code.

Рассмотрено, я проголосую за использованиеdto:s для всех проектов, исключаяJPA тоже. Итак, мой стек становится примерно таким:

  • myBatis for database access
  • POJO as DTO:s
  • Stateless EJB for my DAO services.
  • StatefulEJB for GUI backend.
  • JSF for presentation.

Похожие вопросы