Modern Day Expectations of Web Applications: 10 Years of .Net Compressed into Weeks #4

This post is part of a blog series ASP.Net 10 Years On. Even though this is part of a series I have tried to make each post standalone.

The code review and performance tests of the project code didn't paint a very good picture. We concluded that the best way to get to where we need to be is to start again.

Since we are starting from a blank canvas we need to carefully consider our choice of tools and techniques. Some sections are worthy of their own posts which will follow as the blog series progresses.

VB.Net vs. C#

This is old ground and I do not wish to get tangled up in a holy war of languages. I only include this point, as part of this series is to document how I progressed and what influenced the decisions I made as a .Net developer. At some point early on in my career, it became apparent that I needed to switch to C#. Nobody told me to and I never saw any proven statistic to say it was more advantageous over VB.Net. In the books I bought, all the example code was in C#, many of the job opportunities that interested me required C# experience and nearly all of the forums and blogs I was reading at the time were using C# for their code snippets. These things combined gave me the impression that I should be coding in C# rather than VB.Net and so I began to drift away from using VB.

Code Complete 2 states that:

Studies have shown that the programming language choice affects productivity and code quality in several ways.

With this in mind I'm going to code the new version of this application in C# since I can be more productive as this is my primary language.

In my corner of the world I have also found it easier to recruit developers for C# roles and being as I may need to bring in extra help I want to try to improve my chances of recruiting.

Here is the TIOBE Programming Community Index for November 2012. This places C# quite some way ahead at 5.591% vs 0.769%. This table is not concrete proof but serves as an indication of adoption. I'm not sure if there is some ambiguity in this table as it also lists (Visual) Basic at 5.032%!

Choosing the Framework

I have two choices: I can stick with WebForms as in the original project or I can re-write the application using ASP.Net MVC.

I'm going to choose MVC mainly for the reason that I don't intend to use many if at all, web controls. This is due to the fact that I have a designer who is unfamiliar with WebForms creating new streamlined HTML for the project. Since all power of WebForms is in the controls, it's the wrong tool for the job if you don't plan to make heavy use of them. One of the design principles of the MVC framework is "to be helpful, but if necessary, get out of the developer's way". In this instance this is exactly what I want.

Another reason is that I want to plan for unit tests. A comment in our new requirements suggested that there were stability issues with past releases. Unit testing is a good methodology to have in place to help mitigate this problem and the MVC Framework lends itself well to this. Trying to test WebForm pages in isolation is notoriously difficult.

The project will use ASP.Net MVC 4.0 and will use the Razor view engine since it offers a slightly more succinct syntax over the conventional view engine (.aspx).

Creating an API

Our application will need a method of accepting SMS messages from 3rd party providers over HTTP and to serve any possible apps that may be developed by 3rd party suppliers. Due to the varied nature of the devices that may need to access the API we will use JSON for data exchange and make use of the Web API designed to allow us to easily create a lightweight RESTful HTTP API.

For further reading as to why JSON is chosen over XML see this post. Speed is a major contributing factor. JSON is much leaner than XML.

Designing for Tablet First

There was a suggestion that our client may consult a 3rd party supplier for Android or iPad/iPhone applications - pending their budget. We can help bring this gap and build up the API that such an app would use by designing the site for tablet before desktop. We also benefit from eating our own dog food as we build up the API. This will likely result in us making use of a JavaScript library such as Knockout JS or Backbone JS.

Hosting

We need to keep in the back of our minds that this project may be moved to a cloud computing provider. We recommended using Azure to our client so we need to be sure it will work on this platform should the situation arise. It must run on a vanilla Windows Server instance with IIS 7 and above.

The Database

We established that we are going to move away from MS Access to SQL Server. Our client suggested their demands were going to grow. What if they reach "Big Data" scale? We need to factor this in with our design in the event we may move away from a Relational to a NoSQL database. Windows Azure supports alternative big data tools such as MongoDB. We need to be aware of YAGNI (You ain't gonna need it) but we do need to manage our data access dependences very carefully.

Continuous Deployment

Our client wants to be closely involved with the application as it progresses. The best way to do this is to deploy early and deploy often. We need to ensure that our development time is not burned on deploying code and managing a development environment. We also need to limit the changes of broken code getting onto the development environment. If we are continually shipping work in progress code there is a high risk our client could run into errors which will damage confidence in the product.

Testing Framework

We want unit tests and being that all developers will be using Visual Studio we are going to take advantage of the default MSTest Framework that ships with Visual Studio.

In the next post we will being formulating our business logic code. See the RSS subscription links at the bottom of the page to follow this series.