Dealing with architecture bugs. Case Study

Architecture bugs are one of the hardest to solve. To solve in proper way ;). Almost always they affect huge part of the system. Fixes can have impact on all application layers, because mostly a fix requires changes in more then one layer. If the system is designed according to a set of rules (i.e. is not tightly coupled) then after fixing we don’t have to sit and shake because something else somewhere else may crash…

Some example: Let’s assume that in our system we have reports module. This module is using business layer functions as a way of accessing business data. Simple reports (like lists) are generated fast, but complex reports that combining a lot of different object lists and having some transformation are generated very slowly. During such action we have a feeling that the system freezes for a while….

Is such scenario we have at least few problems to solve:
-GUI responsiveness – why is freezes ?
-CPU is occupied in 99%….
-Hundreds of connections to the database……

it seems that we have some bugs combined together giving us the result described above….

1. GUI responsiveness
Application freezes when we try to generate a complex report. I believe that every experienced coder know what the problem is in 99% cases.
Perhaps invoking business layer function that return our complex report should be done in another thread. Then the GUI thread would be responsive to the user and doesn’t confuse him….

2. CPU is occupied in 99%
It seems that all the complex logic is performed in the client site. All the data is send from server to client and all transformations, generating images etc. is done here…. This is not a good solution. At least not in that case.
I have assumed here that we are using client-server application model and all the data is processed in client. If this is the case we should move the whole processing to the server side. Or even better – generate as much as possible on the database level in (i.e. in stored procedures). In scenario where we have – so called – fat-client the only way is to move as much as possible to the database level.

3. Hundreds of connections to the database
Let’s thing a while why this weird thing is happening(and nobody else can connect to the database while we are generating our complex report :D). Since we are using business objects with properties are another business objects and so on…. and for retrieving each business object we are using method like GetProjectByID(), GetTaskByID(), GetTaskStepByID() in Business Layer…. in our case each time we are opening and closing new connection….. Now we may ask ourselves:”How could we miss that?!“. Generally if we want to display a form with Project we are creating a lot of connections… Shit!
In this case we should change the way we are retrieving business objects from the database. It is bigger task since it’s affects Data Access Layer and Business Layer. The solution should use as less connections as possible. Maybe a connection pool ? Another issue is to return related objects. It may happen that we decide to use a reports engine that works directly with the database (like Crystal Reports). Another possible solution is to use an ORM if we are not using it yet.

But, keep in mind that all that costs time. You have to know the architecture quite good to predict how it will behave after refactoring. Key factor here is the time. For some teams quick and dirty solution will work, because lack of time (We should ship it 2 weeks ago!), and for the others – mostly on early project staged – well designed solution with caching and all others fireworks will make them proud.

Follow me:

Leave a Reply

Your email address will not be published. Required fields are marked *