Okay, the title is tongue and cheek and not meant to stir anyones' blood. The quality of writing a good blog is among other things attracting readership by a catchy title.
"With respect to the ADF environment...I've been to a couple of workshops and what I see missing is the discussion of the impact of the decisions you make when starting a new ADF application. I'll bet the MVC based IDE makes a whole lot of sense to a Java developer but from the Forms side looking a J-Dev is like looking at the Rosetta Stone...where the heck do you start? And why? When building an ADF application why do you pick some components and not others? Is there a specific set that I should always pick? If I miss one can I go back and add it? Why is it in one tutorial I can move a field on the form to another spot but in another I can't move the field anywhere...it's stuck to the frame (if that's what it's called). Mind you....this is just the tip of the iceberg."
Now I just recently started wearing the hat of an Oracle Product Manager for ADF. And it's possible you'll be thinking straight away "here we go, the brainwashing has done its job, Chris is going to start rabbiting on about the virtues of ADF".
Not today I'm afraid.
What I wanted to do instead was address the comment about MVC. I don't intend to pick on the original poster and his opinions. I'd just like to take the ideas and run with them, and express some opinions of my own (which aren't necessarily sanctioned by Oracle Corp either!).
What I'm specifically worried about is I think Oracle Forms programmers will be doing themselves a diservice to discount MVC
- Because Oracle Forms is MVC-like
- The general principles of MVC will assist Forms programmers too
- From experience the best Oracle Forms solutions I worked on were working towards an MVC ideal
Firstly let's consider my point of "Oracle Forms is MVC like". MVC dictates loose coupling and separation of concerns
of the business/model logic, from the view (user interface) logic. Oracle Forms as a framework built into the IDE attempts to present this same concept, to a certain greater or lesser degree. Blocks and items represent the model, and the canvases represent the view. Now it's not the most ideal MVC solution to be sure, but you can see Oracle's original Forms designers had an inkling of MVC in their thoughts.
What I'm *not* surprised about is the original Forms designers didn't implement a full MVC solution for customers. While MVC is an old concept going back to 1979 from Xerox PARC
and SmallTalk it really didn't take off to more relatively recently (I'll take a punt and say it was the explosion of J2EE just before 2000 though I have no evidence to support this). As such there probably was no directive within Oracle to "build something MVC like so developers can create an UI for our database".
Yet even though it appears MVC only recently "had it's day in the sunshine", it shouldn't be pegged to the Java arena only, from my reckoning it's a popular concept. And by popular we'll return to the original posters comments:
"I'll bet the MVC based IDE makes a whole lot of sense to a Java developer but from the Forms side looking a J-Dev is like looking at the Rosetta Stone"
Here's the thing. MVC is not limited to the realms of Java (or SmallTalk for that matter). .Net has it
. PHP has it in oodles
. Ruby on Rails is based on it
. It appears to be pretty popular all round. So I'm not sure there's grounds for dismissing it as a Java peculiarity, there must be something worthy about it if it's used so widely?
This doesn't mean of course MVC is the be-all-end-all of architectural solutions. Indeed Google "Disadvantages of MVC
" to find the counter arguments and there's even variations of it such as MVVM
. But to just place MVC in the Java camp and close yourselves to its popularity is not giving yourself a chance to learn the pros and cons of MVC, and maybe grab some of its benefits rather cheaply for your own use?
This leads onto my second point "the general principles of MVC will assist Forms programmers too". Where Forms fails in the eyes of MVC is it too easily allows developers to make tightly coupled code where the model and view layers combine logic (in other words, poor separation of concerns). The fact that Forms' triggers for UI items reside at the model layer (i.e. the block), means developers can easily intermingle business/model logic with the UI representation. For example a WHEN-VALIDATE-ITEM trigger with an enforced business rule that turns the erroneous field red on a violation shows such tight coupling. Why should the business rule code care the field must be red? What if the user is color blind and we need to change the color to blue; we're going to need to change the business rule code to fix a color? This coupling is a problem, a small one admittedly, but still a problem, especially if we need to change the color in hundreds of WHEN-VALIDATE-ITEM triggers. Solution: don't couple your UI and business logic.
By the way let's be very clear here. I'm not saying that's wrong all the time, indeed in an application made up of 1 Oracle Form with 1 piece of code, who cares. What I am doing is highlighting this is wrong from the MVC point of view. But again why should you care? What can Forms programmers learn from MVC?
This question leads onto my third and final point "from experience the best Oracle Forms solutions I worked on were working towards an MVC ideal even if the programmers knew it or not."
One of the common problems tackled at Oracle Forms sites where Forms has been a proven technology for years, is the problem where the complete system (Forms, database and all) needs to be extended with other technologies. Today organizations don't rely just on Oracle Forms, but a combination of technologies to maintain and integrate with their systems. Maybe a .NET team implemented an ASP solution to backend the same database the Forms system used. Maybe a group of keen graduates implemented part of the solution in Ruby on Rails. From an Oracle perspective maybe even an APEX or ADF or SOA solution has been put in place. Point being Oracle Forms is only but one of the moving parts in the overall system architecture.
Now there's an inherent problem in the WHEN-VALIDATE-ITEM Oracle Forms example I gave before. Regardless of the technology used to update the underlying database table relating to the Oracle Form's block in the previous example, the business rule must still apply. Hmm, that's a clincher. We may have .NET solution, a Ruby on Rails package and even our Oracle Forms system, they all need to implement that same business logic. But the business rule is stuck in our Oracle Forms solution. What do we do? Do we copy the same logic into every platform and then if a change is required have to duplicate that change across all platforms?
Doesn't sound ideal does it? And this is where experienced Forms customers come to the fore, because sites I've visited have strict guidelines on separating out the Forms UI logic from the business logic, where the business logic goes into PLSQL PLLs attached to the Forms, or more ideally down into the database where it can be used by anyone who can connect.
Now putting the logic in the database is a whooooole separate set of arguments (which has yet to resolved and I don't even want to go there, but Google the concepts of "thin vs thick databases" or "thin vs thick middletier" if you're interested, or maybe even the idea of "service oriented architecture"). Yet the fact that the business logic is decoupled from the UI logic this is what I want to focus on. Experienced Oracle Forms sites will be familiar with the pattern I just described. In turn Oracle Designer developers will be familiar with the Table API approach. Indeed many Forms programmers will already understand the what-and-why of this approach. By design you were separating concerns and creating a looser coupling, which enables greater reuse. And it's those ideas MVC teaches.
And it's at this last point I'd like to finish with. The concepts of MVC isn't something Forms programmers should isolate themselves from. Your tool of choice and your experience has probably lead you down the MVC path, choosing the same ideals, all by your own effort and reckoning.
In a previous life as a software developer and consultant, on occasion I'd sit down with a client who would describe a neat solution they had come up with all by themselves, and I'd reply "oh, that's similar to [insert solution X here]". Kudos to you. You've worked out a best practice without guidance, but your own effort and brawn. Maybe it's time to read some more on MVC to see what else you could learn from it?