Who is afraid of the big bad "MVC"?

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.

Recently on the ODTUG LinkedIn group there was a thread entitled How many of you are developing in Oracle Forms and Reports?.  The thread encompasses a number of answers including a discussion on ADF, initially peaking my interest.  Within that thread the following comment was posted:

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

Why?
  1. Because Oracle Forms is MVC-like
  2. The general principles of MVC will assist Forms programmers too
  3. 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?
Comments:

Chris,
this is so true...

Quote:
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."
:end quote

In the 20+ years of programming and designing systems in various languages and technologies I did, it turned out that the 'best' solutions are those which played along the lines of MVC pattern (or a modification of it). So in my opinion it really has nothing to do with forms or any other language. Its just that MVC is a really useful pattern.

When I started programming I didn't know about MVC at all. Looking back at my early projects (OK, it's fading memory) I would say that some concepts of MVC are there, not from the beginning, but after some nights of changing hundreds of code lines due to changed business rules which where scattered through the code. And back then I did not know that I tried to use MVC!

Let me repeat your point: We should take more time to read about (even already known) concepts and patterns!
Never stop learning...

Timo

Posted by guest on March 08, 2012 at 04:10 PM WST #

Toon Koppelaars has a very interesting series called "The Helsinki Declaration" where he talks about an alternative to MVC. See it at http://thehelsinkideclaration.blogspot.com/.

Posted by John Flack on March 09, 2012 at 10:01 PM WST #

Thanks for the comment John. I only had a chance to catch Toon's present at one conference, I wish I had more.

For reader's the specific blog posts John is referring to on Toon's website is likely the following two links (though I encourage you to read the rest of Toon's blog, he's blog entries have a great way of turning problems and questions on their head):

http://thehelsinkideclaration.blogspot.com.au/2009/03/j2ee-and-traditional-mvc-part-1.html
http://thehelsinkideclaration.blogspot.com.au/2009/03/jee-and-traditional-mvc-part-2.html

CM.

Posted by Chris Muir on March 11, 2012 at 02:29 PM WST #

Post a Comment:
Comments are closed for this entry.
About

Chris Muir - Oracle ADF Product Manager - The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today