Расцепленный поток данных находится в шаблоне проектирования Java EE?

Question

Один из проектов, над которым я работаю, имеет такой тип разработанного шаблона, один bean-компонент определяется и используется классами jsp / action / service, то есть используется на уровне представления и бизнес-логики, в то время как существует другой bean-компоненти используется уровнем DAO, называемым «сущностью», независимо от того, что содержимое этих двух компонентов практически одинаково, как мне сказали, использование двух компонентов требуется для шаблона проектирования Java EE для разделения каждого уровня.То, что я понимаю о расщеплении, реализуется рабочим потоком классов, а также иерархией классов, но для потока данных использование одного и того же компонента является простым и плавным, и одна из причин введения POJO для уровня DAO состоит в том, чтобыубедитесь, что это преобразование является гладким.Пожалуйста, поделитесь своими знаниями о том, какие выгоды вы получите от разделения этого потока данных и какие недостатки будут иметь использование одного и того же компонента в потоке данных?

Answer 1

Парни, которые сказали вам, что "использование двух bean-компонентов требуется для шаблона проектирования Java EE", ошибаются.Вы можете, если хотите, некоторые люди все время фанатично относятся к этому, но это никогда не было обязательным .

(Возможно, они думали о бинах сущностей до EJB3, которые не могли быть представлены на уровне представления, поэтому требовалось какое-то отображение на DTO. Но это давно устарелоТеперь. Даже в то время, когда избегали объектных компонентов и использовали JDBC, это было обычным делом.)

Вот статья, которая мне нравится по использованию DTO в многоуровневых приложениях.

Я говорилдля людей, которые решительно выступали за использование отдельного bean-компонента для уровня представления, наибольшую обеспокоенность в отношении отображения сущностей на отдельные bean-элементы уровня представления было то, что постоянные объекты имели методы, которые при вызове вызывали изменения в хранилище данных, и им нужно былогарантировать, что эти методы не могут быть вызваны из уровня представления.Для меня это означает, что они упустили смысл использования POJO для постоянства, то есть они могут охватывать бизнес-логику (то есть методы, изменяющие состояние графа объектов), но они не имеют никаких зависимостей отинфраструктура.Гэвин Кинг и компания столкнулись с большими трудностями, чтобы им не пришлось применять метод сохранения к своим постоянным объектам, и там они применяют метод сохранения к своим постоянным объектам, для этого требуется куча работы, чтобы убедиться, чтоникто не злоупотребляет методами, которых там не должно было быть.

Answer 2

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

То, что у вас есть на самом деле тамэто модель предметной области (бины не-сущности) и сущности.Это необходимо иметь, когда вы имеете дело со сложной доменной логикой, вместо того, чтобы помещать логику в сущности, вы помещаете ее в POJO доменной логики или когда ваши данные довольно сложны, и вы не можете фактически отобразить бин DM непосредственно набаза данных, вам нужно несколько объектов для этого.Модель предметной области также помогает с наследованием.

Теперь, если ваши компоненты точно такие же, у вас либо очень простая модель, либо вы не используете модель домена должным образом, сделайте выбор, вы знаете, что вам нужно.Вы попали туда.

Вы должны взглянуть на "шаблон" модели домена , например, в главе 9 в классической "Модели архитектуры корпоративных приложений"

Answer 3

Java EE (не J2EE в наши дни) предложит использовать JPA для доступа к данным (заменив Entity Beans), заключая в себе слой JPA, запрещающий фасад Session EJB. DTO проходили и выходили. Могут ли эти DTO быть компонентами JPA или мы должны использовать отдельный класс?

Бины JPA являются просто аннотированными POJO и, следовательно, их можно разумно передавать на уровень JSP / Servlet. В простых случаях это то, что я вижу, происходит. Поскольку бизнес-логика становится все более интересной, я замечаю, что иногда нам нужно больше бизнес-ориентированных объектов, таких как DTO, и тогда да, я делаю вам отдельные объекты.

Мой совет: спроектируйте Session Bean Facade с точки зрения того, что имеет смысл для вызывающей стороны, если выяснится, что объекты JPA работают, то используйте их.