MVP/MVC vs traditional n-tier approach for winform apps.

We have a large suite of apps, most are C# 1.1, but at least 10 major ones are in VB6. We are undertaking a project to bring up the VB6 apps to .NET 3.5.

All the c# 1.1 apps are written using a traditional n-Tier approach. There isn't really any architecture/separation to the UI layer. Most of the code just responds to events and goes from there. I would say that from the point of maintainability, it's been pretty good and it's easy to follow code and come up to speed on new apps.

As we are porting VB6 apps, the initial thinking was that we should stick to the existing pattern (e.g. n-Tier).

I am wondering, whether it's worth it breaking the pattern and doing VB6 apps using teh MVP/MVC pattern? Are MVC/MVP winform apps really easier to maintain? I worked on a MVC-based project and did not feel that it was easier to maintain at all, but that's just one project.

What are some of the experiences and advice out there?

From stackoverflow

• It moves a thin layer of code you still probably have on the UI. I say thin, because from your description you probably have plenty of code elsewhere. What this gives you is the ability to unit test that thin layer of code.

  Update 1: I don't recommend to re architect while doing the upgrade, the extra effort is best expend on getting automated tests (unit/integration/system) - since you will have to be testing the upgrade works anyway. Once you have the tests in place, you can make gradual changes to the application with the comfort of having tests to back the changes.

• Dude, if something works for you, you guys are comfortable with it, and your team is up to specs with it. Why do you need to change?

  MVC/MVP sounds good... Then why am I still working on n-Tier myself?

  I think before you commit resources to actual development on this new way of programming... You should consider if it works for YOUR team.

• If you are porting the VB6 apps vs. a full rewrite, I'd suggest to focus on your Pri 1 goal - to get asap to the .Net world. Just doing this would have quite a lot of benefits for your org.

  Once you are there, you can evaluate whether it's benefitial to you to invest into rearchitecting these apps.

  If you are doing full rewrite, I'd say take the plunge and go for MVP/MVVM patterned WPF apps. WPF willl give you nicer visuals. The MVP/MVVM pattern will give you unit testability for all layers, including the visual. I also assume that these apps are related, so chances are you might be able to actually reuse your models and views. (though, I might be wrong here)

• MVC in particular does not exclude n-Tier architecture.

  We also have ASP.NET 1.1 business application, and I find it a real nightmare to maintain. When event handlers do whatever they like, maybe tweak other controls, maybe call something in business logic, maybe talk directly to the database, it is only by chance that software works at all.

  With MVC if used correctly you can see the way the data flows from the database to your UI and backwards. It makes it easier to track the errors if you got the unexpected behaviour.

  At least, it is so with my own little project.

  I'll make the point once again: whatever pattern you use, stick to the clear n-Tier architecture. 2-Tier or 3-Tier, just don't mess everything into a big interconnected ball.

• "Change - that activity we engage in to give the allusion of progress." - Dilbert

  Seriously though, just getting your development environment and deployment platforms up to .NET 3.51 is a big step in and of itself. I would recommend that things like security reviews and code walkthroughs should probably come before re-archecting the application.

  MVC and MVVM are excellent paradimes, particulary in terms of testability. Don't forget about them, but perhaps you should consider a pilot project before full scale adoption?