Golf Tracker - Ep. 3 - Adding Classes

Golf Tracker - Adding Classes

In this episode I'll be adding classes to the many projects that I created in the last episode.  Since this is a quite time consuming process, I've created most of these classes offline to show you what I'm doing, but so you don't have to watch me hand code everything from scratch.

Business Objects

I'll begin with the business objects since they are going to be passed around all layers.  As I mentioned before, the business objects are going to be the classes that are transported between layers, not the Linq-To-Sql entity classes.  In addition to these classes working as Data Transfer Objects (DTO), I want them to also work in the views with validation.  So I'll decorate them with DataAnnotations attributes.

The Course business object looks like this:


It's a simple class that simply contains properties to carry data around.  Keeping the classes as simple and clean as possible is a priority for me.  This makes them easy to refactor and manage in the future.  Now I'll show you how they are used in the DataObjects layer.

DataObjects Layer

Here's a look at the DataObjects project and the various interfaces and classes I've added to make this work.



The classes and interfaces are separated to make them easy to identify and maintain. 

For this episode I'm just creating a single vertical, meaning I'm just going to make a single database entity such as Course work from the data layer to the presentation layer.

I begin with the interfaces.  You'll see that there are two interfaces, ICourseRepository, and ICRUDRepository.  The ICourseRepository is what the concrete CourseRepository class will implement, so let's take a look at it.


You'll see that the interface is empty, it has no members of it's own.  But it's implementing the ICRUDRepository interface and it's passing in the Course business object.  Let's see what that looks like.


This has several methods and we'll see that they are just CRUD methods, nothing at all custom.  The reason for this is to make management of your code easy.  This is especially helpful when you have a code generator generating your code.

When you create the CourseRepository concrete class, and implement the ICourseRepository interface, this will be the result.


All of the CRUDRepository interface members are stubbed out.  Now all I need to do is write the code that will be used for each of these methods.

Here is the code for the CourseRepository class.


I've found that the more you build applications, the more you find yourself wishing there was a better and easier way of doing things.  Such was my problem when ever I needed to refactor a database table.  If I ended up adding a new column to a table, I then needed to add a property to the business object and then also modify all the properties in my repository.

Take a look at the code above and you'll see that every method contains model mapping information to go from either entity to business object or vice versa.  While this works, it's a nightmare to maintain.

To follow my example in the paragraph before, let's say I add a new column to the database table, let's see what I have to refactor.  I need to obviously refactor the Course business object and add the new property, that's no big deal, and I have to modify the Linq-To-Sql classes, no huge deal there either.

But look at all the places I'll need to modify in the CourseRepository class.  And this is only with the basic CRUD methods.  There are no custom methods, of which there will obviously be!

Is there a solution, yes - DataMappers!

DataMappers are separate classes that handle a single thing, mapping the properties back and forth between the business objects and the entities.

Here's the CourseMapper class.


You can see that it easily maps all the entity properties and it's in one class that can easily be maintained.  So I'm going to refactor the CourseRepository class to use the DataMappers instead.

This is the newly refactored code for the CourseRepository class.


You can probably see that it looks like a lot less code now, which is true, but more importantly the code is now easier to maintain.

If I now need to add a new column to the database, all I need to do with the data layer is modify the CourseMapper class, and I'm done!  I don't even need to touch the CourseRepository class.  That's a huge time saver.

But since I'm using a DataMapper it means that I need to handle my POST methods differently.  The POST methods are Insert, Update and Delete. 

Notice that each of those methods don't simply call db.SubmitChanges().  That's because the entity that is being created in those methods by the DataMapper class, is not part of the data context.  You'll see that they are created outside the creation of the DataContext.  And since they are created outside the data context, they have to be attached to the context is some manner in order for Linq-To-Sql to process it correctly.

In the case of an Insert, I need to call the InsertOnSubmit(entity) method and pass in the local entity.  This ends up validating the manually created entity and attaches it to the context and then executes the proper action, in this case Insert.  Then I can call the db.SubmitChanges() method.

Also, because there is this abstraction of the data entity as it never leaves the data layer, we need to have that rowversion column in each table that will contain a timestamp to track the concurrency.  If we were doing all this data mapping and we didn't have any rowversion columns, none of this would work.

Building out the Service Layer

So now I'll move up to the service layer and show you what I've done with the interfaces and concrete classes.

The first I need to do is add some assembly references.  I'll add the references to the GolfTracker projects that I need here and some assemblies to help with dependency injection.



The service layer interfaces are similar in functionality to the data repository interfaces in that there is on ICRUDService interface that contains members for standard CRUD methods, and the custom ICourseService interface implements that interface.

Here's the ICRUDService interface.


And the ICourseService interface.


Now the service classes can be called from the MVC controllers.

Before I want to go much further, I should probably do some unit test to make sure everything is working as it should.

Stay tuned.