Some of you find it useful

I am pretty sure that all the developers out there have tried at least once to develop their application using N-Tier Application architecture. As I remember, I did the same and many times I ended up with application layers where the functional responsibilities are spread over the layers. As the application grew, it became a nightmare to maintain the code. Once I became familiar with the Unit Testing, I tried to create Unit Test for some of my previous written projects and I failed in almost every scenario. The deficiencies in those designs were

- Code was not extensible.
- Code was not loosely coupled.
- No clear separation betweens Layers.
- Not Testable

In this article, I will try to show you how to create an application which does not have all these deficiencies. There are other designs available out there but I found this approach quiet easy to understand, extensible and maintainable. I have used NUnit Framework for creating the Unit Test. So you will need to have NUnit installed on your PC, if you want to run the Unit Test. I have also attached a sample application here with the application. So, if you think code is enough for you to understand everything, download the sample project and stop reading here.

Let’s start with a very simple problem scenario. We want to build an application which will be able to Register Students and will allow students to enrol for some courses. I have attached a sql script of a simple database which contains only three tables – Students, Courses and StudentCourses.

‘Program to an interface, not an implementation’ – is the first principle of reusable object oriented programming and you may hear about other design principles like ‘Open for extension but closed for modification’, commonly known as (OCP) open close principle. In short these principles imply to use abstraction in order to decouple your system from the dependency. In our problem domain, the system has dependency to Database. By following and implementing those principles, we will be able to create a Business Logic Layer Assembly which we can use in all types of projects and the Data Access Layer will be extensible enough to support different data sources like SQL, Oracle, XML etc. Most importantly we will be able to Unit Test the assemblies.

Our solution contains five individual projects
   1. Business Logic Layer (Class Library Project) – contains business object definition, collections and data Service interfaces.
   2. Data Access Layer (Class Library Project) – contains different implementation of provider specific data access classes.
   3. ServiceLocator (Class Library Project) – contains class which is used to register and locate different service instances.
   4. UnitTest (Class Library Project) – Contains couple of unit tests.
   5. TestApp (Windows console application)

I always like to keep my business objects classes very simple; it will have just the properties it requires and the constructors. Let’s have a look at the student class

public class Student
    {
        private int _studentId;
        public int StudentId {
            get { return _studentId; }
            set { _studentId = value; }
        }

        private string _firstName;
        public string FirstName {
            get { return _firstName; }
            set { _firstName = value; }
        }

        private string _lastName;
        public string LastName
        {
            get { return _lastName; }
            set { _lastName = value; }
        }

        private Courses _courses;
        public Courses RegisteredCourses { 
            get{
                if (_courses == null)
                    _courses = ((ICourseDataService)ServiceLocator.
                        Instance.Resolve<ICourseDataService>()).GetCoursesByStudentId(this.StudentId);
                return _courses;
            }
        }

        public Student(int studentId) {
            this._studentId = studentId;
        }

        public Student(int studentId, string firstName, string lastName) {
            this._studentId = studentId;
            this._firstName = firstName;
            this._lastName = lastName;
        }
    }

It has nothing to describe except the RegisteredCourses property and how it gets it value. I will come back to it later in this article. The collections classes are inheriting from Generic List class. I like to keep it in this way because later we can extend them to implement sorting and filtering functionality.

Our Data Access classes implements the data service interface defined in the BLL project. Have a look at one of them. We have abstracted the student related database functionality in an Interface called IStudentDataService which has the following signature

public interface IStudentDataService {
   Students GetAllStudents();
   Student GetStudentById(int studentId);
   Student InsertStudent(string firstName, string lastName); 
}

Now see the SQL Server implementation of IStudentDataService interface. I have used Microsoft Enterprise Library to implement this.

public class StudentSqlDataService:IStudentDataService
    {
        #region IStudentDataService Members

        public Students GetAllStudents()
        {
            Students students = new Students();
            Database db = DatabaseFactory.CreateDatabase();
            DbCommand cmd = db.GetStoredProcCommand(StudentProcedures.PROC_GET_ALLSTUDENTS);
            DataSet ds = null;
            ds = db.ExecuteDataSet(cmd);
            foreach (DataRow dr in ds.Tables[0].Rows) {
                students.Add(Make(dr));
            }
            return students;
        }

        

        public Student GetStudentById(int studentId)
        {
            Database db = DatabaseFactory.CreateDatabase();
            DbCommand cmd = db.GetStoredProcCommand(StudentProcedures.PROC_GET_STUDNETBYID);
            db.AddInParameter(cmd, "@StudentId", DbType.Int32, studentId);
            IDataReader reader = db.ExecuteReader(cmd);
            if (reader != null)
                return Make(reader[0] as DataRow);

            return null;
        }

        public Student InsertStudent(string firstName, string lastName)
        {
            Database db = DatabaseFactory.CreateDatabase();
            DbCommand cmd = db.GetStoredProcCommand(StudentProcedures.PROC_INSERT_STUDENT);
            db.AddInParameter(cmd, "@FirstName", DbType.String, firstName);
            db.AddInParameter(cmd, "@LastName", DbType.String, lastName);
            IDataReader reader = db.ExecuteReader(cmd);
            if (reader != null)
                return Make(reader[0] as DataRow);

            return null;
        }

        #endregion

        private Student Make(DataRow dr) {
            return new Student(Convert.ToInt32(dr["StudentId"]), Convert.ToString(dr["FirstName"]), Convert.ToString(dr["LastName"]));
        }
    }

Once the DAL is ready to use, its now time to see the service locator project. I am not going to describe the service locator concept in details. Google is your friend and the one that i have used in my project is copied from the very well written article by Stefano Ricciardi. You will find it here. I just extend this to register services. 

If you are familiar with Unity Application Block, it has got a container which also can be used as a service locator. Service locator holds the relationship between the abstract and concrete instance. Now have a look at the RegisteredCourses property on the Student object. It is asking for a Concrete instance of ICourseDataService and calls GetCoursesByStudentId method from it. We have implemented it using the lazy pattern as we don’t want to hit the database unless we need to have the registered courses of a student.

Now registering the services is the responsibility of the client Application. Here we have UnitTest and Console as two different host application. We have implemented another implementation of IStudentDataService called StudentMockDataServices to be used in the Unit Test.  So whatever services are registered in the host application, the application will be able to use them. Registering the services is a one time task and ideally you should do it at the start of the application. For web application Global.asax Application_Start is the perfect place for this. Service registration is also implemented using lazy pattern, so it will not block the application loading for generating the concrete service instances. The concrete instances will be created only when required. Lets see the code for the service registration.

private static void RegisterServices() {
    ServiceLocator.Instance.RegisterService<IStudentDataService, StudentSqlDataService>();
    ServiceLocator.Instance.RegisterService<ICourseDataService, CourseSqlDataService>();
}

I have included a sample database script. Run this script on a blank SQL database and it will create the tables, stored procedures and populate the tables with some sample data to see the console application on action. This same approach can be used to decouple other application dependency like Settings, Event Logging etc.  

I hope it helps. I would like to hear your comments and questions you may have regarding this. I would also like to take this opportunity to thank Refky Wahib, my manager at Center for Learning Innvoation, for kindly reviewing my codes and teaching me many things.