De-coupled dataflow is in Java EE design pattern?

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?

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.

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 (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.