Problems with Object Systems
If you analyze your software system you will find various classes. And while you formulate the business rules more and more navigation paths are created between the classes. This is shown in the following picture:
Actually each of these navigation paths represents a query – a consideration about how you get hold of the objects that belong to a certain relation. For example if you have an Employee object and want to navigate to the travels that employee has performed you have to fetch the travel data from the database and construct travel objects from it. Even worse, the number of queries increases exponentially with the complexity of your system.
Now, how should we store such object systems? As we know, Microsoft believes in all things which have rows and columns. In former days we had ODBC, OleDb, ADO, now we have ADO.NET.
With that kind of stuff it is difficult to implement relations between objects. If we don’t care, the code of our business classes gets crowded with persistence code, just to fetch child objects of a relation. So we are not able to read the business rules as easily as we want to.
A first approach to a solution of that problem is to write Data Access Layers. Thus we can isolate the query code and keep it out of our business classes. But the main disadvantages remain in our system. We need lots of code to build our data layer. We still have to solve the problem of building our objects out of mere data over and over again.