Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
BMP versus CMP
The choice of BMP versus CMP can lead to quite a heated philosophical debate; the issues revolve around performance, flexibility, database independence, application server independence, maintainability, and convenience.
Performance
Entity bean performance is a battle between the bean programmer and the EJB container programmer. In a well-written application server, the data persistence should not be much of an issue to the bean developer, but a clever bean developer can still squeeze in a couple of optimizations. In a mediocre to poorly written application server, however, the performance can quickly degrade to a below-acceptable level if left to the container. The bottom line is that if your beans can be deployed in any application server, and you know what you are doing with JDBC and EJB (a very big concern!), BMP should always win out over CMP in performance.
Flexibility
Bean-managed beans also offer greater flexibility with respect to the type of data they are representing. The data comprising an entity bean need not be from a single table or a single database, or even from any database, for that matter. When you are in charge of managing the persistence of your data, you are at complete liberty to do anything you want when the EJB container notifies you; this also provides you with the ability to offer an EJB front-end to an existing legacy system. Sometimes, the nature of your database schema does not mix well with the object-oriented representation that you are trying to develop, leaving you with no choice other than to use BMP.
Application Server Independence
BMP beans, to some degree, are more application server-independent; they are more dependent on the database schema, as I will discuss. Once the database schema is in place, however, BMP beans are easier to move around to different application servers. The primary reasons for that are the application server-specific deployment options; in EJB 1.1 each application server has its own proprietary method for implementing custom finders (the findByXXX() methods). If you write the SQL statement itself, you can alleviate the difficulty of learning the nuances of each application server (note that the EJB 2.0 specification addresses this limitation through the new EJB QL.) Furthermore, you do not need to use a proprietary object-mapping tool to map your bean's fields to database columns.
Maintainability
Bean-managed beans have their downside too: maintainability and convenience. BMP beans are tied very closely to a database schema (the code to access specific tables and column names is hard-coded in the bean itself.) CMP beans can be configured at deployment time; a bean can be mapped to a specific table and its fields to that table's columns. A change in the database schema does not necessarily equate to a change in the bean; a smart object-mapping tool can hide some of the changes, but a major overhaul will affect the bean code, regardless.
Convenience
Finally, a CMP bean is just easier to write! The bean developer is not responsible for all the persistence code that will always look the same anyway, if the bean is simple. This leads to higher productivity and quicker time to market. Furthermore, CMP is more robust in the EJB 2.0 specification, and Sun recommends using CMP over BMP whereever possible (but more on 2.0 CMP in a later article), so start getting used to it now.