Now that we had a Trainee object, we needed a way to populate it from the database.

Since we knew that at some point we would want to make this an "n-tier" application, we decided to put a little bit of design-work in up-front, and instead of just connecting the object model directly to the database, we'd separate them out a bit.

So we started with a "data transfer object" class which mirrored the Trainee object, and would be the object that gets passed back and forth across our application layers. In keeping with some of the terminology introduced with .NET 3.0, we named it TraineeDataContract. I won't even paste the code in here because it's just a class with four public properties matching the properties of Trainee.

This class lives in an assembly called Qaf.TrainAlloc.DataProviders, along with an interface which defines all the ways we communicate with our data source:

 public interface IDataProvider  { IList<TraineeDataContract> GetAllTrainees(); void SaveTrainee(TraineeDataContract trainee); }

So a pretty simple interface for starters. We have a way to retrieve all the trainees, and a way to save a single trainee back to the database.

The end goal for this is to implement a couple of different ways of getting our data. The first will be a class to retrieve from, and save to, our SQL Server database. Later we can make another class which can retrieve from, and save to, a web service or WCF service that in turn uses the SQL Server class to talk to the database. In theory, this gives us the ability to swap out the data provider once the application is deployed. Choose it at runtime, even.

Next step is to implement the SQL Server data provider. See you in part 3!