It's largely a matter of preference. CMP's require less coding, and thus less debugging, but they are limited in what you can supply as far a selection criteria. BMP's allow you to do things like post-SQL filtering and creating finders which return ordered enumerations of beans. On the downside for BMP's, you're coding raw SQL directly into the bean code, and that makes the program code more or less dependent on what brand of DBMS you're using. I understand that no few people are prefer to work exclusively with BMP's. I usually do CMP unless I know I need the extra power. Since the client can't tell which I'm using, if it turns out I'm wrong, all I have to do is refactor the bean.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Jul 27, 2001
Thnx Tim. But is there any design issue like for a single functionality, can mix CMP & BMP beans. Or will there be any transcation related problem if within a transactional context, two setter methods of separate CMP & BMP beans are called? Can we use declarative transaction attribute or isolation level in case of BMP just like CMP?
From a client side, you should be able to use them interchangably. If you're referring to a situation where different types of beans are representing the same items in a table, you shouldn't depend on the EJB server to maintain database integrity - it only guarantees interactions between the beans themselves - EJBs actually aren't required to even USE a DBMS for their persistent store. I've learned to my great pain that it's never good to have more than one path to update anything - it can be extremely frustrating when you have to figure out which one's clobbering info (or worse, when they interact in unforseen ways). For that reason, I try to delegate to a common object.