permaculture playing cards*
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes Part 2: Entity Beans or DAO? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "Part 2: Entity Beans or DAO?" Watch "Part 2: Entity Beans or DAO?" New topic
Author

Part 2: Entity Beans or DAO?

Vlad Eroshin
Greenhorn

Joined: Mar 09, 2005
Posts: 20
Hello Gurus,

I am kinda stuck with the design of part 2. I cannot decide what to use for data access layer for the assignment. I am hezitating between the choice to go with entity beans or to use DAO with. Does SCEA Part 2 actually requires that to use Entity Beans? or can I say that I here is the Domain model for the application and I will use O/R mapping tool for example?

Please advise.

Thank you very much!

Vlad.
Albert Stubbins
Greenhorn

Joined: Mar 22, 2006
Posts: 5

No reason you can't take the non-ejb/orm approach to your persistence so long as you justify your decisions as to why that is preferable to entity ejb's in your particular situation (extensibility/flexibility might be reasons to not prefer entity ejb).

If you are using complex transactions then maybe entity CMP ejb's are a sensible option. If you do decide to use pojo/orm persistence maybe you will then maybe need to introduce Spring DI for transaction management, but if you're using an EJB container anyway why not just use entity ejb and take advantage of the features of the j2ee container?

hope that helps.


Hello there.
Vlad Eroshin
Greenhorn

Joined: Mar 09, 2005
Posts: 20
Thank you very much, Albert!
Ajith Kallambella
Sheriff

Joined: Mar 17, 2000
Posts: 5782
I beg to differ. I strongly recommend you to stick with services provided by the J2EE platform. You may use CMP Entity beans or a a BMP DAO. Even if it works, I urge you not to use Hibernate, iBatis or other O/R mapping tools. If you model a DAO, then you can still use a OR tool beneath the DAO layer, but just don't explicitly include it in your design.

If you go back and read the assignment instructions, you will notice that they make an explicit point about "J2EE based solution".

Good luck,


Open Group Certified Distinguished IT Architect. Open Group Certified Master IT Architect. Sun Certified Architect (SCEA).
Albert Stubbins
Greenhorn

Joined: Mar 22, 2006
Posts: 5

YEs but an ORM such as hibernate *does* use J2EE under the hood (ie JDBC, JTA etc) so it's really just a case of layer indirection. However if you stick with "pure J2EE' solution you can't go wrong.
Vlad Eroshin
Greenhorn

Joined: Mar 09, 2005
Posts: 20
Thank you very much guys! Yes I have also noticed that the instruction says:
"Remember the most important requirement of all: it must be J2EE".

I am reading the book "J2EE Architect handbook" by Derec C. Ashmore. He makes two separate layers - Deployment Layer and Business Logic layer. In Deployment layer he puts all the EJBs and Business Logic he implements as plain java objects. He strongly promotes the idea that Business logic must be deployment independent and selfcontained - meaning that there should not be dependencies on the JNDI lookups and other J2EE stuff in business logic layer.

Looking back on my experience from using CORBA and RMI, I agree with him that business logic should be deployment independent. And I used this approach in my design. I want to make the my business logic independent on what I will be using for persistence.

It looks like if I go with entity beans design I won't be able to accomplish such independence for business layer. Unless I come up with some wrappers to wrap all entity beans stuff.

Best regards,
Vlad
Thomas Taeger
Ranch Hand

Joined: Dec 16, 2002
Posts: 307
Hi Vlad,
in your first posting you wundered about entity EJB vs. DAO, but now I read about business logic:

Originally posted by Vlad eroshin:
He strongly promotes the idea that Business logic must be deployment independent and selfcontained - meaning that

For clustered servers you might prefere a session EJB being a pure/poor Session Facade. That is all what JNDI goes to - not much.

For doing the business logic you may choose remote Session EJBs as well (allowing for further clustering of parts of the business logic if via remote interface), or local Session EJBs, or just local POJOs, all trhee realizing the Business Tier.

This Business Tier accesses Entity EJBs and / or DAOs of the Enterprise Integration / Data Access Tier that in turn access db tables or other resources in EIS / Data Tier.

Originally posted by Vlad eroshin:
... Derec C. Ashmore. He makes two separate layers - Deployment Layer and Business Logic layer. In Deployment layer he puts all the EJBs and Business Logic he implements as plain java objects.

Is he talking about tiers or about layers? In Suns three dimensional cube tiers are vertical (Client, Presentation, Business, Data Access, Data Tier) and layers are horizontal like transport layer.

In my world his Deployment layer would just be the Session Facade EJB mentioned above for Business Tier, right?

And for Data Access Tier there would be a Deployment layer only if using EJBs, not for DAOs?

How Deployment layer is defined? That what we need a deployment descriptor for?

Thomas


www.classic-and-class.com - www.evalulearn.com
Interfaces are the glue of OO.
 
Don't get me started about those stupid light bulbs.
 
subject: Part 2: Entity Beans or DAO?