Next, let's look at the controller. You can add a file named HelloController.vb to the Controller's folder by right-clicking the Controllers folder and selecting Add. Once you get the boilerplate in place, modify it as shown here:
Namespace MVCHelloWorld.Models Public Class HelloController Inherits System.Web.Mvc.Controller Public Function Greet() As ActionResult Dim theHelloGreeting As New HelloDataModel ViewData("Message") = theHelloGreeting.theHello Return View() End Function End Class End Namespace
The first thing to notice is that we use the same Namespace that we used in the Models. This won't always be the case. In MVC, things are organized into logical categories using namespaces. You could have several in your program.
The second thing to notice is that this class inherits System.Web.Mvc.Controller. That's where the class gets most of its core functionality. Controllers do things that you won't expect coming from a Windows Forms background because those functions are built into the parent.
And the third thing to notice is that the end product of this class is an ActionResult named Greet. The ActionResult types in the non-empty MVC app are named Index and About. The standard CRUD (Create-Read-Update-Delete) functions are all ActionResults in a real world app. List is an ActionResult. The controller classes usually don't do anything. They just decide what gets done next as a result of what they're passed. This one decides that displaying a greeting should be done next. But it doesn't actually display it. That's done by a view.
Once you have coded the controller, you can also create a view by right-clicking the code in the controller.
Click here to display the illustration.
The Microsoft team has done some good work supporting MVC in their development tools. The linkage between controllers and views is one of the more intricate ways that MVC ties together and they've made it somewhat easier. But the dialog window that is displayed next will still raise a lot of questions if you haven't seen it before.
Click here to display the illustration.
To make things easier, I copied a Master Page from another project and then modified it to remove all the things I wouldn't use. A master page isn't required, but it's a good idea. Here's the page I used:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head runat="server"> <title><asp:ContentPlaceHolder ID="TitleContent" runat="server" /></title> <link href="../../Content/Site.css" rel="stylesheet" type="text/css" /> </head> <body> <div class="page"> <div id="main"> <asp:ContentPlaceHolder ID="MainContent" runat="server" /> </div> </div> </body> </html>
You can see that things are still linking together by name. For example, you'll see the ID MainContent again in the view, which we consider next.If you used the dialog to create the view, you will notice that both a Hello folder and a Greet.aspx file in the folder have been added for you. The .aspx files in Views aren't normal .aspx files. For one thing, there is no corresponding .vb code behind file. You don't do any processing in Views, so there is no place to put code. I modified the Greet.aspx file to contain this code:
<%@ Page Title="" Language="VB" MasterPageFile="~/Views/Shared/Site.Master" Inherits="System.Web.Mvc.ViewPage" %> <asp:Content ID="Content1" ContentPlaceHolderID="MainContent" runat="server"> <h1><%=ViewData("Message") %></h1> </asp:Content>
The ViewData object is just a keyed dictionary. In this case, Message is the key. It was created in the controller. A lot of MVC purists don't like this technique because (they say) the controller shouldn't be doing any processing. Because MVC is still under active development, and there are lots of other flavors other than the Microsoft brand, you'll see this sort of debate if you start reading about it.
You might think that you're finished now. You might be wrong. There's still more plumbing to put in place and on the next page, we complete the app.