why BMP
I see the following reasons for using BMP over CMP:
1.Accessing legacy systems and non RDBMS data source.
2.For managing complex relationship.
3.When u r not sure that the CMP code is optimized and would like to use stored procedures for database access with an intent of improving performance.
4.When entity data is found in many databases.
The point # 2 mentioned is no longer valid with the coming up of EJB 2.0 which manages relations.
Any more reasons for using BMP ?
Thanks in advance.
[547 byte] By [
mpbhat] at [2007-9-19]
Greetings,
> I see the following reasons for using BMP over CMP:
> 1.Accessing legacy systems and non RDBMS data source.
Or simply, any non-RDBMS data source.
> 2.For managing complex relationship.
> 3.When u r not sure that the CMP code is optimized and
> would like to use stored procedures for database
> access with an intent of improving performance.
True, though not very portable. In any event, CMP can also make use of stored procedures where out-parameters are not needed. Also, Sun promotes "resource optimization" as a selling point for CMP, ie.: "the vendor may know better than the Bean Provider how to optimize queries to the resources it explicitly supports". :-p Though, in this regard, I still tend to trust my own code better than the vendors. :) Furthermore, CMP alleviates most of the burden of O/R mapping on the Bean Provider by transferring it to the Deployer role. So another question one may find him/herself asking is how much can the Deployer be trusted to effectively manage the mapping? It makes for a possible extension of the "platform gets blamed for coder's lack of skill" syndrome. Another consideration is optimizing bean->resource syncs. In BMP one can use a 'dirty flag' to optimize UPDATEs; in CMP one must rely on the vendor doing so and - with a closed source server, at least - there's little way to know. In such cases, BMP may still the preferred way to go...
> 4.When entity data is found in many databases.
Unless it absolutely must be mapped into a single bean, (EJB 2.0) CMP/CMR can support this too - albeit, not very "efficiently". ':)
> The point # 2 mentioned is no longer valid with the
> coming up of EJB 2.0 which manages relations.
Mostly. EJB 2.0 (CMR) manages relationships between beans, not between the actual entities which still maps 1:1 to the beans. We can say that by extension CMR also manages relationships between the entities. However, the spec only partially provides for CMR-level reflection of resource level handling of foreign keys - IGNORE and CASCADE ON DELETE. (Of course, I should remember my own arguments in support of '1' above.and point out that Entity Beans are not strictly for RDBMSes where such handling originated and is most common... :) If other handling is needed (eg. NULL ON DELETE) then BMP and/or business-level logic must be used.
> Any more reasons for using BMP ?
How about reuse and portability beyond EJB? In BMP one can (should) use a DAO to sync with the resource. A well written DAO, in conjunction with a Business Delegate, can be easily used in scenarios where an EJB container is either not available or not practical. ;)
> Thanks in advance.
Regards,
Tony "Vee Schade" Cook
