This question is actually too simplistic. Your persistence options are much richer than JDO or EJB:
Each of these options ”even serialization ”can be the right answer for a particular persistence issue. EJB is overkill for small web applications. Using EJB will kill the performance of your small application and require significant effort to get initial functionality out the door. JDBC, on the other hand, is a bad solution for a programming team with limited database programming experience or with a significant number of persistent objects to code. JDO, finally, is poorly suited to teams with little understanding of transaction management or that require massive scalability. Table 7-1 describes different problems and the persistence mechanisms best suited to them. It is definitely not comprehensive and does not address the advantages of alternative persistence systems.
Table 7-1. Sample applications and matching persistence models
The issues in Table 7-1 are just the surface issues. In short, you really need to know your problem domain and the pluses and minuses of each persistence mechanism in order to choose the best tool to support your application. One of the purposes of this book is, of course, to arm you with an understanding of the different persistence options so you can make that decision for the systems you design and build. The most fundamental distinction between the two persistence models, however, lies in the concept of transparency. In order to take advantage of EJB persistence ”whether BMP or CMP ”you must adhere to the EJB component model. Any components outside of that model cannot be made persistent. JDO, on the other hand, enables you to make any user -defined class persistent. In other words, the persistence model is transparent to the developer. Though you do not write any persistence code under EJB CMP, you are still writing your classes to adhere to the EJB CMP persistence.
|