In our previous post, we very quickly put together a site using asp.net mvc, Entity Framework code first and MvcScaffolding templates.  That got it up and running, but of course there’s still plenty to do.  But before we get going in more development, let’s take a step back and look over the files so we understand what is going on.

So, how does MVC work? MVC stands for Model View Controller.  The pattern lends itself very well to having a good separation of concerns. That of course creates a very testable architecture. One of the goals for asp.net mvc was to use convention over configuration. How many times have you created a webforms application and had a ton of configuration in web.config?  Webforms straight out of the box uses a good deal of configuration just to get going.  MVC is structured in a predictable way.  There is a controllers directory where all the controllers are to be housed and a views directory where all the views are to be housed.  Routing is used to define how a URL is parsed out to map to the controllers.  So, our default route for KimmysCookbook.com is:

            routes.MapRoute(
                "Default", // Route name
                "{controller}/{action}/{id}", // URL with parameters
                new { controller = "Recipe", action = "Index", id = UrlParameter.Optional } // Parameter defaults
            );

What this is saying is that when a URL comes in, the first part should map to a controller, the second part to an action on that controller and the third part is a parameter that will be passed to that action.  The last part defines the defaults.  If no controller is is passed then the default is Recipe.  So in our case, when a user navigates to http://www.kimmyscookbook.com mvc will map that to http://www.kimmyscookbook.com/Recipe/Index .  Notice how easy that URL is to read.  That URL tells the MVC framework to look for a controller named RecipeController (the controller prefix is assumed by the framework) and it looks in the Controllers directory off the root of the site for it.  Once that type is loaded, it will look for the Index method within it and execute that resource.  Notice I said resource.  That’s an important distinction.  We are not serving up pages, rather we are serving resources.  So far the only resource we have returned are Views, however we could return just plain content (text), JSON, a file or even write our out ActionResult.  Just derive from ActionResult.

Our current Index method on the Recipe controller is this:

        public ViewResult Index()
        {
            return View(this.repository.GetAllRecipes());
        }

This is returning a View.  By default, the framework is going to seek out a view in the Views/Recipe directory.  Again, convention over configuration.  It will also search the Shared directory as well.

Our model in this case is an IEnumerable<Recipe>. So we are passing a list of Recipes to the view.  The view’s job is simply to display the model passed to it.  The view is intended to be very simple, therefore you don’t have a code behind file as you do in webforms.