I need some counter-points to counter the argument of why NOT to use M-V-P

Question

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.

Answer 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.

Answer 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.

Answer 3

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.

Answer 4

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.

Answer 5

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.