What is MVC?

What is MVC?

MVC or Model-View-Controller is a fairly common design pattern in the software engineering and especially in web application development. Now the term Design Pattern might sound like some big thing, but in fact it is more of a Divide and Conquer approach to building something, essentially you break the problem into 3 areas:

Model

This handles the Data and Business Logic, so think about retreiving data, storing data, manipulating data.

View

This is the simple one, it is the User Interface or how the thing looks.

Controller

This is the glue, this is an intermediary that handles input, manipulates the model and decides what to display on the screen.

Now when you read it like that, and when you build anything, I think it makes more sense for it to be known as MCV, but apparently I am in the minority on this one.

Why use MVC?

Well as I said earlier, this is a Divide and Conquer strategy, it allows you to focus your efforts on one piece at a time, or, as in most companies, it allows you to break the work down into different teams, you may have someone that is amazing at the frontend and an entirely different, but equally amazing, person or team at the backend.

Parallel Development

Your Designed can work on the front whilst the Developers work on the back (I said it already, but it remains true).

Reusability

This one is a big one. When you break it down like this, then many of the components can be used in other contexts without significant rework.

Scalability

As with the point above, this allows us to add or extend functionality to the parts of the system that are under the most load, which allows us to scale up (and scale down) relatively quickly.

Testing

By breaking down the components, it is often easier to test functionality such as unit testing.

Disadvantages of MVC

It can be slower and much more complex, so if the thing you are building is tiny and not expected to grow, then it’s probably not wirht the effort.

Complexity

If the project is simple, then an MVC approach might feel like too much work, and in fact, it might well be over-engineered. Put it this way, if you were taking the fake it until you make it approach, you probably wouldn’t start with an MVC design pattern.

Boilerplate

This is strange, because one of the advantages of the MVC is comoponent reusability, but whilst the component may be reused, the code itself can feel quite repetitive as you end up writing the same (similar) thing many times.

Learning Curve

Not so much learning how to build using MVC, if that’s the way they taught you right from the begining there would be no learning curve. But when you join a company or an existing product team, understanding how all the pieces fit together can be a challenge as we’re no longer just looking at one file, in fact, as an example, I wrote about Building a Timesheet System, even just adding a single new element to my timesheet system required me to modify at least 3 different files (one each for the M, V, C).

MVC is not the only choice

MVC in the WebCenter Portal world

As a reminder, I am looking after some WebCenter Portals at the moment, this is an enterprise platform for collaborative working. You may have heard of Microsoft SharePoint, it is similar, and if you have heard of neither, then the only way I could describe it is it is like having an internal internet (Intranet or actually more like an Extranet) that only your staff can access, or as in most cases, your staff, your customers, your trusted partners. Some pages are just presenting information, they look very much like web pages and some are a bit more than just a web page.

Oracle WebCenter Portal is a powerful enterprise portal platform, and like many Java-based web platforms, it adopts an MVC pattern but with an Oracle twist.

Oracle’s MVC Approach

Oracle leverages JSF (JavaServer Faces), which implements the MVC pattern but adapts it for component-based UI design. In WebCenter Portal, especially in versions 11g and 12c, MVC is layered with Oracle’s ADF (Application Development Framework) and WebCenter-specific components.

Here’s how the MVC translates in WebCenter Portal:

• Model: Data from multiple sources – databases, web services, content repositories.
• View: ADF Faces components or Portal skin templates.
• Controller: Task flows and managed beans orchestrate interaction between the model and view.

I took that last line from a book about Developing with ADF as I have never used it before and basically hate Java anyway, so I needed some extra help, hence the book. But the last one, my head hurts just thinking about that word soup.

The book goes on to note that Oracle often extends MVC with bindings and data controls, which help abstract multiple data sources and service integrations. This extra layer can be seen as a “Model Adapter” that connects external systems into the MVC pipeline. Right now, today, I would not recommend this book as it seems to phrase things in about the most complicated way it could, thought perhaps after a few hours of coding under my belt, I’ll look back and wonder why it seemed like such a challenge…

MVC in WebCenter Portal - considerations

Now, whilst the book I’m working through has certainly thrown more new words and terms at me than I was expecting, I do see some quick wins:

• Clear separation of concerns – You can update a portal’s skin (the View) without affecting the Model or Controller logic.
• Support for multiple data sources – Oracle’s bindings and data controls simplify integration with varied backends.
• Component reusability – ADF components can be reused across pages and modules.
• Customisation at each layer – You can swap out the UI or change the data source with minimal disruption.

That said, the Oracle twist does leave me wondering just how many small changes were made to the existing portals before they came over to me:

• Steep learning curve – Understanding ADF, JSF, task flows, and data bindings is quite overwhelming.
• Performance overhead – The many abstraction layers seem to have slowed down performance and figuring out how to correct that seems like a full time job in itself.
• Dependency on Oracle tooling – I think I am locked into JDeveloper which feels and looks awful (but it is always hard to move to a new IDE, I’ve seen many heated discussions around which IDE is best and it probably just comes down to which one you know best, so at some point, I’ll likely know my way round JDeveloper better than I do today and maybe then it doesn’t seem so bad…).
• Complex debugging – I read that errors can arise across multiple layers (e.g. binding layer vs. JSF vs. task flow), making issues hard to trace. So this is new to me, there are errors everywhere, finding out the cause is, and will remain, a challenge.