6

I whipped up a demo on Friday before the holiday weekend of using the Model-View-Presenter pattern (the "Passive View" version, I believe) that I want to show to my co-workers this week as an example of how to architect our WebForms application moving forward and get maintainable, clean code. We currently keep almost all logic outside of some data access routines in the code-behind files.

I know immediately one of the points raised will be that it's faster/easier to just use code-behind rather than create a separate class library for the views and presenters, and having to create a separate view per page (that at least can get hairy as we have well over a hundred pages, although at this point I'm talking about future development and not retrofitting the rest of the code). The argument will be that it's much faster to get a task done by doing something like this:

protected void Page_Load(object sender, EventArgs e)
{
    DataSet ds = Customer.Get(Request.QueryString["custid"]);
    if (ds.Tables[0].Rows.Count > 0)
    {
       txtFirstName.Text = ds.Tables[0].Rows[0]["fname"].ToString();
       // other properties here.. 
    }
}

than this:

// CustomerDetails.aspx
private CustomerDetailsPresenter _presenter;

protected void Page_Load(object sender, EventArgs e)
{
    long customerId = Convert.ToInt64(Request.QueryString["custid"]);
    _presenter = new CustomerDetailsPresenter(this);
    _presenter.Init(customerId);
}

// CustomerDetailsPresenter.cs
class CustomerDetailsPresenter 
{
    private ICustomerDetailsView _view;

    // ctor here...

    public void Init(long customerId);
    {
        // get customer somehow, via ORM or DataSet or whatever...
        _view.FirstName = firstName; // some string, whether from dataset or ORM
    }
}

What counter-arguments can I use to show the benefit of using the MVP pattern? Specifically ways it would improve the speed and efficiency of getting things done. Just saying "it's cleaner" or "you can properly abstract the code" isn't enough because code quality has never been a big issue, just speed (and now that mentality is biting us in the rear).

NOTE: This is for new features to an existing brownfield/legacy application, not for a new site (I would chose MVC for a brand new site). New pages that have to interact with the application as a whole, radical changes to old pages, and the like is what we normally do and what I'm talking about using MVP for.

4
  • The developer that use the first version provide much more short time value per hour than the second one. However, the second one may provide more long term value per hour. See where I want to go?
    – user2567
    Dec 26, 2011 at 14:51
  • What about the testability argument? How would that fly?
    – Oded
    Dec 26, 2011 at 15:03
  • Testability wouldn't matter since we have no automated tests at all Dec 26, 2011 at 15:10
  • 2
    In the title you say I need some counter-points to counter the argument of why NOT to use M-V-P. Then in the text you say What counter-arguments can I use to show the benefit of using the MVP pattern? Technically it may be correct, but isn't it a bit confusing?
    – Mike Nakis
    Dec 26, 2011 at 18:40

5 Answers 5

1

I know immediately one of the points raised will be that it's faster/easier to just use code-behind rather than create a separate class library for the views and presenters

This argument can be raised for plenty of things.

  • It's faster to start writing code, instead of spending more of the 50% of the time gathering requirements, designing the architecture of the future project, etc.

  • It's faster to not enforcing style guidelines.

  • It's faster to write code, instead of writing code and unit tests.

In all cases, the argument is invalid for large projects. You spend less time if you avoid writing unit tests, then you spend much more time debugging, understanding bug reports from your customer, etc.

If the project is really small, don't use MVP. Code-behind solution will be faster in all cases, with no drawbacks. If you are about to start a large-scale website with thousands of lines of code, not using MVP because it will be faster at the beginning is not a valid argument.

1
  • The idea is for future maintenance and features added to a very large existing (brownfield/legacy) ASP.NET Website (not Web Application). Added edit to original question to emphasize this. Dec 26, 2011 at 15:46
2

If I were one of your co workers I wouldn't be against the idea using MVP or MVC. But I would question the way you want to achieve it. The way you propose it is much harder than adding MVC 3.0 to the site. MVC and WebForms can be used on the same website. There is almost no argument why to do it in some manual way like you want to do it.

If you are using MVC you have better arguments against it is faster the old way because it does not take more time implementing with MVC. The amount of code you have to write is almost the same.

5
  • Well, the site has to work with existing pages; it's not a totally new site so we pretty much have to stick with WebForms, hence why I was looking at MVP as a way to abstract things. Dec 26, 2011 at 15:43
  • You can have pages that are WebForms and pages that are MVC in the same project. Introducing an MVP patten for a page means a complete refactoring of this page anyway. So why not doing it right for those (and new pages) pages and go for MVC while leaving those pages that are untouched WebForm pages?
    – Remo Gloor
    Dec 26, 2011 at 16:17
  • Can you have MVC pages in a WebSite project? Or would everything have to be copied to an MVC project? Dec 26, 2011 at 19:10
  • Yes see nuget.org/packages/AddMvc3ToWebForms
    – Remo Gloor
    Dec 26, 2011 at 20:03
  • I'll have to look at that and see if it will work with an asp.net web site project (the one with every page as its own DLL) Dec 26, 2011 at 22:42
2

Testability wouldn't matter since we have no automated tests at all

Did I get you right - you test everything manually? And your coworkers think that is "faster/easier" than writing the code in a way that it could be easily tested automatically?

Ask your coworkers that and show them how absurd that sounds, perhaps this the argument you are looking for.

2
  • That is correct. Unit Testing (or any kind of design patterns, or anything that doesn't involve just writing procedural-style code in the event handler of a code-behind file) is viewed by management as a waste of time that doesn't increase revenue. In fact, we are forbidden to write tests or refactor code because that means we aren't working on coding tasks. Feb 3, 2012 at 14:05
  • 1
    @Wayne M: Run. The earlier, the better!
    – Doc Brown
    Feb 3, 2012 at 16:35
1

Trivially, all you have to do is introduce the case of multiple pages. In this case, it will be significantly easier to refactor and test the CustomerDetailsPresenter than six dozen copies of it's source code in six dozen pages.

1
  • 3
    Not really. You can have one copy of the code without using MVP. One solution is to create a separate class with shared methods and call them. Another solution is to create a base class with shared methods, and inherit six pages from this base class. Dec 26, 2011 at 15:13
0

Patterns are a way to solve common problems, it has nothing to do with speed or efficiency. More precisely problems that the languaje itself can handle as it is. If you want speed, code the critical parts in another language, perl is very fast, because in the end you can buy just more servers, cpu or ram, but if the code is a mess or hard to extend it's useless. You won't find good arguments against a certain pattern because they are language independant. The only thing i can tell you for sure is that mixing a pattern with legacy code will make it hard to understand to another programmer.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.