Introduction
In this tutorial, we will try to understand how we can use Interfaces and the Factory pattern to create a truly decoupled architectural framework. In this sample, we will take up a simple three tier architecture and apply interfaces and the Factory pattern to see how we can transform the three tier into a truly decoupled architecture.
Everyone’s favorite, the three tier architecture. OK, everyone know what the three tier architecture is. I will talk a bit about it and then we will get down to the issues related to a three tier architecture. Basically, as we all know, in a three tier architecture, the UI code is in the client section, business objects are nothing but business classes which have business validation, and the data access layer does all the database operations. Till here, everything is good and nice.
If we analyze these three sections, one of the important points to be noted is that business validations are highly volatile. Business rules change as the way of business changes with changing times.
The second volatile section is the client. People like to have support for multiple clients depending on user interfaces. This is not so volatile as compared to business object changes. Even if the customer wants to change, it is not on an urgent basis. Business validations need to be changed instantly.
Data access is the least volatile of all. At least in my whole project career I have still to come across a project which wants to migrate from one database to another database frequently. There are times when there is a need but that’s not urgent and is treated as a migration project.
So the conclusion is business sections are the most volatile and when there is a change, it needs to be changed instantly as compared to UI and backend databases.
Controlling change ripples
Below is a business class called clsInvoiceHeader. You can see in the code snippet that the user interface is setting the value of the business object. So the user interface is directly consuming the class.
clsInvoiceDetail objInvoiceDetail = new clsInvoiceDetail ();
objInvoiceDetail.CustomerName = txtCustomerName.Text;
objInvoiceDetail.CustomerAddress = txtCustomerAddress.Text;
objInvoiceDetail.InvoiceComments = txtComments.Text;
objInvoiceDetail.InvoiceDate=Convert.ToDateTime(txtInvoiceDate.Text);
At the other end, when the businesses object connects with the data access layer, its sending the values in a normal .NET data type. You can see how InsertInvoiceDetails of the DAL component has normal .NET data types passed.
public class clsInvoiceDetail
{
public void Insert(int _InvoiceReference)
{
clsInvoiceDB objInvoiceDB = new clsInvoiceDB();
objInvoiceDB.InsertInvoiceDetails(_Id, _InvoiceReference, _ProductId, _Qty);
}
}
So what will happen if the business objects change? It will just ripple the changes across all the three layers. That means you will need to compile the whole project.
Magic of Interfaces and the Factory pattern
So how do we control those ripple effects across all the tiers? The answer to this is by using Interfaces and the Factory pattern. So let’s first create an interface for the clsInvoiceDetail class. Below is the Interface code:
public interface IInvoiceDetail
{
string InvoiceReferenceNumber
{
get;
}
string CustomerName
{
set;
get;
}
string CustomerAddress
{
set;
get;
}
string InvoiceComments
{
set;
get;
}
DateTime InvoiceDate
{
set;
get;
}
}
Secondly, we define a factory which creates the clsInvoiceDetails object. Below is the sample code:
public class FactoryFinance
{
public static IInvoiceDetail getInvoiceDetail()
{
return new clsInvoiceDetail();
}
}
So the client only refers to the interface which is the proxy and the factory creates the object of the concrete class ClsInvoiceDetail. This way the client never knows about the concrete class ClsInvoiceDetail. The factory class is introduced to avoid the new keyword use in the client. If we have a new keyword client in the UI, then the UI needs to have direct contact with the concrete object which leads to heavy coupling.
IInvoiceDetails objInvoiceDetail = FactoryFinance.GetInvoiceDetails();
objInvoiceDetail.CustomerName = txtCustomerName.Text;
objInvoiceDetail.CustomerAddress = txtCustomerAddress.Text;
objInvoiceDetail.InvoiceComments = txtComments.Text;
objInvoiceDetail.InvoiceDate=Convert.ToDateTime(txtInvoiceDate.Text);
The other end, i.e., the database layer, is also easy now. We need to pass the interface object in the database function rather than .NET primitive datatypes.
public class clsInvoiceDetail : IInvoiceDetail
{
public void UpDateToDatabase()
{
clsInvoiceDB objInvoiceDB = new clsInvoiceDB();
objInvoiceDB.InsertInvoiceDetails(this);
}
}
So here’s what we have done: the UI is isolated using Factory and a business object interface. The database layer is isolated using the interface. So in short, when we change any logic, we do not need to recompile the whole project and thus we have controlled the business logic ripple effect in the business logic project itself.
We have also uploaded the source code for an invoice project to demonstrate how the above decoupling works. One project is a simple three tier architecture while the other shows how we have used the Factory pattern and Interface to increase decoupling between the tiers.
You can get the source code from the link above.
For Further reading do watch the below interview preparation videos and step by step video series.
