Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Part II - Composite Entity Beans

 
Luciano Queiroz
Ranch Hand
Posts: 172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
About composite entity beans:

I have opted to use BMP + DAO.
So, my doubt is: do I have to create an BMP + DAO + VO for each entity?
I was thinking to apply the composite entity pattern.
For example, there are 3 entities: Customer, Address and CreditCard.
Do I have to define a BMP for all these 3?

I decided to define a BMP only for Customer.
Because I'll never directly access Address nor CreditCard. I'll always access Address and CreditCard through Customer.
So, if I have a single CustomerBMP communicating with AddressDAO and CreditCardDAO isn't it enough?
Then, CustomerBMP can receive and return AddressVO and CreditCardVO whenever a customer needs to read/update his address or credit card. I implement get/set methods in CustomerBMP that use all these 3 VOs and DAOs.

What do you think about this?
 
Ajith Kallambella
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Right thinking! Bravo!!

One {DAO,VO,BMP} set for every object in your system will kill the performance. Not to mention maintenance nightmares. A good rule of thumb to consolidate dependent objects is to analyze the collaborations. If a business entity only exists within the context of another entity( Address and Customer ), it is a wasteful excercise to model it as a stand-alone entity.

I recommend modelling business methods on the BMP that manipulates underlying dependent objects. For instance the method addCreditCard() on Customer interacts with creditCardDAO to perform the modifications. I have heard argument against composite entity beans and modelling all dependent objects as local entity EJBs - aka CompositeEntityBean using Local EJBs. In my opinion, local or not, EJBs cannot be as lightweight as POJOs.

Lastly, your design strategy should accommodate easily EJB-izing these dependent objects if necessary. Hint - interfaces
 
V. Sharma
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Folks.
Just making this thread alive again.

Is it still a valid option to go for Composite pattern after EJB 2.0.Since in my opinion Composite pattern is of good use most when we are using BMP. Which could have been a good solution with EJB 1.1

Doubts:

1) Can I assume in my assumptions that I am designing with EJB 1.2
2) If yes has anybody seen any solution where Composite entity pattern was used with CMP.


Thanks
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic