> From: The elephantwalker [mailto:[EMAIL PROTECTED]] > > You will find that if you want the _enterprise_ features offered by cmp > with > straight jdbc calls, your classes for jdbc calls will be slower than cmp, > and _much more_ difficult to develop. > > I am not a smarter developer than Karl or Magnus. Their algorithms for > caching, transaction management, pooling (connection, threads, objects, > you > name it), are among the best in the business. If I were to _attempt_ to > reproduce these features, I would certainly _fail_ to reproduce these > features in a reasonable time.
Eh? Connection pooling and transaction management are provided to session beans through the data source. No CMP or entity beans necessary. Furthermore, if you want sane transaction demarcation, you already have to wrap all your entity bean access in session bean methods. Entity bean caching I have found to be remarkably useless. First of all, it depends on a pessimistic locking strategy, which is both hard to use (gotta love those deadlock exceptions!) and not applicable to a clustered environment or any environment in which the database table can be modified from an external source. Furthermore, finder methods are not cached - and with an eager loading strategy, I really have to wonder what the great advantage of the caching is... bringing all the bean data back usually isn't that much more expensive than bringing just the PK data back, and if it is (because of large data fields) then your cache is going to have size problems anyways. Irrespective of who may be a smarter developer, I can guarantee you that I know a *lot* more about *my* specific business logic than Karl or Magnus. Furthermore, Karl and Magnus are for the most part just implementing a specification produced by a committee of labcoats dedicated to a lowest-common-denominator set of features that IBM, BEA, Borland, Sybase, & the rest of the implementers can agree to. The absence of ORDER BY in EJB-QL and the lack of a standard PK generation mechanism make me seriously wonder if any of the people writing the EJB spec have ever used it to implement a real-world application. > There will always be a place for jdbc in an enterprise application. But in > an enterprise application where the transaction is as important as the > data, > and the data structure itself may change from time to time, cmp ejbs are > the > way to go. Entity beans can be useful for modeling your data. For some business cases, they might actually be all you need. I, however, have yet to see one of those cases in the real world. I will reiterate the three failings I mentioned before: you cannot model relationship attributes, you cannot perform aggregation queries, and you cannot query for data that spans multiple objects. I'll add that if you're restricting yourself to EJB-QL, you're going to have even bigger problems, like the inability to order the result set without sorting yourself in Java. Relational databases have evolved over the last thirty years to provide us with a very refined solution for storing and accessing enterprise data. Entity beans are a big square peg that can only be brutally forced into the multifaceted hole that is our problem space. > A resultset relies on datastructure strings, and are closely coupled with > the underlying database structure. All my experience indicates that the > datastructure will change many times during a project, after the project > is > finished, and before the application is retired. > > jdbc is tightly linked with the datastructure. This link goes to a low > level, as many text strings need to be modified when the datastructure > changes. Arrrrrgh! Don't get caught in the performance trap where you > application performance increases by 2%, but its almost impossible to > change > your application without competely rewriting it. If the primary argument for using entity beans is that they offer a layer of indirection so that you can rename columns, there are plenty of alternative approaches which are *much* simpler. I'm not saying don't use entity beans (although I would *definitely* recommend that a team which does not already have a lot of EJB expertise should avoid them), but I am saying that it is a huge mistake to consider entity beans your only means of data access. To use the square peg analogy again, reduce the size of the square to something that fits smoothly through the hole, and fill in around the edges with other mechanisms (like JDBC). Jeff Schnitzer [EMAIL PROTECTED] Consulting & Contracting - J2EE, WebLogic, Orion/OC4J
