Golf Tracker - Ep. 1 - Overview

Golf Tracker - Overview

Building an ASP.NET MVC 2 application from scratch

This is the overview for the series of videos I'll be creating that shows how I build a complete ASP.NET MVC 2 application from scratch before your very eyes!

What I'll be building is called Golf Tracker.  Golf Tracker will be an application that enables you to enter golf course information into a database, and players into the database, and then enter players scores for the rounds of golf that they played and track their results.

This application will be built as an n-Tier framework meaning that it will contain separated tiers for data access, services and presentation.  This type of framework makes refactoring and development easier by isolating the various concerns.  This also makes it easy to test individual tiers.

This is the database schema that I'll start out with.  It contains three tables, Player, Round and Course and it contains all the information needed to track and manage the application.



As you can see it's very simple.  It will most likely evolve as I get going.

This picture illustrates the n-Tier framework a little better and what I intend to do.



I'll describe what each section is and does:

• Presentation Layer - this is the ASP.NET MVC 2 application.  This is where the user interacts with the application.
• Service Layer - this is a bit if abstraction between the controllers of the MVC application and the data repositories.  This allows me add other bits of code before or after leaving the controllers and interacting with the repositories such as validation, connecting to an API, etc.
• Data Mappers - these are helpful bits of code that simply maps data layer objects to and from business objects.  These mappers are used in the data objects and they help in maintaining entity objects for simple refactoring.
• DataLayer - this is where the repositories are for the various entities and where the database access occurs.

You'll notice that the Presentation Layer and the Service Layer are both wrapped inside the Business Objects.  This is just to illustrate that these layers will be interacting solely with the business objects and absolutely NO data entities.

Business Objects are simply classes that represent an entity or table in the database, and they match the data objects entities property for property.  So why do I use them instead of the Linq-To-Sql data entities?  I do this for a few reasons:

1. Validation - I can easily adorn the class properties with attributes for form validation.
2. Isolation - the business objects are not connected to anything.  The are just classes with properties.  In my case I also don't add any methods to these classes because I want them to be simply Data Transfer Objects (DTO) that carry data to and fro, and not contain any logic.
3. Design - in an n-Tier framework, it's easier to work with a DTO model in the presentation layer than the Linq-To-Sql entities because I would otherwise have to include those assemblies that contain them in the presentation layer making the presentation layer heavier than it needs to be.
4. Loosely Coupled - I'm keeping the application as loosely coupled as I can, which means that the dependencies from one tier to another is dramatically reduced and easily swappable.

Technologies Used

I'll be using various open source technologies to help build this application.

• jQuery
• MvcContrib
• Telerik Extensions for ASP.NET MVC
• Linq-To-Sql
• C#
• SQL Server

So stay tuned and I hope you enjoy this series.