• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Part 2: Entity Beans or DAO?

 
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Greenhorn
Posts: 5
PHP Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Vlad Eroshin
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you very much, Albert!
 
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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,
 
Albert Stubbins
Greenhorn
Posts: 5
PHP Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 20
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Why am I so drawn to cherry pie? I can't seem to stop. Save me tiny ad!
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic