Click here to Skip to main content
Click here to Skip to main content

Interfaces + Factory pattern = Decoupled architecture

, 10 Nov 2008 CPOL
Rate this:
Please Sign up or sign in to vote.
How we can use interfaces and the Factory pattern to create a truly decoupled architectural framework.

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.

For the past few days, I have been writing and recording videos on Design Patterns, UML, FPA, Enterprise blocks, and you can watch these videos at http://www.questpond.com.

You can download my 400 .NET FAQ eBook from http://www.questpond.com/SampleDotNetInterviewQuestionBook.zip.

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.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Shivprasad koirala
Architect http://www.questpond.com
India India

I am a Microsoft MVP for ASP/ASP.NET and currently a CEO of a small
E-learning company in India. We are very much active in making training videos ,
writing books and corporate trainings. Do visit my site for 
.NET, C# , design pattern , WCF , Silverlight
, LINQ , ASP.NET , ADO.NET , Sharepoint , UML , SQL Server  training 
and Interview questions and answers


Comments and Discussions

 
GeneralMy vote of 3 Pinmemberommuruganandam14-Dec-11 18:45 
Generalmama really i searching till date, i confused about it, Pinmemberjameschowdary28-Jan-10 22:57 
QuestionNew to design patterns PinmemberMicl11-Jun-09 6:33 
Generalsample is not working PinmemberMember 428981425-Mar-09 7:56 
GeneralA good article is which makes you think....And this is good Pinmemberivanshettigar11-Nov-08 5:04 
GeneralIMHO this is not a good example of a factory, or even dependency injection[modified] PinmemberTom Janssens11-Nov-08 3:42 
GeneralRe: IMHO this is not a good example of a factory, or even dependency injectio PinmemberShivprasad koirala11-Nov-08 4:51 
Generalthis is just more code to handle... PinmemberSeishin#11-Nov-08 3:36 
GeneralRe: this is just more code to handle... PinmemberShivprasad koirala11-Nov-08 4:59 
GeneralRe: this is just more code to handle... PinmemberSeishin#11-Nov-08 5:15 
GeneralRe: this is just more code to handle... PinmemberShivprasad koirala11-Nov-08 7:38 
GeneralRe: this is just more code to handle... Pinmemberterragenegeystur11-Nov-08 7:42 
GeneralRe: this is just more code to handle... PinmemberSeishin#11-Nov-08 7:54 
GeneralRe: this is just more code to handle... Pinmemberterragenegeystur11-Nov-08 8:16 
GeneralRe: this is just more code to handle... PinmemberSeishin#11-Nov-08 8:29 
GeneralRe: this is just more code to handle... Pinmemberterragenegeystur11-Nov-08 9:20 
GeneralRe: this is just more code to handle... PinmemberShivprasad koirala11-Nov-08 17:50 
GeneralRe: this is just more code to handle... Pinmemberterragenegeystur11-Nov-08 20:46 
GeneralRe: this is just more code to handle... PinmemberSeishin#11-Nov-08 7:50 
GeneralRe: this is just more code to handle... PinmemberShivprasad koirala11-Nov-08 8:10 
GeneralTests ... PinmemberJammer11-Nov-08 3:35 
GeneralGood one. Pinmemberhemasarangpani10-Nov-08 22:50 
GeneralRe: Good one. PinmemberShivprasad koirala10-Nov-08 22:53 
GeneralI was confused if we not use Interfaces+Factory pattern. Pinmemberleegool10-Nov-08 22:08 
GeneralRe: I was confused if we not use Interfaces+Factory pattern. PinmemberShivprasad koirala10-Nov-08 22:46 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Terms of Use | Mobile
Web01 | 2.8.141216.1 | Last Updated 11 Nov 2008
Article Copyright 2008 by Shivprasad koirala
Everything else Copyright © CodeProject, 1999-2014
Layout: fixed | fluid