Architecture bugs are one of the hardest to solve. To solve in a proper way ;). Almost always they affect a huge part of the system. Fixes can have an impact on all application layers because mostly a fix requires changes in more than 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 a scenario we have at least a few problems to solve:
- GUI responsiveness - why i 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 knows what the problem is in 99% of cases. Perhaps invoking business layer function that returns 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 on the client site. All the data is sent 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 a client-server application model and all the data is processed in the 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 a 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 think 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 a 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 a bigger task since it affects Data Access Layer and Business Layer. The solution should use to use as few 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. The 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.