SCJD: MVC Advantages and Disadvantages

So my first crack at creating a small framework became a good learning experience. Working here at Intelliware, we’re so used to layered design that I think this is very much second nature now for most of us. i.e. have separate layers for GUI, actions, service and data store. But most of the time we are just provided with these frameworks and I’ll admit that most of the time I really don’t know what they’re doing under the covers (but I probably should).

But it was nice to kind of do a little small framework for myself and realize the advantages of it as I was doing it. So here’s how I saw my project as it relates to the layers we tend to use at Intelliware and some important advantages I saw in using MVC.

The Layers

Presentation Layer (View)

Solely for rendering the GUI such as JSP, HTML or SWT.

Actions Layer (Controller)

Given this handled all the user events via action listeners and communicated with the service layer (model), I kind of equated this with actions frameworks we tend to use, like Struts, Tapestry or Spring Webflow.

The Service and DAO layers (Model)

So this layer is actually composed on 3 layers in my design…

  • The service layer is responsible for the usual encapsulation of business logic (i.e. the service layer with methods like bookSuite(), findSuite(), addSuite(), removeSuite(), etc).
  • The DAO layer, as the model delegates to it. This is handling the usual CRUD DAO methods such as create(), read(), update(), delete(), find() and also logical locking methods lock() and unlock() to ensure only 1 record is being modified at time.
  • A third layer to handle low level file work; such as seeking to a position in a file, reading bytes from and writing bytes to a file, synchronizing on a file pointer reference to ensure only one thread at at time is writing to a file, etc.

More on logical and file level locking on future posts.


Separation of concerns

The key thing here is reduced coupling of rendering, action and business logic. Let’s say instead of a file as a database, I used a real database and Hibernate. Well, the only layer that would be affected is the model. I’d get rid of the file low level DAO layer and just configure the standard DAO layer to work with Hibernate. Of course there’d had to be other configurations for Hibernate to work, but there would be no change to the actions layer (the controller) or the presentation layer (the GUI). When I realized that I thought that was pretty sweet.

Easy to maintain

If I needed to add or delete a screen on the front end, the model would be unaffected by this new screen. The new view would implement the BookingModelListener and would be notified of model changes. There’d just be one less or one more screen that the model would notify in its list of listeners when the model changes. So its essentially oblivious to the front end change. Less code to change, less maintenance cost.

Flexibility in a client/server environment

The layers of MVC provide flexibility. The application can be used in a call center environment. One central database server, X number of clients connecting to it. Imagine that there needed to be some new screens added to the application to display some booking information in a different way (let say a screen to add or modify a booking record), but didn’t require DAO changes. Without MVC, I would have to redeploy the entire application across the call center; i.e. taking down the entire application and thus encountering downtime. However, with MVC here, all I would have to do was split up the application into 2 jars before originally deploying; client and server. Since the server jar wouldn’t be affected by changes on the front end, that means I wouldn’t have to take down the server. Thus allowing me to slowly roll out the new clients across the call center without company wide downtime. And that’s huge.


Honestly, for this project, I really didn’t encounter any. I’m sure once used in a larger more complex environment some would arise. I’ve read of typical disadvantages such as MVC applications being hard to deploy or being restricted to making changes to data only on a local file system. I found neither of those were issues for this program however. But I do see a potential problem.

Large Controller Classes

I hinted at this in my last post. I never ran into this in my program as I had few screens. But I can imagine if used on a large scale application (like HWNG) where there are many, many screens, the controller would grow to be very large and later be hard to maintain if that one controller handled all actions for the entire application. Maybe creating a hierarchy of controllers would alleviate that, but its still a concern.

It's only fair to share...
Share on FacebookGoogle+Tweet about this on TwitterShare on LinkedIn

Leave a Reply