This project is read-only.
DynamicUnityContainer documentation
The DynamicUnityContainer is a Dependency Injection container that allows for interfaces that contain only properties to be directly registered as types. When you register a list of property-only interfaces with the container, it dynamic creates the types for you at runtime.

I have recently adopted a new coding standard for all my projects. It states, among other things, that:
An interface may:
  • Declare either properties or methods, but not both
An class must:
  • Implement a single interface that exposes all of it's public methods and properties
A class may not:
  • Contain a reference to another class that is not a 'basic' type (primitive or system struct, such as Datetime).
The idea behind this last one is that all coding is done against interfaces, and classes either represent data or manipulate/act on data, but not both.

The discussion of the pro's and con's of this approach to coding is outside the scope of this discussion. What is relevant is that it brings to light a common issue/problem faced by development teams when coding against interfaces in a tradition fashion:
It is easy for a class to get out of sync with the interface it represents
  • When a method/property is removed from an interface, the compiler does not require you to remove it from the implementing class
  • It is fairly common for inexperienced devs to add properties/methods directly to a class rather than an interface, which is often not caught by the compiler.
When a class represents only data properties, then:
  • the representing class is simply a duplicate of the interface, and the maintenance requirement is redundant
  • when a property is added to the interface it also must be added to the implementing class. This code is identical to the interface code, with the addition of the 'public' access modifier

Usage examples:
//TODO: finish

Last edited Mar 24 at 4:58 AM by nhuntera, version 4