> * Many people seem to agree on the inefficiency of entity > beans, specially for massive operations. It looks as if > CMP beans (i.e., those where the OR mapping is automatically > handled) are specially non-performant. Now, say you decide
It really depends on the vendor. They don't have to be slower than any other O/R mapping solution, other than the overhead imposed by being cluster safe and such. Most of the claims about the performance of entity beans are comparing them to hand tuned SQL for data manipulation, where any solution that abstracts the SQL is going to be slower. At least in the case of EJB you can scale to more machines, which is not an option for many O/R mappers (Torque falls into this category right now, OJB is the only free offering I know of that offers clustering). With 2.0 EJB may not be as slow as you think. If performance were the only concern I'd probably be using it myself! However in my current project we have actually abandoned EJB because of the complexity in development, deployment, and maintenance. We decided (after dealing with EJB on our last project) that it took too long to develop for too little benefit. The fact that it is vastly faster (JCS helps a lot here) is only a bonus. But this wasn't really meant to be about EJB... =] > to only use Entity beans when necessary, and then, only > BMP beans (where you manually write the OR mapping). Could > torque generated classes be used for this part of a BMP bean? > Even more, could Torque generate the whole Bean class? Sure, a lot of people use an O/R mapper when implementing BMP, there is no reason why torque couldn't be adapted to this situation, or even be made to generate BMP classes. In practice I expect you would find this not to be faster than CMP. EJB has come a long way and there are now CMP 2.0 solutions which are quite fast since the are optimized for the EJB use case. > * There are several interfaces and/or classes (at least 3) to > be more or less hand-written when creating an EJB. Some of > the methods for these classes could be automatically generated > from a higher level bean description (I guess this is what > some of those fancy IDEs do). Has anybody thought about using > Torque (Texen?) to generate these classes? The nice thing > about such a tool is that you might be able to define a more > sophisticated set of classes implementing an EJB (say, because > you create a factory, and use a base class for BMP and CMP, > or whatever); the tool could adjust to your needs simply > by providing it with different Velocity templates, right? Sure, but there are already some good solutions for this problem. Particularly on the doclet front -- XDoclet / EJBDoclet are really nice offerings which allow you to write all types of EJBs with one class per bean. That said, you could certainly get more flexibility using a velocity + code generation approach if there were a need, but I suspect that the doclet solution is flexible enough for most people's needs. YMMV of course, I'm by no means an EJB or O/R mapping expert. That and I neither use Torque nor pay close attention to it. -- jt -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
