Hi, i've been reading about persistence patterns for the last weeks. Actually got ALL kind of opinions (from books, articles and forums), they differ in each aspect...! I also took a look at a recent topic posted on this forum about "Entity Bean Vs. DAO" wich pointed some advantages on using JDO, Hibernate, etc... ( this is already clear for me!). Then i posted the following question on another forum (cause i really wanna have a big set of options). That it is, "Suppose i want to build my app with pure CMPs ( i don't want JDO, stored procedures or O/R mappers). Is a one-to-one mapping to my relational model the best option? I've heard (also read at EJB Design Patterns) not to use Composite Entity, so the only left option is a one-to-one mapping in CMPs -> Relational DB. Is that rigth?" Surprisingly, i got the following answer, "As far as i know/read, composite is more preferable than one-to-one mapping. One-to-one mapping ties you more closely to data model.In the EJB1.1 days one-to-one mapping end up in bean to bean communication which is not recommended." So, could any expert, please, give a "final veredict" on this subject? If there's no final verdecit, could some experts give me their point of view? Thanks in advance, ltcmelo
Hi Kyle, A follow-up question. Does direct mapping from cmp bean to db table mean that db tables should be denormalized? I guess I'm just wondering how this approach impacts performance and if granularity is still an issue.
"I believe in coyotes and time as an abstract Explain the change the difference between What you want and what you need there's the key"
Originally posted by Jason Stull: Does direct mapping from cmp bean to db table mean that db tables should be denormalized? I guess I'm just wondering how this approach impacts performance and if granularity is still an issue.
If you go with CMP, you're fairly limited in your options. While many containers provide the ability to map an entity bean to multiple tables (e.g. if you have a Person with a 1:1 with Address), but that ties you to the container. As well, opportunities for this tend to be limited (e.g. we store multiple Addresses per Person, so we have to use two entity beans). The real issue with entity beans is that if you design your system following the usual tried-and-true patterns, you'll front them with session beans. Those session beans will check security and manage transactions. Yet every call to an entity bean will *also* check security and manage transactions. This is wasted effort, and in the end the only benefit derived from using entity beans is that CMP is easy. Of course, Hibernate is easy, too, and it doesn't carry the excess baggage. That being said, I recommend modeling your DB as appropriate for the DB. Normalize as you would normally, and map the entity beans one per table. This allows you to model the entity bean relationships appropriately.
Joined: Feb 02, 2004
As long as we are hacking on cmp entity beans. One thing I hate about them is the total lack of flexibility. We have some pretty complex entities and some fairly complicated searches to go along with them. I think that EJBQL still doesn't have enough features. At one time we did do direct mapping of CMP EJBs to db tables. This scheme was dog-slow. And try as hard as we could, we never beat the performance of SessionBean + BMP EJBs + DAO. I'm studying for the SCEA right now, and all the study materials I've come across basically delegate CMP EJBs to cases where, "Data is not complex and performance is not critical".