Business Components Without the Business: Part III

Over the last two weeks, I’ve been talking about model layer code to facilitate integration of database-level validation logic into an ADF application. This week, let’s finish off the project by writing the controller-layer code that will turn these custom exceptions into nice, user-friendly error messages. Continue reading Business Components Without the Business: Part III

Business Components Without the Business: Part II

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

My Next Book Is up on Amazon

…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.

Business Components Without the Business: Part I

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 Business Components Without the Business: Part I

The Business Logic Wars

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 The Business Logic Wars