Creating an On Premise Database and MVC Web Application and Migrating to Windows Azure and SQL Azure-Step 1 of 10

When CIOs begin to consider the reasons why they should embrace cloud computing, one of the key benefits is scalability. IT organizations can quickly and easily grow or shrink depending on the business need at hand.

Essentially, I recommend the customer use MVC and Windows Azure, given these facts:

-Windows Azure provides the scalability for hosting the web application-MVC provides both the (1) separation of concerns, and (2) the ability to perform unit testing-SQL Azure allows us to scale and easily maintain multiple relational databases

The migration path to the cloud will be straightforward. The following steps will be performed:(1) We will create a new Visual Studio Project that is a “Windows Azure Project Type” with one MVC Web Role(2) We will use the SQL Azure Migration Wizard to copy our on-premise database to the cloud in a SQL Azure account that I have previously created(3) We will also make use of the ADO.NET Entity Framework

Notice that we can configure our cloud based services any way we wish. Below we have specified that we want 4 running instances of our MVC application. That means that in the Microsoft data center there will be 4 running instances of a 64-bit Windows operating system that are running IIS, each IIS instance running our MVC application. Windows Azure will automatically load balance across all 4 instances.

Using SQL Azure, you can create new instances of the SQL Azure database. We will use the connection string to connect to the specific instances of our SQL Azure database. Also note that there are 3 copies running as hot backups of our data. Since we have 3 databases, that means we have 9 more running in the background, ready to be called into service when one of our 3 databases encounters errors.

We will start be creating an “on-premise” version of our MVC application. The cloud version will be created in a future post.

One of the reasons we chose MVC is because unit testing is built-in. This great feature of MVC is possible because of the separation of concerns, namely, that we separate business logic from GUI logic.

However, unit testing is not the point of these blog posts. So select “No” below.

Now we are ready to code up the logic for our MVC application. We will only modify 3 files in our MVC project:(1) HomeController.cs – this is the module where code executes when the end-user access the MVC web site using a URL like this, “http://localhost/home/index”

Notice that the string “home” represents the controller (HomeController.cs) and that the string “index” represents the Action Method called “Index().” In other words, this means that “http://localhost/home/index” ends up called the “Index()” method of the “HomeController.cs” controller class.

This screen illustrates that we can change the “ViewData” variable in the controller class. The contents of this variable (ViewData[“Message”]) will be displayed by the “view,” which we will illustrate later. I modified the string to say, “Welcome From Bruno’s Tutorial.”

The point here is to illustrate the default behavior of our MVC application. Note that “home/index” is implied even if it is omitted from the URL.