Saturday, February 9, 2013

Controller


ASP.Net MVC Controller is the fifth post in a series of tutorials which introduces the basics of ASP.Net MVC programming.

You can download the example code for the Model, View and Controller posts here. Visual Studio 2012 is required. If you don't have a copy, you can download a free copy of Visual Studio 2012 for Web.

Previous Posts:
MVC Introduction
HTML Forms
Model
View

Controllers

Controllers are responsible for responding to requests made on an ASP.Net MVC website. On a non-MVC site, a request is made explicitly for a file e.g. http://www.blogger.com/index.html. In MVC the request is made to the controller. Requests are either GET or POST which I reviewed in the second post on MVC.
This can be a difficult concept at first as there is a tendency to think that the View e.g. Edit.cshtml file is what is being requested but in actual fact the Controller is the first port of call and you can decide what view you want to display in the Controller.

Like Models and Views, there is a convention for how Controllers are named and where they are stored. Controllers are stored in the Controllers folder and are generally named to match the object with 'Controller' appended to the end e.g. PeopleController. Notice I am using People and not Person. Plural names are used for Controllers e.g. Cars, Products, People, etc.

If you look in the Controllers folders, there should be two controllers there which are generated from a template. AccountController manages registration and logins and the HomeController is a generic controller that manages the Views in the Home folder which current is the Index and About view.


We will add a Controller for our Person.

To add a Controller, right click on the Controllers folder, select add and then Controller. Name the controller PeopleController.
Select Controller with empty read/write actions as the template.


Like Add View, ASP.Net MVC will scaffold basic code to get started with a Controller.


using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;
using Acme.Intranet.Models;

namespace Acme.Intranet.Controllers
{
    public class PeopleController : Controller
    {
        //
        // GET: /People/

        public ActionResult Index()
        {
            return View();
        }

        //
        // GET: /People/Details/5

        public ActionResult Details(int id)
        {
            return View();
        }

        //
        // GET: /People/Create

        public ActionResult Create()
        {
            return View();
        } 

        //
        // POST: /People/Create

        [HttpPost]
        public ActionResult Create(Person person)
        {
            try
            {
                // TODO: Add insert logic here

                return RedirectToAction("Index");
            }
            catch
            {
                return View();
            }
        }
        
        //
        // GET: /People/Edit/5

        public ActionResult Edit(int id)
        {
            return View();
        }

        //
        // POST: /People/Edit/5

        [HttpPost]
        public ActionResult Edit(int id, Person person)
        {
            try
            {
                // TODO: Add update logic here

                return RedirectToAction("Index");
            }
            catch
            {
                return View();
            }
        }

        //
        // GET: /People/Delete/5

        public ActionResult Delete(int id)
        {
            return View();
        }

        //
        // POST: /People/Delete/5

        [HttpPost]
        public ActionResult Delete(int id, Person person)
        {
            try
            {
                // TODO: Add delete logic here

                return RedirectToAction("Index");
            }
            catch
            {
                return View();
            }
        }
    }
}


The Controller will contain a number of actions which return ActionResults which are a generic class that are returned by controllers. There are more complex return types but they are generally inherited from ActionResult.

The View created in the previous post provides a form for a person to be created. I will concentrate on the Actions for Create only. Notice there are two Create functions. The first is a GET action and he second is a POST action. You can restrict the action to POST by placing [HttpPost] attribute above the action.

As noted in the previous post on HTML forms, GET is primarily used to retrieve data while POST is used to submit data. MVC is a commonly referred to as a RESTful architecture. The client requests resources from the server e.g. a web page, the server then rests and does nothing until another GET or POST action is requested. In between requests, the server goes off and serves other requests. This is extremely efficient and is the significant reason for the success of the internet. Windows applications based on a client server model would run out of memory very quickly if it had to deal with the amount of requests that some web sites have to deal with. This is because windows applications retain a relationship with the client requesting information and must allocate memory for each client.

First, lets look at the GET action. The function will return a View when http://acme/people/create is requested. Hows does MVC know where to find the Create function. Again MVC relies on convention. MVC has a routing mechanism which will be expanded upon in a separate post. If you don't change anything, the following routing applies:

domain/controller/action e.g. http://acme/people/create, http://localhost:1388/car/delete

So MVC looks carefully at the URL and knows that everything after http:// and before the first / is the domain, the next part s the Controller and the last part is the Action. Note, the Controller part is omitted from the URL so PeopleController becomes people. The URL is not case sensitive so people is the same as People.


        //
        // GET: /People/Create

        public ActionResult Create()
        {
            return View();
        } 


The GET action returns a View. For now, think of a view as an empty model e.g. Person. If you want to populate the initial web form with some data, you can initialise a new person object and return it. If we had included a DateCreated field in person:


        //
        // GET: /People/Create

        public ActionResult Create()
        {

            Person person = new Person();
            person.DateCreated = DateTime.Now;

            Viewbag.Title="New Person";

            return View(person);
        } 


         

Now every person is initialised with the DateCreated set to the current date and time.

That is all that is required to show the person on the View. We now need a function to accept the POST action. The following function does nothing really but return the user to a view named Index. Note, the scaffolding that created the controller may have included a FormsCollection object instead of the Person object. Replace public ActionResult Create(FormCollection collection) with public ActionResult Create(Person person) as below:


        //
        // POST: /People/Create

        [HttpPost]
        public ActionResult Create(Person person)
        {
            try
            {
                // TODO: Add insert logic here

                return RedirectToAction("Index");
            }
            catch
            {
                return View();
            }
        }

Also ensure that the namespace which Person belongs to is referenced at the top e.g. using Acme.Intranet.Models;

The POST action returns a RedirectToAction which causes the browser to issue a GET request. In the example above, after the code is completed, the browser will go to the Index view for the Person e.g. http://acme/people/index. You an change this to return RedirectToAction("Edit"); and it will return to the current Edit view.

Important: If the [HttpPost] attribute is not placed above the action, the action method will be assumed to be GET.

Initially MVC may seem like a lot of overhead as there are a lot of new concepts to learn if you have come from ASP.Net forms or scripting languages. The good news is that MVC follows rules and once you become familiar with these rules, it makes life so much simpler.

You can download the example code for the Model, View and Controller posts here.

If you haven't used Visual Studio before, run the Visual Studio application, from the File menu select Oen Project, browse to the location where you extracted the files and select MvcTutorial1.sln. After the application loads, click the F5 button or select Start Debugging from the Debugging menu. The ASP.Net MVC application will open in your default browser. The initial URL will be a series of numbers like http://localhost:49529/. Type People/Create after the URL address e.g. http://localhost:49529/People/Create.
Hopefully you will see a web page similar to below:


Note: The form will not save data yet as we have not added a repository.

Concepts covered

  1. Controllers
  2. Actions
  3. Routing
  4. ActionResult
  5. GET versus POST actions
  6. Initialising objects for Views
  7. Return Views

The next post will review the Model, View, Controller paradigm based on the code so far before introducing a way to save our new Person to a repository or a database.

Friday, February 8, 2013

View


ASP.Net MVC View is the fourth post in a series of tutorials which introduces the basics of ASP.Net MVC programming.

Previous Posts:
MVC Introduction
HTML Forms
Model

Views


IN MVC, Views are what we see and interact with. The view can be a web page on a desktop, tablet or mobile device. The view can also be an app or a console application or any number of options for interacting with an application. ASP.Net MVC controllers supports the concept of returning views which are web pages, but controllers can also return JSON, XML and many other formats which can be consumed by numerous devices. In fact a request to a server can return the same data which can be shown differently depending on the device. The server is not very concerned about what device consumes the data, it just knows a request has been made and data must be processed and return in a particular format. This concept is termed 'separation of concerns' and is a powerful concept that differentiates ASP.Net forms from ASP.Net MVC.

Mobile and tablet devices are becoming more popular than desktop and notebooks and while this has been primarily consumer led until now, this progression is started to take hold in business. Developing separate applications for different devices is a luxury that is difficult to justify for most businesses. There are ways and means to optimise and reduce the server side code but the connection between the user interface and business logic is problematic. MVC has come at a good time for web and mobile based applications.

Razor

As per my Model tutorial, I will be programming in C#. I will also be using Razor as the syntax in the ASP.Net web page. Razor is almost identical to C# if you are using C# for your project and is the code that will be inter-dispersed with your HTML syntax. Razor is relatively new and was introduced with MVC 3. Prior to that a similar syntax was used to that in ASP.Net forms which used <%= %> to distinguish ASP.Net code from HTML. Razor uses an @ symbol which is far easier to read. If you are starting out, I would suggest using Razor otherwise use what ever you are comfortable with. Note - although ASP.Net code is inter-dispersed with HTML which cannot be avoided, I tend to use it cautiously and avoid or minimise placing business logic in the View.

The View

There will be a little more explanation when I get to Controllers but for now think of a view as a web page. In C#, the web page will have an extension of cshtml and in VB.Net it will be vbhtml. The web server will do the necessary processing to convert these files to HTML.

Strongly typed views

MVC3 introduced the concept of strongly typed views. Basically this means each web form is strongly associated with one object e.g. Person, Car, Project. One object = one form. You can have more than one form on a web page in MVC but this can be a little head wrecking in the beginning as there is a tendency to be loose with the data that is retrieved and stored to and from a server. For example if you are working with a SQL database, you can query data for a web page based on joins on many tables and now MVC is restricting you to only one object which is associated with one table in a SQL database. But don't worry, there are techniques to overcome this restriction. You can workaround the strongly typed view concept by using dynamic types but it doesn't make for great coding and you loose the IntelliSense in Visual Studio. I stick to strongly typed views where ever possible as it is a self organising process which produces better outputs.

Standard folders and files

Following the convention over configuration theme, MVC expects certain files and folders to be in the right place. This convention provides great familiarity across projects.

In the Solution Explorer, expand the Views folder. Note the View folder is a standard MVC folder. There will be a number of standard folders and views within the views folder which were generated based on a template.
The Account folder contains views used for logging on to your site. I will cover this in detail on a separate post.
The Shared folder is a standard MVC folder that contains views that are accessible universally. MVC does its best to find an explicitly defined view. If it cannot find it, it will look in the Shared folder. The shared folder is commonly used for templates and common views that occur throughout a web application e.g. advert, the latest news or an error page.
The Home folder is akin to the root folder of a conventional website. The Index file for the website resides here and optionally other files can also. The bulk on the view for a website can be located in the Home folder which is not uncommon for a small web site. Larger sites will contain more folders organised based on object names. ASP.Net MVC does a little bit of MVC magic to route requests from the root index file to the home index file e.g. http://acme/ gets mapped to http://acme/home/index.


In the root of the Views folder is a special partial view named _ViewStart.cshtml. This partial view is used for all views in the Views folder. If you open the file, you will notice one line of code which defines the layout as referencing "~/Views/Shared/_Layout.cshtml". This is basically saying that all views should use _Layout.cshtml in the ~/Views/Shared/ folder for the Layout. A layout is akin to a template.
@{
    Layout = "~/Views/Shared/_Layout.cshtml";
}

Partial Views are prefixed with an underscore e.g. _Layout.cshtml. Partial Views are subsets of Views and are not used to display a web page but can be used to display part of a web page. In the case of the template, they are often used to display the header, menus, footer and so on that are common to all views.

  1. We are going to create a view to allow a person to be created. First create a folder named People under views. Note, the plural is used. Again this is convention.
  2. Then create a View named Create by right clicking on the Person folder, selecting Add and then selecting view.
  3. Select Razor (CSHTML) as the View Engine. Note, you can use a combination of Razor and ASPX (C#) but not in the same view. If you are new to MVC, then select Razor.
  4. Select Create a strongly-typed view. From the Model class pull down list, select Person (Acme.Intranet.Models). This is the class we created in the Model post.
  5. Select Edit from the list of Scaffold templates.
  6. Leave the text box for the layout or master page empty. We are going to use the layout defined in the _ViewStart.cshtml file.





If you used the settings in the form above, you should have the following code. Notice the @ symbol and the @ { } symbols. Razor uses the @ symbol to distinguish C# code from HTML code. @ { } is used to define a block or numerous lines of C# code.

@model Acme.Intranet.Models.Person

@{
    ViewBag.Title = "Create";
}

<h2>Create</h2>

<script src="@Url.Content("~/Scripts/jquery.validate.min.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Scripts/jquery.validate.unobtrusive.min.js")" type="text/javascript"></script>

@using (Html.BeginForm()) {
    @Html.ValidationSummary(true)
    <fieldset>
        <legend>Person</legend>

        <div class="editor-label">
            @Html.LabelFor(model => model.FirstName)
        </div>
        <div class="editor-field">
            @Html.EditorFor(model => model.FirstName)
            @Html.ValidationMessageFor(model => model.FirstName)
        </div>

        <div class="editor-label">
            @Html.LabelFor(model => model.LastName)
        </div>
        <div class="editor-field">
            @Html.EditorFor(model => model.LastName)
            @Html.ValidationMessageFor(model => model.LastName)
        </div>

        <div class="editor-label">
            @Html.LabelFor(model => model.Age)
        </div>
        <div class="editor-field">
            @Html.EditorFor(model => model.Age)
            @Html.ValidationMessageFor(model => model.Age)
        </div>

        <div class="editor-label">
            @Html.LabelFor(model => model.Height)
        </div>
        <div class="editor-field">
            @Html.EditorFor(model => model.Height)
            @Html.ValidationMessageFor(model => model.Height)
        </div>

        <p>
            <input type="submit" value="Create" />
        </p>
    </fieldset>
}

<div>
    @Html.ActionLink("Back to List", "Index")
</div>


MVC used Scaffolding to automatically generate the above code. Scaffolding was popularised by Ruby on Rails and is very useful for generating common code that occurs in CRUD (Create, Read, Update, Delete) operations.

At the top, the strongly typed view is defined by the @model statement. @model Acme.Intranet.Models.Person basically says that this form is is strongly typed to the Person object.

ViewBag is like a super variable that was introduced in MVC 3. Prior to MVC 3 ViewData was used. If you are new to MVC, you can ignore ViewData for now as they are used for similar functions. ViewBag can contain just about anything you want it to. It can store an object, a collection of objects, a simple string or integer or an array. ViewBag goes against the principals of MVC so a little care needs to be taken when using it. I will expand of ViewBag in the Controllers post.

Notice that many of the Razor code lines start with @Html. MVC contains items called Html helpers which are a set of defined functions that automate the generation of HTML code. Unlike ASP.Net forms, in MVC the automation is at a more granular level and importantly can be overridden or extended.


@Html.BeginForm() - This will output standard HTML for a form.
@Html.LabelFor - This will create static text for a label.
@Html.EditorFor - MVC will output the best html form element i.e. Input type="text" for strings such as Firstname
@Html.ValidationSummary - Displays a message if the form field is incomplete or has an invalid input. I will cover this in detail in a separate post.

The form contains a standard HTML submit button.

Outside the form, at the bottom of the view is a simple Html.ActionLink helper. This will create a hyperlink to another view, one named Index in this case. Html.ActionLink will be covered in a separate post but for now you can create simple links to other views using Html.ActionLink providing two parameters, the first being the text to display in the hyperlink and the second being the View name. @Html.ActionLink("Edit Employee", "Edit")


Concepts covered

  1. Seperation of Concerns
  2. Razor
  3. Strongly Typed Views
  4. Standard MVC View folders
  5. Partial Views
  6. _ViewStart.cshtml file
  7. Scaffolding
  8. CRUD (Create, Read, Update and Delete)
  9. Html Helpers
  10. ViewBag
Although our view is quite simple, it is sufficient for us to present a View that will create a Person. We still need a Controller to complete the MVC pattern for it all to work. The next post will introduce Controllers.


Sunday, February 3, 2013

WCF versus ASP.Net API

This is a slight diversion from my ongoing ASP.Net MVC tutorial but there is relevance even if it may not seem like light reading.

I just sat down this morning to familiarise myself with Windows Communication Foundation or WCF for short. WCF is a framework for building service oriented applications and allows data to be sent asynchronously from one service to another. The client can be a web page, a mobile application or a desktop application such as Microsoft Excel. I was beginning to wonder why I hadn't delved into it previously as my final year project at Trinity College in 2001 was based on loosely coupled web services which I used to develop an Enterprise Resource Planning system. WCF hadn't yet come on the scene in 2001. Microsoft were busy developing Simple Object Access Protocol (SOAP) which is a specification for exchanging messages using XML.

Microsoft combined SOAP with Web Services Description Language (WSDL) to produce WCF which integrated web services into windows applications. It did solve many issues of previous messaging systems such as a single programming model which could be extended to support future transport protocols and messaging formats. I had considered SOAP in my final year project but at the time it was relatively new and there was significant overhead over XML over HTTP which at the time appeared to be a very lightweight and flexible alternative. Most of my applications were web based, so I developed my own little framework at the time using XMLHTTP, Javascript and Classic ASP which worked really well and was flexible enough to adapt to most problems that confronted me. AJAX came out a couple of years later as a formalisation of the XML over HTTP framework, made popular by Google. With the popularity of the web, the lightweight frameworks became popular especially for non critical applications.

When ASP.Net 2.0 came along, I started to look into it as the the missing link in my application was an Object Oriented approach to the business logic. Perhaps having come from a lightweight and flexible approach to web services, I found ASP.Net very heavy and disorganised. With ASP.Net, although I could now create classes for my objects which I felt was important to put some order on my business logic, I considered the tight binding of the User Interface and the business logic through the code behind method to very messy. ASP.Net seemed OK for very small applications but led to a lot of redundant code for larger applications. My lightweight application using XML over HTTP continued to do the business so it is unlikely that WCF would have interested me. With a little influence from Ruby on Rails, thankfully Microsoft redeemed themselves with ASP.Net MVC. And now with .Net 4, Microsoft have delivered Web.API which is very interesting.

After doing a little research into WCF, I started to wonder if there are more than a  few confused developers out there since Microsoft's decision to move Web API from WCF over to ASP.Net MVC. Have a look at Microsoft's 2006 article 'Future of ASP.Net Web Services in the context of Windows Communication Foundation' versus Microsoft's recent roadmap for Web API. Clearly Microsoft's focus has shifted towards web technologies and HTTP is now clearly the protocol of choice.

If HTTP is your preferred transport protocol, for the most part the same end result can be achieved using both Web API and WCF frameworks as WCF now supports HTTP and RESTful web services. Once you have invested in a technology such as WCF, you are less inclined to make any sudden moves to the latest technologies as the bleeding edge can be more than slightly uncomfortable. Microsoft realise this and will continue to support WCF but it is starting to become clear that there are two camps emerging, the ASP.Net/WCF and MVC/Web API.

My personal preference is MVC/Web API but I am slightly biased towards the MVC framework, also because I have not put considerable investment in ASP.Net but importantly because of the pure simplicity of MVC. MVC has simple convention rules which imposes structure on applications that has enormous benefit for projects especially for large teams. Being able to look at a project you are not familiar with and immediately knowing where the models are, that all data access is contained in neat data repository files for each model and the UI contains the minimum of business logic thus allowing the UI guys and girls to be creative without the overhead of intermingled code. Now extend this slightly and you get an asynchronous messaging system. This is where convention over configuration comes into its own. Web API supports numerous clients including Web, Mobile and desktop applications and is likely to extend further as the end service only needs a URL and the ability to consume popular formats such as XML, JSON and a range of other formats. Due to the general popularity of the OAuth framework for open standard authorisation and Microsofts integration of OAuth2 in MVC4, it appears to be gaining popularity for securing Web API messages. The concepts of OAuth should be familiar for anyone who has used payment systems such as PayPal. A full list of applications that support OAuth can be found on Wikipedia.

Summary
ASP.NET API is a framework for building non-SOAP based services over HTTP only whereas Windows Communication Foundation is designed to exchange SOAP-based messages using variety of transport protocols like HTTP, TCP, NamedPipes or MSMQ etc. If you need to support a variety of transport protocols, or the slower performance of HTTP is a consideration, WCF will continue to be the popular. ASP.Net API is certainly one to watch as the web gains popularity as the platform for business applications.

Sunday, January 27, 2013

Model

ASP.Net MVC Model is the third post in a series of tutorials which introduces the basics of ASP.Net MVC programming.


Previous Posts:
MVC Introduction
HTML Forms



The best way to learn is by doing, so I will run through how to create a class which will be used in the next couple of posts to create an MVC application that retrieves and stores data to a SQL database. If you have used Object Oriented programming techniques before, this will be straight forward.

You will need Visual Studio IDE for the examples. If you don't have Visual Studio, you can download the express version. It has some limitations but is free and is more than sufficient for learning. I will assume no Object Oriented programming experience and C# will be the language used. If you wish to use VB.Net, the developerFusion converter tool maybe useful for converting C# to VB.Net if you are not familiar with both. The code will be straight forward so it should convert without any issues.

Model Concept

The M in MVC stands for Model. The Model is a class just like a class in any other Object Oriented programming language. You can create a class for Person and create instances of person e.g. Michael Earley which can be used to populate forms in a web page (the View).

Object Oriented programming is kind of big for web design as for a long time scripting languages such as ASP and PHP were the main way to control information on the server side and had very limited Object Oriented capabilities and at best it was forced. ASP.Net Web Forms can be programmed using Object Oriented techniques but their are no rules or conventions for how this should be done which an be difficult for web designers and programmers who are new to ASP.Net.

Exercise

Start up Visual Studio (or Visual Studio Express for Web). From the File menu, select New Project.



Select ASP.Net MVC 3 Web Application as the template. When prompted, select Internet Application as the template. Ensure Razor is selected as the view engine.


A basic but functioning MVC project will be created. Before we do anything else, we will change the Default namespace. The reason for this will become apparent shortly. Right click on MvcTutorial1 in the Solution Explorer and select properties. Lets pretend we are creating an Intranet application for a company named Acme. Change the Default namespace to Acme.Intranet.



Again in the Solution Explorer, there will be a number of standard MVC project folders. Models, Views and Controllers are standard MVC folder names. If you expand the Models folder, you should see an AccountModel.cs class file which is created as part of the ASP.Net MVC 3 Web Application template.

Right click on the Models folder and select Add -> Class. Name the class Person.cs. All classes in C# have .cs as the file extension.


Your Person class should look like this:


using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;

namespace Acme.Intranet.Models
{
    public class Person
    {
    }
}

The class includes some standard namespaces at the top. The namespace are like containers for similar classes. You could potentially have objects of the same name in separate namespaces e.g. Acme.Person and Horizon.Person but the same class name cannot exist in the same name space. This avoids naming conflicts with classes. A commonly used convention is to use Company.Product as the default namespace for applications. Remember, we named our Default namespace to Acme.Intranet. If we want to use Person i other classes, we can type Acme.Intranet.Person. Normally to avoid having to place Acme.Intranet in front of every declaration of the Person class, you can include a reference to the namespace at the top of the class e.g. using Acme.Intranet.

Our class is named Person. Pascal casing (first word capitalised) is the standard convention for naming classes in C#. Always use meaningful names for classes, don't abbreviate the name and never use plurals. Examples of good class names: Employee, EmployeeType, EmployeeWorksOn, Project.

The Person has no properties yet. Properties are accessible values of a class. Lets add a FirstName, LastName, Age and Height.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;

namespace Acme.Intranet.Models
{
    public class Person
    {
          public string FirstName { get; set; }
          public string LastName { get; set; }
          public int Age { get; set; }
          public float Height { get; set; }
    }
}

You will notice that each property starts with public. This is an access modifier and if it is set to public, it tells other objects that property is accessible. The other popular options are private and protected. Private allows this class only to access the property whereas protected allows only this class and any sub classes to access the property. For now we will use Public for properties.

The next attribute of a property is the type. FirstName is a string and Age is an integer (or int in C#). It is important to get the type right especially for numbers which can be classified by the number of decimal places or the size of the number. int is suitable for Age as it will be a whole number e.g. 29. I will use float for height as it allows me to store decimal places as I wan to store each persons height in metres e.g. 1.76m.

The property name should be descriptive and unique to the class. Pascal case should also be used for properties. Don't use any spaces in the property names e.g. First Name converts to FirstName.

{ get; set; } is a C# auto-implemented method for getting and setting the properties. The get and set functions can be extended but for now we will keep it simple as all we want to do is get and set the values.

Concepts covered

  1. Namespaces
  2. Object Oriented Programming
  3. Class
  4. Access Modifier
  5. Type
  6. Naming Conventions
  7. Auto-implemented Get and Set properties
Although our class is quite simple, it is sufficient for our first MVC model. The next post will introduce Views.



Sunday, September 30, 2012

HTML Forms


ASP.Net MVC HTML Forms is the second post in a series of tutorials which introduces the basics of ASP.Net MVC programming.

Previous Posts:
MVC Introduction


As noted in my first post, ASP.Net MVC relies heavily on traditional web forms, the ones that have been around since HTML was invented.

Web forms allow form data from inputs such as text boxes, radio buttons, checklists, etc. to be sent to a server for processing. Actually, you can send form data to another HTML page or the same HTML page but to be really useful, data is sent to a server to either store or retrieve data or both.

A common example is entering registration details for a website. You enter you name, email address and password. The details are sent to a server. If the data is valid, a connection a database is made and the data is stored. The server can then redirect the user to a successful registration page or directly into the contents of the website. Otherwise if the data or part of it is invalid, the user is prompted with a warning. Validation can happen on the server or the client or a combination of both client and server. Checking if the user completed the name field could be checked on the client but checking if the user name is already taken can only be checked on the server through a query on the data store of users.






Every HTML form should contain the following attributes:

Name

The form name must be unique for each form on a HTML page. Each HTML page can contain more than one form but each form can only have one submit button.

Action

The action attribute tells the form where to send the form data. The action should refer to a server side form such as an Active Server Page or a PHP page. The server should have software to process the server pages. Microsoft IIS can process .asp pages and with additional add-ons can process other types of pages such as .php. Apache is a common web server software for .php pages and is available for Windows, Unix an MAC servers. Note: If the Action is omitted, the page will submit the form data to itself.

Method

The method can either be GET or POST. The GET method appends the form data to the address of the action when the form is submitted. in the above example form the address may end up looking like this:

http://www.mysite/registeruser.asp?name=michael&email=michael.earley@me.com&password=mvc&confirmpassword=mvc

There is a glaring problem with the GET method. The password is included in the web address which is not a secure way to submit a password. The POST method on the other hand submits the form data without appending it to the web address.

POST should be used generally for form data and GET should be used for search queries e.g. http://www.mysite.com/search?name=Michael. POST queries are useful because they can be bookmarked or written as url addresses. For example you could output an array of links each with a different url depending on the users in a database e.g. http://www.mysite.com/search?name=Michael, http://www.mysite.com/search?name=Tom, http://www.mysite.com/search?name=Sue, etc.

Be careful. If you don't include a method for a form, the default is GET.

HTML Form Example

The following is an example of a simple registration form which posts to itself. Create a HTML file named registeruser.html using the following code. Notice the page sends data to itself by appending the form data to the URL.




<html>
<head>
     <title>Registration Form</title>
     <link rel="stylesheet" type="text/css" href="style.css">
</head>

<body>
<form name="registrationform" action="registeruser.html" method="GET">
<p>Registration Details</p>
Name: <input type="text" name="username"><br>
Email: <input type="text" name="email"><br>
Password: <input type="text" name="password"><br>
Confirm Password: <input type="text" name="confirmpassword">
                        <input type="submit" value="Submit">
</form>
</body>
</html>


In a client server situation, the action would refer to a server page e.g. register.asp and the method would be POST to avoid having the password appear in the URL.

HTTP versus AJAX HTTP

The client passes data to the server using HTML forms through a combination of POST and GET methods via HTTP or AJAX (Asynchronous JavaScript and XML ) HTTP. AJAX allows for a more fluid experience with forms as the entire web page does not need to be refreshed giving a more windows form experience. AJAX does require a little extra code over traditional HTTP methods.


In Classic ASP and PHP, this is how things worked and it works well up to a point, well the point where there are too many forms and files to maintain. Websites often start off with one client page and a separate server page to process form requests and then maybe another to confirm the request. Large websites can end up with hundreds of files in lots of folders which become difficult to maintain. The business logic ends up spread across many files which makes code difficult to mantain and change.

ASP.Net Forms versus ASP.Net MVC

Microsoft introduced ASP.Net Web Forms in 2002 as the successor to Active Server Pages in an effort to improve upon HTML forms. While ASP.Net forms looked good in theory, in practice it was a backward step for web development. State Management was introduced to overcome the short comings of the HTTP Protocol which by design made web client server communications stateless. The desire by Microsoft was to make web development more akin to Windows forms development for which there were numerous developers trying to break into web development. Thankfully, Microsoft have absolved themselves with the introduction of ASP.Net MVC and a return to stateless development or a Restful Service as it is often referred to now.

Restful Service

MVC is a Restful Service. This means that once a request is made to a server, the server deals with the request and may return data to the client. Once that is done, the server forgets about the client literally. Any additional requests are completely independent of the last request and must include everything required to compete each request. The server doesn't even remember the users credentials for each request but there are ways to standardise how this information is included with each request to minimise code.

Summary

HTTP or AJAX HTTP actions are the method of communication for ASP.NET MVC forms. Understanding the difference between GET and POST is very important to understanding MVC as it is heavily reliant on these methods for communication.

To progress to Controllers which I will cover next, you will need to have the necessary software installed for MVC. My next blog will go through what is need to get you up and going. The good news is that the software is free.

Happy coding.

Michael




Monday, May 28, 2012

MVC - Introduction

Introduction

Welcome. This is my first blog on Model View Controller (MVC). I am blogging about it because I love programming in MVC so hopefully you will learn from my experiences. I also maintain a blog on Building Information Modelling (BIM) called BIM Manager, as aside from programming I have a passion for Architecture also. I think this puts me in a very small but growing group of individuals.

Through a series of posts over the next few months I plan to cover topics on MVC, Databases, Entity Frameworks (stuff that connects MVC and databases) and jQuery (very smart JavaScript). I may wander into other interesting MVC and Object Oriented related stuff but will try to keep focused.

MVC

MVC stands for Model View Controller. MVC is a bit of a buzz word at the moment as it is recently increasing in popularity. But what is MVC?

MVC is a pattern based framework for building applications. Software systems use MVC to basically put manners on code by ensuring code abides by strict rules. With a little bit of time and some coffee, you could even develop your own MVC pattern but there are plenty of good patterns out there and life is about more than just programming. MVC is a pattern or a set of rules. Applications such as Ruby on Rails, iOS and ASP.NET MVC now have some very well defined rules for how MVC code is structured. MVC is not new as it has been around since 1979 and was originally named Thing-Model-View-Editor.You will now find MVC in many applications both for the web and desktop. For example, if you plan to write an app for an iPhone, you will need to use MVC. Many organisations are using MVC to simplify very complex applications and websites.

I primarily develop web applications and also dabble in desktop and iPhone development. I started web programming in VB and Classic ASP which for a long time got a lot of productive programming done. When I switched to ASP.Net, I had great hope that it would remove some of the repetition involved in scripting while promoting reuse through Object Oriented programming. The reality was not so good. ASP.NET added so much baggage trying to make web sites work like windows based applications, that I soon was fed up and used it sparingly. I looked at a few bolt-on applications such as Devexpress for Visual Studio to automate some tasks but it was still clunky. The viewstate functionality of ASP.NET especially annoyed me, this wasn't web development any more.

I started to look at Ruby on Rails which has led the way in web MVC programming and then came across ASP.NET MVC which was still at the early stages of development. I found the Model View Controller a bit puzzling at first, but soon things started to click as I realised I was relearning the basics of HTML again. I was also starting to learn iOS programming for the iPhone/iPad online from Stanford University and was surprised that MVC was being used here also. Ruby on Rails is a great programming environment and credit must be given to David Heinemier Hansson for having the insight to bring MVC to the web. HTML has recently evolved to version 5 is now changing the web again with the introduction of media related functions that were long needed. It is exciting times indeed to be looking at MVC.

I opted to develop in ASP.NET MVC mostly because I was familiar with Microsoft applications and also because I program for AutoCAD and Revit which until recently were solely Windows based. I switched most of my programming tC# when I started MVC as most of the material and samples on the web were C#. VB will work just as well and there are websites that will convert VB to C# and vice versa.

Onward and Upward

Slightly convinced? Try MVC out, you won't regret it. It is suitable for beginners or experienced programmers alike.

I would recommend learning some basics of HTML first. W3Schools and HTML Goodies are excellent web sites to get you started on basic HTML and JavaScript. Many tutorials and books start with the Model or the View but my first meat and bones post will look at the HTML form. Yes, this is the basic HTML form that has been around since the beginning of HTML. MVC relies surprisingly heavily on HTML forms. I will include code with each post and build up to a useful everyday application.

Enjoy.