In my previous article (part 1), I shared what an n-Tier architected application is and why you should familiarize yourself with the concepts behind them.  In this article, I will take this a step further and show you how you can create a simple n-Tier architected ASP.NET application using Visual Studio 2010.  I won’t create all the CRUD (create, read, update, delete) operations for the business objects, but it should give you a strong start to creating a simple multi-tiered ASP.NET application.

When we are finished, your Visual Studio solution will have the following layers:
1) SalesSystem.Web - ASP.NET website
2) SalesSystem.Presentation - Presentation Controllers
3) SalesSystem.BusinessObjects – Business Logic Layer (Objects)
4) SalesSystem.Core – Core Utility Objects

We will start by creating an empty Visual Studio solution and then adding projects to it.  Each project acts as a logical layer (tier).  Projects can reference each other via the use of project references.  When you build the Visual Studio solution, it will build each project for you automatically.  Before I show how to create an empty solution and add projects (logical layers/tiers) to it, here’s a brief explanation of what each project will do.

SalesSystem.Core – I used this project to contain generic utilities, functions, extensions, helpers, etc which can be used across any new application you may develop.  Think big.  You don’t want to reinvent the wheel if you don’t have to.  I thought I may be developing more web applications in the future, so a common task is reading connection strings from the web.config.  So I wrote a utility object for the web.config and put a base class to be inherited on all web pages in there too.  This project/assembly is used by each of our other tiers.

SalesSystem.BusinessObjects – I made this project to house all of my business objects.  I didn’t take the time to create an official DataAccess Layer… but business objects often are made to interact with one particular data source type.  In this case I am interacting with a SQL Server and the connection string to run the queries on is passed in via a connection string to still maintain a dynamic and flexible approach.  Regardless of merging the business objects in with data access routines, I am able to use these business objects going forward easily as long as the application (whatever type it is) supports CRUD operations on a SQL Server.

SalesSystem.Presentation – Okay, this project may be a bit confusing for most.  I made another tier/layer to act as the liason between the UI and business objects.   I have a couple of reasons for this.  First, it makes calls simpler from ASP.NET page code behinds.  An ASP.NET page can have one controller which does a myriad of tasks (page centric) on many types of objects.  Second, it will help with automated unit testing in the future if we decided to take it to that level.  Your presentation layer should essentially be presenting the UI and capturing data from the user.  The less “clutter” you can put in the presentation the better.  So using presentation controllers can assist here.

SalesSystem.Web – This project is the presentation layer and we are using an ASP.NET website to do this.  Our objective in this layer is to simplify the logic down to presenting and capturing data from the user.  Any business object acquisition or saving should be done through the controller.  This makes the UI code much cleaner and simpler.

Here’s what the final solution will look like:

Step 1: Create an Empty Solution – First we want to create an empty Visual Studio solution so we can add our projects (layers/tiers) to it.  Below is a screenshot on how to do this.

Step 2: Add Projects to the Solution – Next we want to add projects for each tier we want to our solution.  We have 4 layers that we want to develop, so we’ll add 4 projects to the solution which will facilitate logical layers.  Each layer may be a different project type.  For instance, the presentation tier (SalesSystem.Web) will be an ASP.NET web project.  However our core, presentation controller, and business projects will all be windows class libraries as they simply have .NET classes in them.  Below are screenshots to help facilitate how to add the projects to our empty solution.

Step 3: Add Project References – The final step to getting your ASP.NET n-Tier architected solution to work is to setup project references to each tier can communicate, consume, and/or interact with each other.  Think of project references as “inheritance”.  If you need to use a tier’s (project’s) functions or data types, you need to add a project reference (or inherit) from it.

SalesSystem.Web References - We know that SalesSystem.Web will need to make calls to the SalesSystem.Presentation controllers which will return objects from SalesSystem.BusinessObjects.  So the SalesSystem.Web will need project references to both projects.  It will also need a project references to SalesSystem.Core because that is our core project which we have our core objects & utilities that we can use everywhere.

SalesSystem.Presentation References – This tier doesn’t care about the UI.  It makes calls to the business object layer.  Therefore it only needs a reference to SalesSystem.BusinessObjects.  Again, add a reference to SalesSystem.Core as well.

SalesSystem.BusinessObjects References – This tier is only concerned with its own business objects and interacting with the database.  It doesn’t care about what presentation layer is employed to use them… so the only references you need is to SalesSystem.Core.

Here is how you add a project reference:

Step 4: Code – I’m not going to go into detail on how to code the tiers.  Instead I am attaching the solution which includes the code in each tier to acquire customer sales from the AdventureWorks database using our n-Tiered solution.  The end deliverable is an ASP.NET website which a page’s codebehind class makes a call to our presentation controller tier which makes calls to our business objects and back out again.

Summary - Imagine taking this application to the next level and offering a Windows WPF UI option.  We could reuse the same presentation controllers, core, and business object tiers.  We would simply replace the ASP.NET web presentation tier and most of our work would already be done.  If a call to the database was broke, we’d fix it in one business object and be done.  One place, one time.  We wouldn’t have to be searching through all code-behind files trying to locate every instance of the problem.  If you had a UI designer/coder, they could be designing the look of the web pages while you focused on the business objects and back-end tiers (parallelism).  There are many reasons why applications are constructed like this.

Hopefully this helps you get a good start to understanding n-Tier architected applications and how you can accomplish this in Visual Studio using logical layers with VS projects and project references.

n-Tier Architecture – Part 1
n-Tier Architecture – Part 2

SalesSystem_Soln.zip (792.10 kb)

Throughout my career, I’ve been a guest speaker and judge at local universities.  I’ve also interviewed many job seekers over the past several years.  As a result, I’ve noticed some areas of weakness new developers have when being thrown out into the “real world” of programming.  You’d be amazed at how many new programmers do not have experience with n-Tier architected applications.

So what is n-Tier architecture?  N-Tier architecture refers to an architecture which breaks up an application into separate layers (tiers).  A tier encapsulates methods, objects, properties, interfaces, technologies, etc to perform a set of predefined tasks.  Each tier is separate and thus can reside on other servers, networks, assemblies, namespaces, classes, etc.

For an example, let’s say we have a Silverlight application.  The Silverlight XAP is the presentation layer.  Our Silverlight application then consumes a web service which creates objects which run queries on our SQL Server.  The web service creates the business objects which are part of our business logic layer.  The objects then query the database through the data access layer.

There are many advantages to breaking up the application into tiers (layers) like this:
1) Avoid changing or recompiling other layers if one layer needs changed.
2) Reduction of complexity.
3) Promotes parallel development
4) Easier to maintain.
5) Works much better with automated testing.
6) Easier to scale.
7) Promotes code/tier reuse.
8) Helps with adoption of new technologies.

In our Silverlight example, we had the presentation tier implemented using Silverlight on the client’s web browser.  The web service, objects, and database interaction were done on the server.  Because these layers were “distributed” among multiple machines, they can be referred to as “physical” layers.  On the other hand, layers separated by assemblies or sets of classes can be thought of as “logical” layers.

Now that we know the basics as to what an n-Tier architected application is, in my next article I will show you how to create an n-Tier enabled ASP.NET web application using logical layers in Visual Studio 2010.

n-Tier Architecture – Part 1
n-Tier Architecture – Part 2

Today I decided to make a small ASP.NET MVC application which would add, edit, delete, and list US states which resided in a SQL Server Express database.  I am a veteran in ASP.NET Web Forms development, so I wanted to see what MVC is like.  I create business objects/models everyday, so understanding models was easy enough.  The tricky part for me was creating and understanding how controllers and views interact with each other.

First Impressions:
1)  I liked the clean separation between controller/view/models.  Basically this is required when using MVC.  I’ve already been accustomed to separating layers, so this wasn’t new to me, but seeing how the MVC Framework has this built in was refreshing.
2)  When I created a new MVC Web Application, it automatically prompted to create a Test project.  I thought that was pretty neat.  I’m not experienced in creating automated test yet, but I’m sure I’ll get there soon and just seeing the parallelism with MVC and testing was impressive.
3)  REST (Representational State Transfer) URLs was interesting.  Apparently you can configure how requests are mapped to controllers in the Global.asax.  I didn’t get into this much as I took the defaults, but simply editing a state looked like such: “/states/Edit/1”.  No more mapping to a template/resource.
4)  You can generate a view straight from the controller by right-clicking when you return an ActionResult.  Visual Studio will then prompt/ask you what kind of view you want to make and you can also have it create a strongly typed view so that you can access the model’s properties.  So the framework can assist in starting a view pretty quickly for you.
5)  Not having view state and post backs was really nice.  The rendered HTML was very clean.
6)  I was confused at times as to how the framework knew what to pass to controller routines on a form post and also how id’s work.  What if you have more than 1 property that makes up the id?  I imagine this would come with time.

Overall I enjoyed the initial experience and it seemed very structured.  I feel that one day doesn’t do it justice as MVC is a bit more complex than web forms.

Helpful Resources:
1)  Scott Guthrie’s NerdDinner.com Chapter:  Scott Guthrie wrote a chapter in Professional ASP.NET MVC 1.0 in which he walks you through step-by-step in creating an MVC web application.  You can download the chapter in PDF and also download the source code if needed.
2)  Simple E-Commerce Storefront Application: This is another Scott Guthrie example, however this example has some nice architecture diagrams that go along with it to explain what’s going on a bit more.

MVCTest_Soln.zip (891.39 kb)

ASP.NET MVC Overview Part 1 (General ASP.NET MVC Overview)
ASP.NET MVC Overview Part 2 (Advantages of MVC and Web Forms)
ASP.NET MVC First Impressions

In Part1, I discussed the basics of what the MVC pattern is and how Microsoft has incorporated MVC into ASP.NET.  In this segment, I am going to discuss some general advantages of ASP.NET Web Forms and ASP.NET MVC.  Neither flavor of ASP.NET will be the superior choice in all circumstances.  Therefore knowing the advantages to each will help.

I’ve found through my development career that there’s never a right or wrong way to do something.  Scott Guthrie posted recently the following which is very true, “Great developers using bad tools/frameworks can make great apps.”  The same principal applies to bad developers using great tools/frameworks… inevitably they will create bad applications.  Just because one framework may shine better in certain situations may not mean its better.  If the developers using the superior technology cannot grasp or develop it properly, its full potential will not be realized.  So keep these principals in mind when evaluating the two.

Advantages of ASP.NET MVC
1) Separation of model, view, controller results in reduction of complexity, promotes parallel development, and easier to maintain.
2) Enables full control over rendered HTML (leaner html rendering).
3) Works much better with automated testing as all core contracts are interface based.  You can run unit-tests without having to run the controllers under an ASP.NET process.
4) Does not use view state or postbacks (no view stage = quicker load times).
5) Framework is very extensible and pluggable.
6) Supports existing markup (aspx, master pages, ascx, inline expressions).
7) Supports existing session, caching, authentication, etc.
8) Easy integration with javascript frameworks.
9) Follows the design of a stateless web.

Advantages of ASP.NET Web Forms
1) Commonality between windows forms development in that it uses the event model.
2) Usage of view state and server forms helps manage state more easily.
3) Promotes RAD more so than MVC as more controls/components are available.
4) Less complex than MVC and generally requires less code.
5) More mature as it’s been around since the 1990’s.

ASP.NET MVC Overview Part 1 (General ASP.NET MVC Overview)
ASP.NET MVC Overview Part 2 (Advantages of MVC and Web Forms)
ASP.NET MVC First Impressions

Traditionally there has been only one approach to develop ASP.NET web applications; web forms.  Lately I’ve been hearing a lot of hype wrapped around this thing called MVC and the fact that it can be used as an approach to develop ASP.NET applications.  What is MVC?  MVC stands for Model-View-Controller.  It is a design pattern which separates an application into 3 logical tiers: domain, input, and presentation.  This isolation between layers yields independent development, testing, and maintenance of each.

Model – The model can be thought of as the business layer.  It performs application logic and is used to maintain the state of the application typically in a database.

View – A view is a component that is used to display the UI which can often be a direct representation of the model’s state.  For an example, the model may return a collection of workers from the database.  The View could display the workers in a GridView/DataGrid.

Controller – The controller ultimately handles and responds to user interaction.  It works with the model based on what the user desires and then renders the appropriate view accordingly.

The ASP.NET MVC Framework is Microsoft’s stab at at creating an ASP.NET programming environment that is centered around the MVC pattern.  So how is the request model different between MVC and traditional web forms?  An ASP.NET web form uses the postback to relay the request and the page’s code behind handles it.  In ASP.NET MVC, REST is used to communicate the request and MVC is used to process it.

REST stands for Representational State Transfer.  In ASP.NET MVC, instead of mapping URLs to ASPX files stored on disk you are mapping URLs to controllers (classes).  The controller will handle what view to render back to the end-user.

ASP.NET MVC Overview Part 1 (General ASP.NET MVC Overview)
ASP.NET MVC Overview Part 2 (Advantages of MVC and Web Forms)
ASP.NET MVC First Impressions