Question:
I am aware of the recommended approach to developing three-tier systems?for example, presentation layer to business objects to data objects. Say I have a system that has a data object named ICustomer and a method called GetDetails(…) which returns customer details. I have an ASP page/Win32 app that wants to get the customer details for display. Should it go direct to the data object (this breaks the “rules” of exposing the data objects) or go through an intermediary business object (which is just a wrapper with no functionality and just delegates the call to the data object)? Obviously this call does nothing but add an extra layer and degrade performance due to having to create an intermediary object.
Answer:
This is really a great question! It is also one to which there may be no definitive answer. You may get a different answer from every person you ask, but here is my take on it. I have created a “pure” data access object. I reuse that object in many different projects. This data access object has functions such as OpenConnection() and GetRecordset(). Those functions contain code that accesses and uses ADO objects to do the nitty-gritty work of accessing data stores.
For individual projects, I create project-specific objects that reference and use the “pure” data access object. The project-specific object will call OpenConnection(), GetRecordset(), and others. Also, the project-specific object usually does not contain code that references ADO objects because the “pure” data access object does that work. In addition, the project-specific object can focus on processing the data that is returned in the recordsets and passing relevant information (not data) to the client.
From a performance standpoint, you are correct: there is an extra layer that consumes resources. However, from an application management perspective, and from a coding perspective I have found that the extra layer is justified.
