I have been interviewing quite a few people recently for a position as Java developer.
Every single CV came with either a Struts or Spring mention. If not both. Oh yes, I have even discussed systems where both frameworks were used at the same time.

Of course it’s your system, you are free to use whichever technology you prefer. However, you must also be able to explain why you picked that particular framework. And “It wasn’t me who picked it” is not a good answer. If you had a better idea why didn’t you question the decision?

Perhaps my problem is not exactly with MVC frameworks but with the people out there who use them without thinking things through. These are the sort of people who go around telling you that they used both Spring and Struts because it’s an “Architectural pattern”. The truth is that they haven’t thought about their architecture at all. They just thought that by using an MVC framework the problem would solve itself.

Yesterday I was reading a post by Albert Wenger at Union Square Ventures about Loose Coupling. I’m not going to repeat here what Albert already explained quite thoroughly. I will just say I agree with everything he said. Especially with this paragraph:

So how does loose coupling enable scaling and innovation?  Scaling bottlenecks tend to move around as a site or service grows.  With loose coupling it is often possible to isolate a bottleneck and prevent it from slowing down everything else.
…
This also points to how loose coupling enables innovation.  Different teams can more easily be in charge of their own part and make changes to it more quickly.  Entirely new parts can be added more easily too (a great example here is Facebook adding chat).

MVC frameworks themselves do not prevent loose coupling as an architectural decision. The problem is that most of the people who use them are the sort of over-engeneering maniacs who try to build the perfect system in one big blob of code, and inescapably, fail.
So here’s my point. Using an MVC should not be considered an architectural decision. Architecture is at a much higher level.

Most architecture design nowadays show systems split horizontally.

This may allow your application to support higher load, but doesn’t give you the ability to isolate bottlenecks in your application. I believe what we’ll see in the future is architecture diagrams that are split vertically with every single component (or task your app has to perform) being completely independent from the rest, and feel free to use the MVC of your choice in each component. Just make sure you know why you decided to use it.

Bookmark It