This is an (obviously) late post in a series of posts about ODTUG Kaleidoscope 2009. Monday was the least busy day for me at Kaleidoscope–I only attended two presentations, “That’s Rich! Putting a smile on ADF Faces,” by Lucas Jellema, and “Fusion Design Fundamentals,” by Duncan Mills. But it was perhaps the most thought-provoking of my days there. In fact, I have a full three posts worth of stuff to say about just these two talks. Today, I’m going to talk about a dramatic contrast: the two talks, among other things, represented opposite ends of a debate I consider quite important: the advisability, or lack thereof, of using ADF Faces RC client-side components.
This week’s post will be the first of a five-week series about an important but little-discussed topic: Tuning your business components for maximum performance. A lot of projects put very little effort towards business components tuning (usually nothing more than improving the SQL of expert-mode VOs), and because of this, a lot of developers new to the framework come away with the (false) impression that business components perform poorly. Business components actually perform quite well, so long as they’re properly tuned.
This week, I’m going to talk about tuning entity objects. Over the next weeks, I’ll cover associations, view objects, view links, and application modules.
Last week, I introduced the ADF development methodology I’m proposing, “Extreme Reusability,” articulated its goals, and discussed the techniques of “Generalize, Push up, and Customize” and “Think Globally, Deploy Locally” that are critical to the methodology. I didn’t, however, describe the actual…well, methodology, meaning the development cycle prescribed by Extreme Reusability.
Notice I didn’t say the application development lifecycle. That’s because developing under Extreme Reusability, like developing under SOA, isn’t primarily about the creation of standalone applications. You should think of the development cycle for extreme reusability as part of an enterprise-wide effort.
Development under Extreme Reusability involves developing along three separate but interacting (and communicating–communication is absolutely vital under this system) tracks: framework development, service development, and application development. These tracks are assigned to different individuals on the team, in (at a guess–remember this is a proposed methodology) somewhere around a 20-60-20 division for a typical organization’s needs.
Last week, I talked about how to code database error messages, entity object classes, and custom exceptions to facilitate integration of database-level validation logic into an ADF application. And I promised that this week, we’d finish off the project by writing the controller-layer code that will turn these custom exceptions into nice, user-friendly error messages, right? Well, I’m not going to do that, because I actually forgot something at the ADF Business Components (ADF BC) layer. Controller stuff next week. I really promise this time.
Continue reading Business Components Without the Business: Part II