MVC/MVP - Overused Patterns?

I did an engagement recently where a client wanted to create a windows forms application from an existing legacy application. The existing legacy app was important but relatively simple in terms of architecture.

A previous consultant went in and recommended the use of the Model View Controller (MVC) pattern, with the possible use of the CAB (Composite UI Application block).

While the MVC can be a good choice as far as a general pattern goes, and the CAB a reasonable application block, in this scenario I thought it was quite a bad decision. The team responsible for development had no real idea how to implement MVC properly, had never done anything remotely like the CAB before. Patterns such as Inversion of Control / Dependency Injection were very new and complex to them. The recommendation was simply a formulaic response to a problem that did not suit the context.

In reality, the team could not have delivered the application in their required timeframe, with their current skillset.

What’s the moral of this post? Well, more as a warning. Standard patterns and accepted trains of thought are good in general, but don’t recommend or use architectures just because everyone else is, or they are the current implementation flavour of the month. As an architect, assess not just the technical details, and possible ways of designing the solution, but also how that fits in with current social issues such as team skillsets, experience, likelihood of success and current needs. In this example, the legacy applications architecture was very simple. The architecture I ended up proposing was in itself quite simple (in fact overly simple), but achieved the goals of modularity, loose coupling, expandability and ability of the existing team to deliver it. It also allowed further complexity and patterns to be introduced where necessary and as required, but it certainly wasn’t required from the outset. Small Steps.

Its easy to make a simple thing complex, but its a much much harder task to make a very complex thing simple.




  • Oh come on, everybody's doing it...........

  • I wouldn't want to be too technical with asses either.

  • Theyeine,

    Thanks for catching that :-)

    Brings new context to a hairy technical problem ;-)

  • Hi Glavs,
    I went through the same with my teams at the company I currently work for.
    I agree with you that our main goal as architects is to make very complex things simple. That´s a major worry for me in every single project I design.
    What I entirely disagree with you is that we should be downgrading the quality of our work to match the skills of our teams. Let me explain if further.
    Our projects are mainly ASP.Net ones, and since we need Unit Testing it´s not exactly a simple architecture. Besides there are huge projects and then there are the small ones. I know there´s no such architecture that "one size fits all" but I had to find a common ground for our projects so they can derive from. And this common ground is the Model-View-Presenter pattern.
    Most people in our teams have absolutely NO IDEA what dependency injection means. And they don´t even have to! Because as architect my job is to make their job more productive (not easier). So I started the NMVP Framework, which is a frameworked approach to development of MVP applications. The results were so fantastic I´m writing a book on the framework. The teams were more productive and code quality improved.
    I´m just writing to tell you that in my opinion being an architect is not scaling down to meet the team´s expertise... It´s keeping the bar up high with the team´s expertise.

    Bernardo Heynemann

  • Hi Bernardo,

    I also agree with you. In my situation, I neglected to mention that I was not able to follow the architecture through. I had to leave the team to fend for itself as I was simply on a very short consult. So I had to make a judgement call on what would succeed and what would not (no matter how pure it was). In the end, the design still had some core MVP concepts, but was simple and flexible enough for that to be fully adapted at a later stage as time permits and complexity increases. I would be interested in reading your book though. Thanks for the comments.

  • I'd have to say that these patterns should probably be used more than they are. The next step is bringing true unit testing to the presentation layer - which is pretty hard without MVP.

  • Udi,

    I have seen to many bad implementations to say it should be used more. Used more judiciously is my take on it.

    Sure you can argue that its just a matter od knowing how to implement properly, but thats with anything really.

    Anyways, thanks for your comments. I am not advocating not using it, but too many a "reflex architecture" has been created with MVP (ie. oh you need a new "x" solution, MVP is your answer - end of story)

  • Well done Glav, finally someone actually agrees that using design patterns (for the sake of using them) doesn't stop you project from failing!!

    As an architect, success is more likey if you do meet the level of the team, so I also agree with Bernardo, that pushing the team that little bit further will extend them and raise the bar.

  • I am a fresher in programming tools...
    let me know how can I study MVC Quickly.
    What are the prerequistes for this tool.
    Which framework is used for it?

  • May I know what is the solution you proposed for the legacy system? I am also in the same situation. We have lot of vb applications which have to be converted to .Net. I also thought of introducing cab. But Myself didn't understand fully. You can imagine the current team. Please share with me about your solution to

Comments have been disabled for this content.