Avrom’s Java EE and Oracle ADF Blog

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 »

…well, sort of. They don’t have the title correct, and Dr. Paul Dorsey probably won’t be joining us (me, Peter Koletzke, and Duncan Mills) in this project, but you can sign up to be notified about Oracle JDeveloper Fusion Development – A Handbook for 4GL Developers on Amazon now. It’s being written against the upcoming JDeveloper/ADF 11g release.

We now return to our regularly scheduled programming.

Last week I talked about where business logic should go in an enterprise application, and voiced my firm opinion that sometimes–but not always–it belongs in the database. But if you’re using Oracle ADF, there’s a tricky point about this: ADF does not handle trigger-raised database errors especially well, so has no out-of-the-box way of nicely integrating with database validation. Even if you’re not using ADF (and, in particular, ADF BC), knowing what sort of thing is involved in getting database error messages into a user-friendly form may prove useful.

Continue Reading »

In an enterprise application, there are lots of choices about where to put business logic–validation rules, value calculation, and so on. You can put it in the database, in the server-side web application (and there, you have a decision about whether to put the code in the model or the controller), or as Javascript running on the client. Where should you choose to put your application’s business logic?

That’s a great question to ask in a bar full of developers of mixed backgrounds, if you like bar fights. SQL programmers will say you should put your business logic in database triggers, where it’s most secure and robust. Heavy-duty Javascript types will say that, at the least, business logic needs to be redundantly implemented in Javascript, to improve client interaction and reduce server round trips. And people from the Java EE community will tell you that the database is for data and that RIAs give you performance almost as good as Javascript without the security concerns, and that you should take the compromise (and the best-structured, most extensible option) and put the business logic into the middle tier.

I have my own very strong opinion on where to put business logic, but it isn’t any of the above. It’s this: It depends. Continue Reading »

Last week, I talked about the ADF Faces Rich Client components included in ADF 11g, the rich capabilities they offer, and the fact that I still don’t think they use AJAX to its full potential. I mentioned some examples of how I’d like to see these components evolve in 12g.

Of course, with JDeveloper 11g still in technical previews, JDeveloper 12g is not on the horizon yet–I don’t know if it’s even in development–so from the perspective of a developer out in the field, any discussion of how these components might be enhanced for 12g is still pretty pie-in-the-sky. What can developers do in the mean time?

Continue Reading »