tags:

views:

675

answers:

12

At my company we're about to build a new site using ASP.NET MVC. My boss (marketing guy) would like to know some more about the technology so I've tried to find a really good, simple and pedagogical presentation of the MVC concept without any luck. Most of them require quite a lot of basic knowledge in programming.

Any suggestions for a good video, slides or other?

+2  A: 

Craig Strong has a pretty nice article about MVC in general and how to explain its benefits to business. Check it out here: http://c6s.co.uk/webdev/128

Scott Anderson
A: 

You can very easily do this, that is if you understand marking speak. I dont but I imagine it would go something like this...

This should be use. MVC (if done right) will allow you to decouple the UI from the data (model) and control of the UI (controler). This will allow the UI to be more flexible which will in turn allow to better market it self faster.

Tony
changed image => imagine for you
TStamper
bah. Thanks. I type slower then I think...
Tony
A: 

This is a pretty simple one

http://en.wikipedia.org/wiki/Model-view-controller#Pattern_description

The best way I can thing of is that the model is the data representation, the view is the presentation to the user and the controller is what collects user interaction that changes the model.

Robbie
+1  A: 

I wouldn't try to explain the technology to him, I'd try to explain what the MVC architectural principle is all about.

MVC was designed to separate concerns. Plain and simple. Explain to him that when you build anything that what you're building can be classified in two different categories: what the business need is (the domain), and everything else.

MVC separates the Domain from the everything else by introducing layers to separate out the concerns. M is for Model, which is your domain. V is for View, which is the visible part to him, what he sees. C is for Controller, the part that controls what is going on in between the Domain and the View.

Joseph
+4  A: 

You have to explain the benefits of ASP.NET MVC, not the features

  1. You have control over your URLs -- that means SEO for the site will be better -- that means your site will be higher in google

  2. The code is cleaner, which means that it's easier to change, which means that you can add features faster

etc.

How do you save money, make money, reduce risk? That's what your boss wants to know.

Lou Franco
Yes, benefits will persuade much better than features. That is marketing 101.
Dana Holt
+1. So many of these answers involve trying to teach the marketing guy the MVC design pattern. He doesn't care. He wants to know how this technology will make him more money, save him money, or get him more customers.
Grant Wagner
surely the pretty URLs aren't the #1 reason for MVC...
nickf
Pretty URLs have business value -- google can read them, understand and index them. Keywords in URLs are considered to be important. URLs that are understandable are a usability benefit to advanced users
Lou Franco
+1  A: 

Imagine a control room in a factory, the model is the machine itself, the monitoring equipment is the view and the instrument panel is the controller. You could have several different control rooms for the same machine and changes in the controls in one control room would reflect on the monitors in all control rooms.

The point is that you should only model once and then view or control however is most convenient.

Stefan Thyberg
And the marketing guy is going to say "so?", or possibly "and how will this get us more customers?".
Grant Wagner
Imagine if YouTube had no API, for example, there was no way to embed anything anywhere, the only place you could do anything was at the YouTube website. The site would be less popular for it.
Stefan Thyberg
Also, that was not what you asked for.
Stefan Thyberg
A: 

To a marketing guy, perhaps the best way to explain the reason for ASP.Net MVC is the ability to broaden your product's reach.

By using MVC, the code is already separated in a fashion that will let you more easily build an interface that feels natural on a desktop, and then the different interface that caters to a general mobile device user, and a still-slightly-different interface that caters to an iPhone user, without risking the backend code getting out of sync and introducing subtle and company-harming bugs. And, if there's a smart client desktop app that could be a product... it, too, can rest on the same codebase.

The Model is "how things work inside the box". The Controller is "what you can touch on the outside of the box" and the view is "what comes out of the box"...

Tetsujin no Oni
A: 

The most important thing for your marketing guy is money, budget, TCO ...

When you don't use MVC you usually mix design, application logic etc. alltogether.

Programmer then must know html design, programming etc... That could mean you need powerful professional to do it all.

if you use MVC, everything is divided into "separate parts". Html coder can prepare html layer, programmer only works with application logic etc...

MVC brings better granularity and everybody can focus on what he or she can do the best!

Listen, for example xhtml validity and css cleanliness is so hard that there is a lot of people who focuses only on this while lot of browsers and platforms compatibility on mind.

Usually one person is NOT the best asp.net programmer, xhtml coder in one ;-)

RomanT
+1  A: 

The marketing guy would just be interested in the "V" part, the View. Depending on how you design things, the View would just be basic HTML/CSS "templates" that the marketing person could modify. Technically without breaking anything.

Ideally the Model (database) and Controller (logic) shouldn't care if the View (presentation) is XML, HTML, text, etc. The marketing person shouldn't care what the Model and Controller do, except for requesting additional functionality.

Going further with the "ideal", you should technically be able to replace ASP with PHP, Java, Ruby, etc as the Controller without touching the Model or View.

Brent Baisley
+2  A: 

M-V-C Think of it as: "Order Details (including Customer & Employee info)", "HTML/ASP Form (to display the OrderDetails)" and "Order details service class (having methods to SaveOrderDetails, GetOrderDetails etc.).

The Model (Data Class e.g. OrderDetails)

  1. The data you want to Display

The Controller (Service class)

  1. Knows about the Model (Order Details)
  2. Has methods to manage the Model
  3. And as such can be unit tested Its Single Responsibility is to manage the OrderDetails CRUD operations.
  4. It knows NOTHING about the View

The View (ASP Page)

  1. Displays the Model (OrderDetail's ViewData).
  2. It has to know about the Model's structure so it can correctly display the data to the users on screen.
  3. The View's structure (style, layout, HTML etc., locale) can be changed at anytime without it changing anything in the application's functionality.
  4. And as such, many Views can display the same Model in many different ways.
  5. In multi-tenant web applications, Customer specific Views can be stored in a database table and displayed based on Customer information
Tawani
A: 

The model is the data access layer, which can just be a wrapper for a few simple queries to an ORM that manages the data entity relationships itself. It handles communication to the data source, retrieves data and usually organizes it into objects defined in your application.

The views are just html files with bits of html and css with some templating engine (smarty, mako, etc) code to display the data passed to it the way you want.

The controller puts it all together. Requests made to your page will be routed to a controller (class) and an action (method) within the controller. Just like any other application, the action will do what's requested of it, but it's still part of the controller.

So, the controller uses the model to query data (users, content, etc), then passes the data to a view to be rendered and displayed the way you want.

scottm
A: 

He's a marketing stooge, what does he need to know about MVC or how it differs from Web Forms or a front-loading cement mixer?

Just give him a blank stare until he gives up and returns to his office. As soon as he is gone, go out and order a good book on ASP.NET MVC.

I recommend the Steven Sanderson book, but just about any of these would probably help some and keep your project from becoming a complete disaster: Stack Overflow: Best ASP.NET MVC book?

Maybe once you've read the book you'll be able to answer his questions on your own. (If you know enough about ASP.NET MVC to successfully complete your next project, you should be able to answer this question on your own.)

GuyIncognito