I\'m reading about ASP.net MVP pattern over this weekend and it seem like even the most simple task take too much effort if do it in MVP pattern the pay off seem to be at larger
I would recommend reading the following two links to get you up to speed on MVP and MVC :
Should you switch over?
Based on what you've told me I would recommend that you use the Passive MVP model mentioned in the article above.
My main assumptions are:
Your View (codebehind + aspx) essentially become dumb and just perform simple tasks:
I've used this model extensively for Web Forms development and I couldn't imagine not being able to Unit Test my Model and Presenter code. Once you establish your base model which doesn't take very long and seen the power of Unit Testing, working with Web Forms becomes enjoyable.
Some links to MVP stuff that the model I've used is based on:
I would also recommend that you learn MVC to.
When time permits, take an existing App and port it to MVC. This way your sole focus is getting to know MVC and when you move logic into the MVC pattern, you'll discover things that you implemented in WebForms and never gave much thought to but now need to solved in another way. Great way to compare the patterns and see what works for you.
Hope this helps, feel free to ask any questions.
In my opinion, the ideal way to go for new applications is MVC. However, if you have a lot of code already using WebForms, then the MVP pattern is the way to go.
If you start a new project, then ASP.net MVC is a better choice. But if you just want to refactor an existing project as you just said, then MVP is the option because there is no easy way to convert those web-forms codes to MVC .
I would go Asp.Net MVC if it's a new project, but I agree, MVP might be a good pattern for legacy webforms projects.
Here's an example from my blog: http://www.unit-testing.net/CurrentArticle/How-To-Use-Model-View-Presenter-With-AspNet-WebForms.html
my personal opinion is that if there's a lot of code in the code behind, there still are ways other than adopting M-V-P in order to slim it down, refactor and make it testable.
if your page has extensive user interaction (like buttons/links enabling/disabling, panels and controls appearing/disappearing) M-V-P would be worth the hassle.