How to propose Asp.Net Mvc over other technologies to client?

Question

How to show benefits of adopting asp.net mvc to client?

I mean - we as developers can understand benefits of easier implementation of automated testing, better control over rendered html etc., but what would be strongest motives for client to accept usage of asp.net mvc?

Maybe there's some more nice looking examples built with asp.net mvc (excluding stackoverflow) to show?

---

p.s. Please, do not start flame war.
In this case - it doesn't matter if asp.net mvc is better than x or vica versa.

Answer 1

Clients typically don't care what technology is used in building their website, so I would use cost as the driving factor for using ASP.NET MVC. Let the client know that their cost will ultimately be lower if they choose technology X (even if that isn't necessarily true). The bottom line is a powerful negotiating tool.

Answer 2

For the most part clients don't care about what is going on under the hood so long as it is

• cheap
• reliable
• maintainable
• compatible with anything they currently have

Cheap is easy to sell, ASP.net MVC is free. Reliable? It is built by Microsoft and that is an easy sell to most PHBs. Maintainable? This is a bit trickier since it is a new technology and there aren't a whole lot of experts. However the selling point here is that it is much closer to pure HTML than, say, webforms so should be easy for almost any developer to maintain.

Compatible is harder, but you can use user controls in MVC if that is what they have. This one you'll kind of have to solve for yourself as it is client specific.

Answer 3

I'd go the other route, find some crappy ASP.NET Web Forms sites to show them. Should be pretty easy. :)

Answer 4

This is a layered question:

1. Why use .NET - capability and performance (and there's no harm in saying its a technology you're comfortable with). IIS7 is turning into an very impressive platform.
2. Why use ASP.NET MVC? The key sell to a client here is the level of control you have over the output - this is a tradeoff you decide to take on board as a developer, you have more control so in some respects you have more work to do however the win for a client is in the resulting pages which should be smaller, more standards compliant, more search engine friendly and generally all the things that a public web site should be.
3. But if its for an internal site you have to actually make a more considered judgement, forms works, you can produce very good results and if you know the environment its going to be deployed into you may find that you're more productive with the building blocks it provides than with MVC.

As an aside, there's nothing to stop you using the strengths of the MVC model in web forms - the fault we tend to be most guilty of is failing to separate the logic correctly because its too easy not to, but from a clean slate you can be aggressive in what you allow.

Answer 5

This question might be a little subjective, but I will take a crack at it anyway.

--Background:

MVC was picked for me before I started at my present company and I was charged with learning it, which suited me fine as I am very HTML oriented. The project is in development but we have iterative meetings to show progress and flesh out requirements. In one of these meetings I found a major payoff:

--My Experience:

The question of whether the site could support mobile phone access was put forth but up until now I had been designing the site for a 1024 x 768 minimum resolution. No worries, I simply turned off CSS Styles and the page displayed in a not-very-pretty-but-very-functional flow. The entire site is designed semantically making it easier to port to different front ends via style sheets and maybe a little JS. ASP.net MVC is awesome for semantic websites, which are cheaper and easier to maintain.

--More Stuff

This is one of several benefits of adopting a web technology that more fully embraces the medium it runs on. Others include:

• Better separation of model view and control logic, because well its MVC, but this makes you code more loosely coupled, and more single-responsibility-principle adherent ultimately making it cheaper to maintain

• More standards based, meaning its easier to use JQuery and CSS tricks that all the cool kids are using, because those really shine in well formed sematics-based documents. This means its cheaper to add flair

• Restful, URL - driven requests. Your URL does not specify some .aspx to load and do a ton of work across a bunch of layers in its poor little code-behind. Your URL specifies a request which causes the router to invoke model-layer functionality which runs where it is supposed to, then dumps pertinent data to a view. Lots of good stuff here:

  • This makes it easier for one controller to serve up pages, webservices, AJAX, and handle all CRUD cases, but all around a single context.

  • Each responsibility is handled by a method called from the router, each group of related responsibilities can be materialized into a controller.

  • You control what data goes where, you can custom build a view model to go out to the view, and the view simply contains logic to show it, making things simple and secure especially if the people working oon the view are not the people working on the controller logic.

There's a lot more but in the time I have taken to type this, all the other answers have probably been posted.