There's been a certain amount of noise recently surrounding simple JDBC frameworks
like iBATIS. I've liked the idea of iBATIS myself, for use in applications which
don't need an object-oriented domain model, and don't work with deep graphs of
associated entities in a single transaction. A JDBC framework also makes good sense
if you are working with some kind of insane legacy database; ORM solutions tend
to assume that associations are represented as nice clean foreign keys with proper
referential integrity constraints (Hibernate3 much less so than Hibernate 2.x).
Just had an interesting discussion on firstname.lastname@example.org, started by David Cherryhomes, which saw me stupidly insistingthat something can't be done when in fact, now that I think about it, /I realize I've actually done it before/, and that even the Hibernate AdminApp example uses this pattern!
Another major change in Hibernate3 is the evolution to use an event and listener
paradigm as its core processing model. This allows very fine-grained hooks into
Hibernate internal processing in response to external, application initiated
requests. It even allows customization or complete over-riding of how Hibernate
reacts to these requests. It really serves as an expansion of what Hibernate
tried to acheive though the earlier Interceptor, Lifecycle, and Validatable
Hibernate3 adds the ability to pre-define filter criteria and attach those filters at both a class and a collection level. What's a pre-defined filter criteria? Well, it's the ability to define a limit clause very similiar to the existing where attribute available on the class and various collection elements. Except these filter conditions can be parameterized! The application can then make the decision at runtime whether given filters should be enabled and what their parameter values should be.
I just cleaned up some of my files and found this snapshot in one of my folders. I made it two weeks ago, as I finally had time to install Oracle 10g. I remember how I was shaking my head in desperation as I realized what they had done. Let me explain.
This item is a prediction about the future. Predicting the future is a dangerous business, and exposes the author to ridicule in both the future and present. Nevertheless, articulating a /nice/ vision of the future can help bring about that future.
Now that the EJB 3.0 early draft is
it's definitely time to move on from all the recent politics, and start
thinking about what we can actually /do/ with this stuff. EJB is the only Java
standard which addresses server-side /business logic/, and is thus central
to J2EE. The EJB spec committee recognizes that EJB has fallen short of achieving
some of its ambitious goals, and is in need of an overhaul. This overhaul
has focused very much upon ease of use, primarily via simplification of the
requirements upon bean implementors. However, the spec committe also identified
a number of critical functional enhancements that facilitate ease of use and
the elimination of certain J2EE anti-patterns.
Another blogger, who will remain unmentionable, is upset that some of the guys at JBoss are beginning to throw the term AO around. According to him, the AOP community is just terribly attached to their P, and quite concerned that JBoss might be about to dominate the world with their P-less aspects.