The DAO design pattern is traditionally associated with the Java Core J2EE Patterns, but this relatively simple pattern is equally applicable to our Microsoft .NET world.
This time I am not talking hypothetical here, since recently I saw it being used extensively in real world .NET webportal code I was auditing. I guess it is time to investigate this pattern in more detail.
A great advantage of the DAO pattern is that it separates the business logic and data access layers which – in an ideal situation – should know nothing about each other and where probably both will be changed frequently and independently. Changes of business logic can trust on the same DAO interface, while changes in persistence logic do not have any impact on its DAO clients as long as the interface is implemented correctly.
In this pattern the business object is the client which needs to get or set some data from a remote datasource. It is doing so by creating a data access object and a transfer object, which is a vehicle and contains the data.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
class BusinessObject { public void Run() { DataAccessObject dao = new DataAccessObject(); //Set data string input = "Hello?"; TransferObject to1 = dao.GetTransferObject(); to1.SetProperty(input); dao.SetTransferObject(to1); //Get data TransferObject to2 = dao.GetTransferObject(); string output = to2.GetProperty(); Console.WriteLine(output); Console.ReadKey(); } } |
The data access object contains the data source and functions like an object adapter. It fills the transfer object with data.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
class DataAccessObject { private DataSource m_DataSource; public DataAccessObject() { m_DataSource = new DataSource(); } public TransferObject GetTransferObject() { TransferObject data = new TransferObject(); data.SetProperty(m_DataSource.GetData()); return data; } public void SetTransferObject(TransferObject data) { m_DataSource.SetData(data.GetProperty()); } } |
The transfer object just represents the data from the data source in object format.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
class TransferObject { string m_Property; public void SetProperty(string property) { this.m_Property = string.Format("TransferObject->{0}", property); } public string GetProperty() { return m_Property; } } |
Most of the times the data source will be some database, but it can be anything varying from a flat file to an ERP adapter. For the sake of this simplified example the data source is just another object.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
class DataSource { private string m_Data; public string GetData() { return m_Data; } public void SetData(string data) { m_Data = string.Format("DataSource->{0}", data); } } |
The data access object design pattern is a relatively simple pattern you can use to separate you business logic from the actual implementation of the data source. The pattern is originally associated with J2EE patterns, but as I showed in the example code it also suits very well as a .NET pattern.
Comments