Basic IoC container with unit tests.
This project provides a simple to use inversion of control framework for use with the .NET micro framework.
The container is optimised for use with singletons and can be configured by using the IContainerInstaller interface.
Could be be used as part of a plugin framework. Check out the unit tests for full details.
@ Robert,
Welcome to the community, and thank you for your contribution. Your project looks very interesting. I havenât done much research in this area, but are there other IoC/Test frameworks available for NETMF? Yours looks very easy to use. Iâll give it a try on my next project.
@ jasdev,
Awesome, I hope you find it useful⌠If you need any help just let me know and Iâll be happy to assist.
Iâm not sure if there are other IoC or unit test frameworks for NETMF. I did this mostly to learn the capabilities (and limitations) of NETMF (this was the first bit of code I wrote for my FEZ Spider)
Iâm planning on making the unit test side of this a little neater⌠just need to see if I can work around some of the limitations on reflection that NETMF has.
If people find this useful Iâll see about making the container do a litte more that it does now (better lifestyle management, property injection)
I would guess that IoC containers are few and far between for embedded systems, because generally the goals in embedded development are:
[ul]Small code (code storage is often limited, and using more often means more parts or more expensive parts)
Fast code (CPU power is limited, and smaller/less powerful CPUs are cheaper and use less power)[/ul]
IoC, while a fine design pattern (if you, as I do, consider IoC to simply be the principal that users of a class are given the implementation instead of constructing it themselves), is entirely implementable without service locators and containers which go against the above principals.
@ godefroi
I donât see how using an IoC framework would go against either of thoes two principles given that my implementation is neither fat nor slow.
I also disagree with the implication that the IoC container is an expensive thing to have in an embedded system. As systems grow the cost of having the container significantly diminshes over the benefits gained by having the container.
Yes, you can do all of this without a framework, but weâre not just talking about having maintainable code through losely coupled systems. Weâre also talking about having applications that are by their very nature modular, and whole point of the framework is to automate the heavy lifting of managing the components within the system.
Application compositision is the goal of my container, not service location (which is an anti-pattern and I completely discourage the use of). Sure there is a cost of having the container resolve the dependencies, namely some relfection to find and match constructors to dependencies, whcih in the case of singletons is optimised to a dictionary lookup for subsequent resolutions (hence why I said the container is optimised for singletons), thing is, all of this is done during the composition phase of the application and wouldnât be noticable anyhow.
There is a use case for an IoC framework as demonstrated by this [url]http://wiki.tinyclr.com/index.php?title=Dynamic_Assembly_Loading[/url]. A plugin framework is a type of dependency injection, and this scenario is completely covered by my container.
Note that I said: [em]generally the goals in embedded development are[/em]
If your goals are different, then thatâs great. Generally, however, the goal is to do more with less, and if the cost is greater than zero, then thatâs real money youâre talking about, and the bean counters donât comprehend âmaintainable code through loosely coupled systemsâ.
Also, embedded applications are generally not developed to be modular. Theyâre developed to do one thing over and over through their entire life. Dynamic assembly loading, while possible on NETMF, isnât the sort of thing you encounter in normal embedded development.
Iâm not trying to discourage you, Iâm just explaining why you havenât seen this sort of thing before in embedded development.
@ RobertODonnell - This IOC container was from some time ago, but I wanted to say that itâs very cool to be able to apply these patterns to this environment.
As a software developer with a desktop and server background itâs very easy to get the feeling you are going against good âembeddedâ design principles by incorporating higher levels patterns but that seems to me to be the whole point of NetMF in the first place.
One small addition I made was to add a method to the Component class with a signature of âWithValues(params object[] values)â and then loop over the values which lead to a nicer syntax for constructors with more than one argument.
I am struggling with how to deal with optional âargumentsâ as the NetMF reflection classes are limited but that can be âfixedâ by always building classes with constructor chaining.
All in all I reckon its awesome, Thanks!