Today at work, my boss and I were brainstorming on the best way to use IoC across all our code. During this, he proposed an idea for using IoC that at first made me feel uneasy with the way it was being used. But the more I think about it, the more I am amazed by its design. Let me set this up for you and the best way is with pictures.
Note: The code examples given here are not functional and just provided to give a rough idea of what is intended.
Explanation:
- The BaseLib is a library that contains all the interfaces we define. It also contains the CDepInjection class.
- The CDepInjection class contains a static Register method that will find an assembly that corresponds to an interface and using Reflection, load it.
- The Database library contains a CDatabase class with a static constructor that will be called from the previous step when the Database library is reflected and loaded. See image below.
Benefits:
- By having all the interfaced in BaseLib, we are programming against an interface.
- By having the CDepInjection class in BaseLib, there is only 1 place we need to update code and only 1 dll that we will need to deploy in production should changes be needed. (Note: We could have 100 servers running 100 application each and they may be windows services, web services, asp.net mvc apps, windows forms apps, console apps etc.).
- By making a change in CDepInjection and telling it to map an interface name to the appropriate assembly and class and having the RegisterType be in the CDatabase class, we can create a new database class, CNoSqlDatabase in another assembly, deploy it, make a change to BaseLib by telling it to now map IDatabase to the CNoSqlDatabase and then deploy that to all our servers GAC. Now, everything will use the new CNoSQLDatabase.
Concerns I have:
- Using a static constructor in CDatabase means that it will be called one per process and only when the assembly is loaded in the Register(..) method of CDepInjection. I’m not convinced that a static constructor would be the best thing to do. In essence, aren’t we just abstracting the mappings that would go in a config file and putting them into BaseLib instead of an app.config of BaseLib?
- Resolving parent-child would necessitate having to call register in the ‘main’ method of all our applications. For instance, if CDatabase was going to need logging, it would have to call Register(“ILogging”) in the static constructor above the Container.RegisterType<IDatabase, CDatabase>() call.
I would very much appreciate a critique of this design. Thank you.
Aboutdev's Weblog 