Hi, We are in the process of creating am online shopping cart, but busy with the first module.. catalog. We have indentified almost 15 tables for this.. like product- prodcat- store- store_types.. The requirement is a bit complex like, the site can have different store, and the product price may vary depending on the store/region etc.
Now my question is, what's the best way to implement this on a J2EE scenario ??. If we use CMP, I think I will end up creating an entity bean for each table.. of course I will be using composite entity. The other limitation in using CMP is, I won't be able to use DAO. OR should I design the system to use both CMP+VO and BMP+DAO+VO ???. Is it ideal to use both ??.
I am planning to follow the various J2EE design patterns acc to the requirement.
Use a proprietory third party ORM technology, or good old fashioned straight JDBC. Sorry my comment was a little flippant - but have a read around and you'll discover the real down side of Entity Beans.
I would use CMP, taking advantage of Xdoclet code generaton. Better still try the Eclipse with Lomboz.
You have said "The other limitation in using CMP is, I won't be able to use DAO." - however if you look at the Value List Handler pattern taken from Core J2EE patterns (Core J2EE Patterns: Best Practices and Design Strategies ), you will find that they recomend that for a search that may return a large result set, we have a value list handler that makes use of a DAO. The main reson for this is performance, as entity beans can have a huge performance overhead.
As Paul said, I have looked at other third party ORM technology like hibernate ..
But I am still confused with when to use hibernate and when to use Enterprise beans. You mentioned that there are down sides in entity beans. But what about hibernate, do you think we can get all the functionality of entity beans (deployed in a J2EE container) in hibernate. What about container managed persistence, CMT, Security etc ???.
Hello, I think i am joining this discussion a little late. In this case i would not go for entity beans . I say BMP+VO+DAO will be a better approach than entity beans. Regarding hibernate somehow i feel that you won't get the freedom that one can have with DAO's VO's etc.
Sawan<br />SCJP,SCWCD,SCBCD<br /> <br />Every exit is an entry somewhere.
But I am still confused with when to use hibernate and when to use Enterprise beans
They are interchangable technologies - both being persistance layers.
You are right to be sceptical of sawan parihar's post - it doesn't make any sense (sorry sawan parihar, unless you can justify what you say?).
Why not use Entity Beans? Well, this is all well documented, but I'll summarize it here:
Entity Beans are not portable, despite claims to the contrary. They always require platform specific configuration, some thing Hibernate doesn't.
EJB-QL is a subset of SQL, and restrictive as a result. HQL: on the other hand is as rich, and Hibernate allows direct SQL if you find a case where you absolutely need it.
Entity Beans come with a lot of baggage - you mention CMT and Security. Why are these a requirement of the persistance layer when it is already provided by Session Beans?
You need SessionBeans to access EntityBeans. The same is not true about Hibernate (which doesn't need a container at all)
Entity Beans force the use of DTOs (or something simmilar) since you can't pass an Entity Bean to a client. You can pass POJOs.
Entity Beans work well enough for CRUD operations, but badly for large reads (which tend to be the norm in web applications).
There's more but that should be enough to make my point. BMP is not a tennable technology unless you have very specialist requirements. If CMP is the technology you know, then there is perhaps a case for using it. But I'd seriously consider another ORM route.
(BTW: If you check other posts I've made you may notice that I am an unappologetic fan of Hibernate - so some people may disagree with some of the downsides I list.)