I had an architectural problem yesterday.
I was working on a methods and managers I won't disclose but will analogy instead.
Imagine you have a coffee manager. Let's name it CoffeeManager.
In my case not only I had coffee manager but also I had a SugarManager, a CupManager etc.
In order to take a coffee without sugar in a plastic cup I should do something like:
Sugar sugarObject = SugarManager.GetSugar(Sugar.None);
Cup plasticCup = CupManager.GetCup(Cups.PlasticCup);
Coffee shortCoffee = CoffeeManager.GetCoffee(sugarObject, plasticCup);
And this happens at the very frontend of the project (in ascx for example).
And not only it happens that way but the managers are spread in few different projects.
So in the frontend I need to call few different managers, get some results from them and pass those results to the manager that should be doing my job.
I also need to handle all the problems that may rise in the managers so I get a lot of code in the frontend just to get something that in my opinion for that particular case should be returned calling a single method and auto handled in the manager.
I think the front end shouldn't care about business operations that much, also as I said the managers were in different assemblies so I ended up adding few references to the frontend project.
I refactored the code so the CoffeeManager can do this job internally (drawback is that the matrix of all combinations of sugar and cup should be added as a methods in the CofeeManager, but I can live with that).
