Java EE 设计模式中是否存在解耦数据流？
我正在从事的项目之一具有这种设计模式，一个bean由jsp/action/service类定义和使用，即由表示层和业务逻辑层使用，而另一个bean由jsp/action/service类定义和使用DAO层，称为“实体”，无论这两个bean的内容实际上是相同的，我被告知通过使用两个bean是Java EE设计模式所要求的，以解耦各个层。我对解耦的理解是通过类的工作流以及类层次结构来实现的，但是对于数据流来说，使用相同的bean是直接和平滑的，并且为DAO层引入POJO的原因之一是确保这一转变顺利进行。请分享您的专业知识，了解通过解耦此数据流可以获得的好处以及在数据流中使用相同 bean 会带来哪些缺点？
One of project that I am working on having this kind of designed pattern, one bean is defined and used by jsp/action/service classes, that is, used by presentation and business logic layer, while there is another bean is defined and used by DAO layer, called "entity", regardless of the content of these two bean are virtually same, I am told by using two beans is required by Java EE design pattern, to decouple each layers. What I understand about de-couple is implemented by the work-flow of classes as well as class hierarchy, but for data-flow, using same bean is straight-forward and smooth, and one of the reason introduce POJO for DAO layer is to assure this transformation is smooth. Please share your expertise about that are benefit will gain by de-couple this data-flow and what drawbacks will have by using same bean in dataflow?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
那些告诉您“Java EE 设计模式需要使用两个 bean”的人是错误的。如果你愿意的话就可以，有些人一直热衷于这样做，但从来没有被要求这样做。
（他们可能正在考虑 EJB3 之前的实体 bean，它无法暴露给表示层，因此需要某种到 DTO 的映射。但是现在这已经过时了很长一段时间。即使在当时避免使用实体 bean 并使用 JDBC 是很常见的。）
这是一篇文章我喜欢在分层应用程序中使用 DTO。
我和那些强烈支持在表示层使用单独的 bean 的人交谈过，支持将实体映射到单独的表示层 bean 的最大问题是持久对象他们的方法在调用时会导致数据存储发生更改，并且他们需要保证无法从表示层调用这些方法。对我来说，这意味着他们错过了使用 POJO 进行持久化的要点，即它们可以包含业务逻辑（即改变对象图状态的方法），但它们对基础设施没有任何依赖性。 Gavin King 和他的公司遇到了很多麻烦，所以他们不必在持久性实体上放置保存方法，然后他们在持久性实体上放置保存方法，这样做需要大量的工作来确保没有人滥用本来不应该存在的方法。
The guys who told you "using two beans is required by Java EE design pattern" are wrong. You can if you want to, some people are fanatical about doing it that way all the time, but it has never been required.
(It might have been they were thinking of pre-EJB3 entity beans, which could not be exposed to the presentation layer so some kind of mapping to a DTO was required. But that has been obsolete for a long time now. Even at the time avoiding entity beans and using JDBC was common.)
Here's an article I like on using DTOs in layered applications.
I've talked to people who strongly favored using a separate bean for the presentation layer, the biggest concern in favor of mapping entities to separate presentation-layer beans was that the persistent objects had methods on them that when called caused changes to the datastore, and they needed to guarantee that those methods couldn't be called from the presentation layer. To me that means they missed the point of using POJOs for persistence, which is that they can encompass business logic (that is, methods changing the state of the object graph) but they don't have any dependencies on the infrastructure. Gavin King and company went to a lot of trouble so they wouldn't have to put a save method on their persistent entities, and there they go putting a save method on their persistent entities, in doing so necessitating a ton of work to make sure nobody misuses the methods that shouldn't have been there in the first place.
仅仅因为它很流行或符合任何要求就使用你不需要的东西并没有什么意义，但拥有它的未来证明可能是值得的。
您实际上拥有的是域模型（非实体 bean）和实体。当您处理复杂的领域逻辑时，这是必须的，而不是将逻辑放入实体中，而是将其放入领域逻辑 POJO 中，或者当您的数据相当复杂并且实际上无法将 DM bean 直接映射到对于数据库，您需要多个实体来执行此操作。域模型还有助于继承。
现在，如果您的 bean 完全相同，那么您要么有一个非常简单的模型，要么没有正确使用域模型，请选择您的选择，您知道您在那里得到了什么。
您应该查看域模型“模式”，例如经典著作中的第 9 章《企业应用架构模式》
It doesn't really make sense to use something you don't need just because it's trendy or conforms to whatever, but having it future proof might be worth the trouble.
What you actually have over there is a Domain Model (the non-entity beans) and entities. This is a must have when you deal with a complex Domain Logic, instead of putting the logic inside the entities, you put it inside the Domain Logic POJOs or when your data is rather complex and you can't actually map a DM bean directly to the database, you need multiple entities for doing that. A Domain Model also helps with inheritance.
Now, if your beans are exactly the same, you either have a very simple model or you don't use the Domain Model properly, take your pick, you know what you've got over there.
You should have a look at the Domain Model "pattern", for instance under Chapter 9 in the classic "Patterns of Enterprise Application Architecture"
Java EE（现在不是 J2EE）建议使用 JPA 进行数据访问（替换实体 Bean），将 JPA 层包装在会话 EJB Facade 后面。我认为您的问题相当于决定该 Facade 中使用的类型，传入的 DTO然后出去。这些 DTO 可以是 JPA beans 还是我们应该使用单独的类？
JPA bean 只是带注释的 POJO，因此它们可以合理地传递到 JSP/Servlet 层。在简单的情况下，这就是我所看到的情况。随着业务逻辑变得更加有趣，我注意到有时我们需要更多以业务为中心的对象作为 DTO，所以是的，我会分离对象。
我的建议：根据对调用者有意义的方式设计会话 Bean Facade，如果发现 JPA 对象可以工作，则使用它们。
Java EE (not J2EE these days) would suggest using JPA for data access (replacing Entity Beans) wrapping the JPA layer behibd a Session EJB Facade.I think your question amounts to a decision about the types uses in that facade, the DTOs passed in and out. Could those DTOs be JPA beans or should we use separate class?
JPA beans are just annotated POJOs and hence they can reasonably be passed up to a JSP/Servlet layer. In simple cases that's what I see happening. As the business logic becomes more interesting I'm noticing that sometimes we need more business focused objects as the DTOs, and so then yes I do you separate objects.
My advice: design the Session Bean Facade in terms of what makes sense to the caller, if it transpires that the JPA objects work, then use them.