Hello!
I've recently introduced to unity block and to DI and ServiceLocator patterns. It seems to have sense, but on practice some questions concerned about its rational use arise. I mean, that I've came to unity from articles about service locator, which is used to decouple classes realize some functionality (services) from classes that use them. I started to use unity container to implement this scenario. Additionally, I've borrowed modularity technique from PRISM, when main application loads minimal set of needed assemblies and there is a configuration file where services and interfaces are correlated. If unity container returns no mapped type, application searches this type in this list of assemblies, loads required, register requested type in container and then tries to resolve it again. So we get some lazy initialization or initialization by demand. Seems to be a good idea. But reasonable question arises - what if we would register each class in container after its interface decoupling system as much as it possible? Would it be rational and correct? I mean classes that expose business entities, i.e. Agreement, Client, Payment, Currency and so on. If we can decouple assemblies which contains FileDialog, MessageBox, OpenWindow services, application modules (as it is meant in PRISM), why we cant do this with business classes? From one hand it seems to be convenient for developing, testing, but from other hand - wouldn't it lead to much overhead to use container to instantiate every class from business domain even very simple ones??
Would someone tell me about it?
by the way i want to know how "tweak" objectbuilder strategy to implement in standard Resolve method strategy that I've described. Now I have overload that intercepts exception and loads requested assembly and then tries to call containers Resolve method again.
Thanks in advance!