[HttpPost]
        public JsonResult GetOfferings()
        {
            offerings = new OfferingRepository();
            offerings.GetOfferings();
            offeringTypes = new OfferingTypeRepository();
            offeringTypes.GetOfferingTypes();
            return Json(
                new
                {
                    Offerings = offerings.Offerings.Select(t =>
                        new
                        {
                            OfferingName = t.OfferingName,
                            OfferingId = t.Id
                        }),
                    OfferingTypes = offeringTypes.OfferingTypes.Select(t =>
                        new {
                            OfferingTypeName = t.OfferingTypeName,
                            OfferingTypeId = t.Id
                        })
                });
        }

This morning I started reading up on the ASP.NET MVC 2 processing pipeline, which differs quite a bit from ASP.NET Webforms. Its important to understand the processing pipeline because it allows you to implement custom functionality such as your own Controller factory. Understanding the processing pipeline is also important because you understand what is possible and what not.

Webforms use a page life cycle whereas ASP.NET MVC starts off by processing an incoming request which it first tries to match up  with a file on disk. If it finds that the incoming request maps to a physical file it serves the physical file. If however it finds that the incoming request is for a .NET type that implements IRoutehandler, it looks in your Global.asax file at the routes in your RouteTable and looks to see if the request matches any of the route entries. MvcRouteHandler then knows how to take the request and invoke the relevant controller class. The controller is a class that inherits from a class called Controller which exposes the methods within that class to action methods, i.e. they can implement ActionResults or ViewResults which is rendered by a viewengine.

I think that describes the execution pipeline quite well.

public class PagingInfo
{
	public int TotalItems { get; set; }
	public int ItemsPerPage { get; set; }
	public int CurrentPage { get; set; }
	public int TotalPages
	{
		get
		{
			return (int)Math.Ceiling(decimal)TotalItems / ItemsPerPage;
		};
	}
}

In the controller in his book he then creates a class called, ProductsListViewModel, which has two properties, IList Products and PagingInfo PagingInfo:

public class ProductsListViewModel
{
	public IList
 Products { get; set; }
	public PagingInfo PagingInfo { get; set; }
}

On a side note I must say I agree in part with Jeffrey Richter in his book C# via CLR that properties are a weird mix of a method and not a method and sometimes it does feel as if what you are doing in a property might work in a method also. But I digress. In his controller he has a action result that binds the ProductsListViewModel to the view:

public ViewResult List([DefaultValue(1)] int page)
{
	var productsToShow = productsRepository.Products;
	var viewModel = new ProductsListViewModel
	{
		Products = productsToShow.Skip((page - 1) * PageSize).Take(PageSize).ToList();
		PagingInfo = new PagingInfo {
			CurrentPage = page,
			ItemsPerPage = PageSize,
			TotalItems = productsToShow.Count()
		}
	}
	return View(viewModel);
}

Before I continue there are a few things to note about the controller method and the first is that I have not shown the productsRepository and its implementation and the second thing to note is that PageSize is a public variable declared in the controller class.

The code works great, and I have used it now in several places and I really like it because it feels as if the PagingInfo class provides an abstraction that the entity you are paging does not know about. This makes it feel light and easy to implement. I do however think it might be useful to create a class that accepts a generic type instead. So what I have done is create a class called EntityViewModel, and it looks a bit like this:

public class EntityViewModel
{
	private List listOfEntities;
	private PagingInfo pagingInfo;

	public List ListOfEntities
	{
		get { return listOfEntities; }
		set { this.listOfEntities = value; }
	}
	public PagingInfo PagingInfo
	{
		get { return pagingInfo; }
		set { this.pagingInfo = value; }
	}
}

This will mean that when I create a controller method I can do this instead:

public ViewResult List([DefaultValue(1)] int page)
{
	var productsToShow = productsRepository.Products;
	var viewModel = new EntityViewModel
	{
		ListOfEntities = productsToShow.Skip((page - 1) * PageSize).Take(PageSize).ToList();
		PagingInfo = new PagingInfo {
			CurrentPage = page,
			ItemsPerPage = PageSize,
			TotalItems = productsToShow.Count()
		}
	}
	return View(viewModel);
}

Which to me seems a bit more flexible. It doesnt end there though because I want to consume the controller method using jQuery and jQuery templates and for that I need to change the controller method slightly:

public JsonResult List([DefaultValue(1)] int page)
{
	var productsToShow = productsRepository.Products;
	var viewModel = new EntityViewModel
	{
		ListOfEntities = productsToShow.Skip((page - 1) * PageSize).Take(PageSize).ToList();
		PagingInfo = new PagingInfo {
			CurrentPage = page,
			ItemsPerPage = PageSize,
			TotalItems = productsToShow.Count()
		}
	}
	return Json(viewModel);
}

Now I can get a JSON result, AND it has paging which is totally awesome!

ASP.NET MVC 2 uses the Webform rendering engine and ASP.NET MVC 3 uses the Razor rendering engine. You can read more about the Razor view engine on Scott Gu’s blog, but essentially it boils down to is the way in which dynamic content and html is rendered and how your view engine deals with it.

Today I started reading up on ASP.NET MVC 3 and Razor, starting here because I wanted to get a better understanding of how layouts work in Razor and also how I could leverage some of its cool functionality specifically for a CMS. Before I continue discussing how I could see myself building a CMS using Razor, I want to define what I would want from a CMS and what I would want it to do. Consider this my requirement statement, my way of defining the nature and functionality of the CMS.

I want a CMS that is flexible enough to handle multiple page layouts without having to create static pages. In other words I want to create a CMS that allows me to add pages from scratch without having any static views in place. I just want to be able to create pages using different templates. So if my only view is the home view, then every subsequent page that I add will essentially be part of a ViewResult within the HomeController, and if pages are nested the ViewResult should reflect that. A page can have a parent or child page, nth levels deep. The basic workflow for adding a page to a CMS could be:

1. Select a page Template
2. Select a layout
3. Populate regions within layout with content
4. Save the page

Apart from this basic functionality the CMS should provide a way to integrate “datasets” or strongly typed data items into a page, style the data items and provide cascading pages if required without the CMS having to know anything about the data item it is cascading. If you have a product and it has several entities associated to it then you might want to create separate pages based on those entities, but then it means you have to specify the page and page layouts for the cascading items. It also depends on what type of layout that data item has.

1. Don’t do ANY UI manipulation in any of my server side API’s. The sole purpose of any API within the applications I build is to deal with business layer logic and the data related to it. Ideally speaking I would want my API to return structured data which is easily transformed into a format for the client application using the API (e.g. JSON). I have had experiences within another development team in the recent past where the API returned HTML with the data and to say that this is a mess is understating the obvious – if you think about it quickly then you can understand the impact of one style or layout change will have on this approach. It also blurs your application in terms of its concerns and makes testing a problem. So ideally I dont want any UI logic in any of my API’s.
2. The second objective I have is that all my UI for web applications must be handled with client-side scripts. Client side includes both static HTML, CSS and JavaScript, and in this instance I specifically refer to JavaScript and the handling of my API’s data using JSON, for which I use jQuery. The REST (:D) of this article is dedicated to the AJAX options available in an ASP.NET application.

Dealing with AJAX in an ASP.NET Application

Developing ASP.NET applications gives you two “frameworks” or “architectures” to work with:

1. ASP.NET Webforms
2. ASP.NET MVC

Notice that each architecture or framework uses the ASP.NET runtime which in turn runs on the .NET framework, and part of the .NET framework is the Common Language Runtime (CLR). People often think ASP.NET automatically refers to webforms. The difference between the architectures lies both in how it was designed and who it was designed for. Webforms was designed for Windows Forms developers working within the Visual Studio drag-and-drop environment and aimed to provide an abstraction of Windows Forms for the web. With webforms you could simply drag and drop controls onto a design surface and assign properties to the controls. The problem with webforms was that it required state management and to deal with the state management viewstate was created. Basically state management refers to a controls ability to retain its “value state” across postbacks. So if I created a simple label and set its text to “hello world” viewstate is used to retain that text value throughout the life of the rendered page. Webforms also introduced the concept of the Page Life Cycle, which exposed certain events at certain points of the page’s rendering process. The problem with viewstate is that the viewstate is inserted into your HTML pages which causes the page to bloat – so there is no clean markup. Viewstate totally goes against the grain of how the web works – being stateless.

ASP.NET MVC addresses some of the issues associated with webforms by using a mature and well known architectural pattern – Model-View-Controller, as used in Ruby-On-Rails. ASP.NET MVC does not use the page lifecycle for a start and it embraces the web’s statelessness instead of fighting it. The result is that you have no ViewState and this means that there is no HTML bloat and you also have complete control over your HTML.

There are a couple of ways to consume AJAX requests in ASP.NET but they fall into two categories:

1. SOAP
2. REST

In my previous development role I worked with guys that used SOAP to do AJAX requests and although this approach was good enough it was specifically aimed at ASMX web services which meant adding web references to your project. Needless to say adding these reference is a pain in the ass, because if a new method was added to a service you had to first update your reference before you could see the method. REST, however, addresses this issue by allowing you to make calls to URL’s, and not by adding any references. It also means that if a new method is created its available immediately. The remainder of this article is about consuming REST-like services in an ASP.NET application.

With my latest development effort I started out by using Page Methods in an ASP.NET Webform application. Why ASP.NET webforms you may ask? Well I wanted to focus on the business value and I just started out with Webforms without concerning myself too much with the technical side of things. Page methods implement a REST-like architecture and simply requires that you add a WebMethod attribute in your code-behind’s CS file like this:

    [WebMethod]
    public static Dictionary> GetLastSixMonthReport()

You could then access the web method through jQuery like this (notice the Default.aspx/GetImportsLastSixMonths):

    $.ajax({
        type: "POST",
        url: "Default.aspx/GetImportsLastSixMonths",
        data: "{}",
        contentType: "application/json; charset=utf-8",
        dataType: "json",
        success: function (msg) {
            var dict = msg.d;
            var html = '';
            $("#importsData").empty();
            html += dict;
            $("#importsData").append(html);
        }
    });

The main issue I have with this approach was that if I wanted to create a new web project I had to re-create the web methods – which is not ideal. So if I wanted to move this project over to a new MVC app I would have to recreate the methods. Based on this I decided to create a separate WCF project that could host all my methods and deliver them in a REST-JSON way. To get WCF to deliver JSON in a REST fashion you need to do two important things:

• Configure it
• Add the appropriate Interface attributes

Configuring a WCF service for JSON requires that you add an endpoint address to the service itself like this:

You also need to add an endPointBehavior like this:

In your service behaviours you need to set httpGetEnabled to true as well. I added this in my service class:

[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]

In service contract I added the WebInvoke attribute to each method, like this:

    [OperationContract]
    [WebInvoke(Method = "GET", BodyStyle = WebMessageBodyStyle.Wrapped, ResponseFormat = WebMessageFormat.Json)]
    ProductCollectionView[] GetProductCollectionViews();

Once I set this up I could access the JSON-enabled endpoint: http://localhost/LRB2CServiceLayer_v1/LRB2c.svc/ajaxEndpoint/GetProductCollectionViews and I would see the JSON. Notice that the JSON comes with a MethodNameResult as opposed to the “d” from the page methods. Consuming it uses a similar approach to the jQuery for page methods, except that you use a GET (which is a little dodgy):

    $.ajax({
        type: "GET",
        url: "http://localhost/LRB2CServiceLayer_v1/LRB2c.svc/ajaxEndpoint/GetProductCollectionViews",
        data: "{}",
        contentType: "application/json; charset=utf-8",
        dataType: "json",
        success: function (msg) {
            var dict = msg["GetProductCollectionViewsResult"];
            var html = '';
            $("#importsData").empty();
            html += dict;
            $("#importsData").append(html);
        }
    });

I decided to convert the WCF service to a class library (DLL) instead because I had all kinds of issues with XSS because I ran the WCF service as a separate web application. The idea was that a WCF service was easily shared between web apps. I basically combined the class library with a MVC web app instead. A class library can just as easily be shared among multiple projects or web sites. The JSON that MVC returns is different to WCF and Webforms – it just returns the object, no indexer/key such as “d”. Getting MVC to return JSON is pretty straight forward:

        [HttpPost]
        public JsonResult GetGetProductCollectionViews()
        {
        }

Of the three methods/technologies I described I like the ASP.NET MVC approach because:

• Its RESTful
• The JSON result only contains the object(s)

The reason I am looking at using agile as a development methodology is because I want to develop a commercial product using ASP.NET MVC and as Phil Haack says in this article:

Notice that at this point, we’re focusing on the behavior of our app first rather than focusing on the UI first. This is a stylistic difference between ASP.NET MVC and ASP.NET WebForms. Neither one is necessarily better than the other. Just a difference in approach and style.

And from that I gather that ASP.NET MVC was designed to work well as a unit testing platform as well. I started about 3 weeks ago to formalise my development process and I started out by defining agile to have the following steps:

• Start off by Planning a work item
• Do a requirements analysis of the work item and identify what you will need to do to get it working correctly
• Design the code/program
• An iteration then begins:
  • Write the code
  • Write a unit test
  • Do an acceptance test

I am having to change my development process though, because I intend to use Team Foundation Server (TFS) as my source control system, and I was thinking that maybe I need to consider using MSF (Microsoft Solution Framework) to drive my development process. MSF is integrated into TFS, and it essentially means that you can build applications and do source control within a development methodology. I started off looking for stuff on MSDN and searched for this and came across this presentation. From this presentation I understood that the agile process is structured a little differently to what I did in my initial process definition. Each iteration in a MSF consists of:

• Envision
• Plan
• Build
• Stabilize
• Deploy
• Continuous

Iterations occur at various steps and its up to the project manager to determine how many iterations occur. MSF also promotes a daily work cycle, which essentially makes sure that your code is of an acceptable standard. Essentially you check-in each day, make a build, make sure its an acceptable build and then you continue the develpment process within an iteration. This process repeats daily. Within the iteration cycle there are several other iterations which aim to achieve a pre-determined level of quality, based on planning of feature sets. The iterations also act as a mechanism to correct a project plan if there are deviations. The iteration is broken up into iteration cycles, with iteration 0 consisting of a project setup plan followed by a first iteration that involves planning, developing, testing and getting feedback followed by an nth number of iterations that involve planning, developing, testing and feedback. The last iteration is a set of nth iterations that involve developing, testing and releasing the product. You have to view these iterations as a set of ‘refinement’ iterations, each iteration is intended to refine the solution. You also have to view these iterations in relation to the iteration steps mentioned above. In the powerpoint presentation they present a very cool view of the iterations as they happen.

Iteration 0

At the top they start off with the envision stage that includes the writing of a vision statement and the identification of personas within your system. Once that is defined you have to determine an iteration length. At the planning stage of the iteration you have to access/assess project progress, which is a continual thing I assume. Within the build stage you must start off by creating a scenario through brainstorming. You must also create a Quality of Service scenario through which you create a QoS. At this stage you must also refine the personas. The scenario that you created previously requires that you prioritise the scenario list, each with a scenario description. You need to prioritise QoS as well and write a QoS requirement. From the scenarios that have been written you need to create a solution architecture that partitions the system. You also need to storyboard the scenario, and develop a performance model. You also have to identify the security objectives, and then you need to test the scenario by defining a test approach.

On the next level you have to determine the interface. Does this mean the actual UI? You also need to plan an iteration at this stage by estimating a scenario or QoS. Then you need to develop a threat model. On the next level you need to plan an iteration around scheduling a scenario. From this you can develop an architectural prototype. You also need to plan an iteration around QoS and then create a infrastructure architecture. At the next level/step you plan an iteration around dividing the scenario into tasks, that make up a dev task which is then costed, and the same strategy is applied to QoS.

From the diagram in the powerpoint I assume that you can repeat as many iterations as you want.

Iteration 1

Iteration 1 includes writing a QoS test and writing a validation test for testing your scenario. It also includes doing a code check-in to your source control. It contains stages/levels that require you to write code for a development task, as well as creating an update of a unit test. It also covers fixing bugs:

• Reproducing the bug
• Locating the bug cause
• Deciding on a bug fix strategy
• Reassign the bug
• Create of Update unit test
• Code the fix
• Perform unit test

Implementing a development task covers the following:

• Create of Update Unit Test
• Write code for dev task
• Perform Unit Test
• Perform Code Analysis
• Refactor code
• Integrate Code Change

After this stage there has to be a build and an accepted build. In the build there will be:

• Start a build
• Verify a Build
• Fix a build
• Accept Build

An accepted build will revolve around testing scenarios and in particular:

• Conducting an exploratory test
• Select and run a test case
• Open a bug

Two reasons to use ASP.NET MVC:

• Clean HTML
• Controllers can be called from JavaScript

So to come back to my strategy for using AJAX in web applications, I think an approach I am going to try is to divide navigation into two classes:
*Website navigation
*Page level navigation

Website navigation will generally allow for “postbacks” whereas page level navigation will allow for actions that are very specific for that page. The MVC framework provides a structure that supports this strategy. Your views act as your “postbacks” and the actual views themselves are where the activity takes place. Postbacks in this instance refers to the flicker effect you get when you click on links, whereas AJAX allow for a smoother effect.

The other bit of strategy I would like to think about is processing the results from datasources through AJAX. At the moment I am developing web applications where the web services return HTML strings, and the JavaScript simple ends up displaying it. I feel that this approach is messy and does not allow for a clear and contextualised view of your system. There must be an approach that creates good quality AJAX that can interact with server side code. I am looking for an approach that will make it easier to develop and implement my classes. I love the classical object design approach because I like things organised that way.