It’s done! After much tinkering, I’ve completed my new Framework for Database API-Based Business Components. This is, in some loose sense, based on the Framework for Package API-based business components I published on this site previously, but it’s essentially a complete rewrite, from the ground up. It’s also massively improved, in several ways:
- Locking (both pessimistic and optimistic) actually work.
- With few exceptions, the new framework limits itself to writing JDBC calls and translating columns to attributes, meaning that it takes full advantage of standard ADF mechanisms for caching, tuning, etc. For example, the framework now respects view object tuning settings such as fetch size.
- In part because of this, applications written using the new framework should perform considerably better than those using the old one.
- The framework should be much easier to extend. For example, by providing an implementation of one interface and a concrete subclass of one abstract class, you should be able to extend the framework to support databases other than the Oracle DB, using procedural languages other than PL/SQL.
- The framework is now part of a formal project, with bug/enhancement tracking and ways for the community to participate.
If you’re interested in using the framework, examining its source code, and/or contributing to its ongoing development, check it out at the project’s home page.
Edit: When I first posted this, I said the new framework didn’t have any documentation other than the Javadoc up. That’s no longer true–it has a user guide up now, too.
Wow. I’ve had some interesting first days at conferences before, but this was exceptional.
My day started out with a meeting of the ADF Enterprise Methodology Group. This was a group discussion led by a panel, consisting of Chris Muir, Simon Haslam, Andrejus Baranovskis, Steve Muench, and myself. But the great thing about this was that it actually wasn’t mostly us talking–we had truly excellent participation from the audience! I’ve blogged about the ADF EMG before, but I want to reiterate here that it’s a great group. We have pretty much daily discussions about all aspects of ADF application design and planning. If you have any interest in ADF development (and if you don’t, I’m not quite sure why you’re here), you want to join. Seriously.
Continue reading Oracle OpenWorld/Oracle Develop 2009: Day 1
In the spirit of the last post, I want to talk about another design pattern that’s useful in a wide range of Java development cases, and for which I think better tooling support (maybe in the form of a JDeveloper addin!) would be very useful: The bridge, also known as the driver. You’re probably familiar with the term “driver,” at least in the sense of device or JDBC drivers, and as we’ll see, there’s a reason why the driver pattern shares a name with them.
The stated purpose of this pattern is to “decouple an abstraction from its implementation so that the two can vary independently.” This may not make much sense at first, so we’ll start with a concrete example.
So, I’ve been doing some work on my Framework for Package API-Based ADF BC (locking doesn’t work as-is, and it turns out the framework needs some pretty significant re-architecture to get it to), and between that and my regular work, I’ve been a little ADF’ed out. So for a couple of weeks or so, I’m going to do something I haven’t done a lot of in this blog, and post a bit about pure Java. This will, hopefully, contain techniques of interest to ADF developers, and I’m probably going to use some ADF-based examples, but I’m mostly going to be talking about “Java techniques that they don’t teach you in a 5-day Java class.”
While working on the new version of the Framework, I’ve run into some significant annoyances, by which I mean the sort of coding work that a monkey–or better yet, a tool–could do but is long and fiddly to do by hand. This isn’t something that will primarily bug your average ADF developer, but it’s a sufficiently common Java technique that it would be a useful add-on for any Java IDE, JDeveloper included. It’d be a neat project for my Copious Free Time, but for now I’m just going to throw it out there in case anyone’s interested: The automatic generation of a decorator. Even if you’re not interested in that, you might want to read this article, just to get a feel for an important design pattern.
Continue reading Design Patterns and You: The Decorator
Continue reading 3000 Developers!: Kaleidoscope ’09 Report II