Thursday, February 18, 2010

Loose coupling in .Net

Hello Folks,

I am starting a series of posts on .Net technology.
My audience will be preferably Novice programmers in .Net
Today I have taken how to achieve loose coupling in C# with ease.
There are many reasons why Architects employ Loose coupling in their architectures. I have listed some of those
  • Greater re-usability, you can separate the logical modules better and can reuse them some where else.
  • Maintainability, code becomes more self explanatory and you can debug, develop and maintain the modules separately.
  • Unit testing, support unit testing more as you can create mock objects in place of actual implementation.
  • Simultaneous development, As the code becomes loosely coupled, one team does not necessarily know the implementation of the other and can work on a layer, in case of N-tier application. teams would only know the contracts.
Yes, it is all about contracts (Interfaces)
The basic idea is about declaring an interface and share it with the other logical module or layer.
Now you can implement this contract as you like.
The basic thumb rule is eliminating concrete instantiation of classes across layers.

Consider a class in some layer which inserts a record in a database. Now a scenario is this class does  not necessarily know the implementation of your Data Access Layer.
public class UserClass
{
   protected void SomeFunction()
   {
      IDataAccess objDataAccess = DAFactory.InitDA();
      objDataAccess.InsertRecord();
   }   
}
And here is how your interface will look like
public interface IDataAccess
{
    void InsertRecord();
}
Now this interface will be your contract between two layers. one layer having the above class will use this interface for accessing the functionality you promised to give in your contract.

Now lets write our Data Access layer. Right now lets assume that we implement our DataAccess layer on top of a Sql Server Database.
So the implementation will look like:


Here you are implementing the method you promised to give to UserClass.
public class DataAccesswithSQL:IDataAccess
{
   public void InsertRecord()
   {
      //Insert a record in your SQL DB
   }
}
Here we still haven't made the link between UserClass and DataAccess. i.e. DAFactory.InitDA();
As in UserClass we are using an already instantiated IDataAccess type object (DataAccesswithSQL).
DAFactory.InitDA() is the function which is going to give us a ready made instance of type IDataAccess
here we are going to do it here:

We use a simple factory which initializaes type IDataAccess object
public class DAFactory
{
   public static IDataAccess InitDA()
   {
      return new DataAccesswithSQL;
   }
}

As you can see it has become decoupled for instance, tomorrow if you plan to implement your DataAccess with Oracle Database you can easily do that by just implementing the IDataAccess in DataAccesswithOracle without disturbing UserClass or other layers. After implementing DataAccesswithOracle, you will need to change the instantiation part in DAFactory to new DataAccesswithOracle();

Further reading
You can also refer how Dependency Injection is done between layers for loose coupling.
http://www.codeproject.com/KB/architecture/DependencyInjection.aspx 

I hope you enjoyed reading through my post.
Stay tuned for the next post.
Many Thanks,
Padmanabh