-
Notifications
You must be signed in to change notification settings - Fork 7
Home
InjectABL is an Inversion of Control container/Dependency Injection module that was created as part of the AutoEdge|TheFactory reference implementation. This project separates the InjectABL module from the larger AutoEdge code, and makes it available for independent use in an OpenEdge ABL application.
The InjectABL IoC component is inspired by, and largely based - conceptually and to a lesser degree code - on the Ninject DI container. While many DI/IoC products provide mapping facilities, the majority of them are XML based; Ninject starts with source code-based mappings, which can be extended to use XML. This provides more readability; in addition Ninject has usable defaults, and is relatively simple to use and understand. It is also itself easily extensible.
There's more information on usage at http://communities.progress.com/pcom/docs/DOC-105068.
The short and sweet answer is:
Dependency injection means giving an object its instance variables
Contained in that statement is the statement "the object does not manage it's instance variables' lifecycles, creation in particular".
There are 3 main injection patterns: constructor, method and property injection. We assume that constructor injection is intended for mandatory dependencies, and method and property injection is for optional dependencies.
Another good description of dependency injection is on the Ninject site.
While dependency injection means that an object does not manage it's own dependencies' lifecycles, the objects have to come from somewhere: this is an IoC container's purpose. It manages the lifecycles of the injected objects.
Why do we need such a beast? Most examples of dependency injection show reasonably simple examples; in these cases it's easy to see the concepts of injection. However, if we want our DI to scale, we need something to manage the dependencies. This is what the IoC container does, at the simplest level. Wikipedia has more, including pros and cons, and further reading. Note that the techniques available to IoC include the injection techniques above.
The reference implementation aims to provide extensible and replaceable components (since one size does not fit all). Coding to an interface is a strategy used to achieve this goal. From Wikipedia,
The use of interface allows to implement a programming style called programming against interfaces. The idea behind this is to base the logic one develops on the sole interface definition of the objects one uses and do not make the code depend on the internal details. This allows the programmer the ability to later change the behavior of the system by simply swapping the object used with another implementing the same interface.
When a class is coded against interfaces, there's an additional requirement to know which class to instantiate that implements that interface (since an interface cannot be invoked itself). This knowledge will take the form of some kind of mapping from the interface to the concrete class.
This ties nicely into DI, since we can inject the implementing (or concrete) object into the relevant object. Furthermore, since the IoC container manages these injected objects' lifecycle, we have the perfect place to keep the interface mapping information.