Projects tagged ‘container’ and ‘di’

PicoContainer is a lightweight and highly embeddable container for components that honour Dependency Injection. Despite it being very compact in size (the core is ~100K and it has no mandatory ... [More] dependencies outside the JDK), PicoContainer supports different dependency injection types (both CDI and SDI) and offers totally customisable lifecycles. PicoContainer has originally been implemented in Java but is also available for other platforms and languages. [Less]

NanoContainer is a container for components honouring dependency injection. NanoContainer builds on top of PicoContainer the support for several scripting meta-languages (XML, Groovy, Bsh, Jython ... [More] and Rhyno), AOP, Web frameworks (Struts and WebWork), Persistence (Hibernate) SOAP, JMX, and much more. [Less]

This project provides a unified and real-world use case and set of classes that are used to showcase the various available Dependency Injection containers. The domain model is based on the DI overview ... [More] post at Dependency Injection in Ruby. The purpose of the project is to allow developers to easily compare the containers to make an informed decision when picking one. Performance comparisons may also be performed by using the same use case. [Less]

If you're looking for a very simple IoC library in PHP to wire up simple dependencies and you can live with constructor dependency injection this is the project for you! Features (currently): ... [More] Constructor dependency injection Ability to inject static values as constructor parameters Can traverse dependency chain and initialize a dependency structure Very simple INI style configuration Can detect circular dependency at runtime [Less]

The ComponentDependencyGraph (cdg) library allows you to define the dependencies between .NET components using a FluentInterface. Its purpose is to manifest the component architecture of an ... [More] application in code. Once this is done, the mapping for Dependency Injection (DI) containers (DIC) like Microsoft Unity or Ninject or Castle Windsor can be created from the dependency graph. Most importantly, though, from the internal dependency graph a dependency diagram can be generated. The cdg thus is able to regenerate an architecture visualization at any time from code. It thereby helps to enforce the DRY principle: an application´s architecture needs not to be maintained in two places (documentation and code), but rather is kept in a single place: the code. Although an architecural plan is always implicitly present in the code implementing it, it cannot easily be extracted from it as needed. Tools like NDepend might help - but they have a hard time depicting dynamic relationships between components when contracts and implementations are separated. The cdg closes this gap by taking well established DIC mappings one step further in an DIC independent way. [Less]

Usage Manual Using The Container As a Factory, And No More "new" Statements! In this first example we learn how to obtain class instances from a Gamba Container, and how it decouples your component ... [More] implementation from each others. Everybody knows that hardcoding is a bad practice... but whenever you place a new statement in your code, you are really taking a concrete class implementation in a hardcoded way! For example, supposing that you wants for a java.util.List implementation instance, and you choose a java.util.ArrayList: List list = (List) new ArrayList();Well, but if you want to choose another implementation for a List, you will have to change all your classes that news it. Lechuga solves this problem, since the concrete implementation class is uniquely declared in a context file as is: After declaring the class implementation, you can obtain an instance of this, calling the Gamba Container: GambaContext gc = GambaContainer.getContext("tips-context.xml"); List myList = (List) gc.getBean("myList"); Assert.assertTrue(myList instanceof List); Now, if you want to choose another implementation for a List (i.e. LinkedList), you only must have to change the class specified in a context file, and all your classes that instantiates it will obtain the new implementation: Dependency Injection Dependency Injection means to inject recursively into your requested bean instance his declared dependencies. This feature allows you to obtain a desired bean instance (obtained by a Factory, in fact), fully configured and ready to use, altought his object-dependencies are being injected. Setter Injection For example, suppose that you have in hands: In the above example, a "b" instance are being injected to an "a" instance using setter injection. When you asks the container for an "a" instance, the container works for you and performs reflect operations to do the same as the following piece of code: A a = new A(); B b = new B(); a.setB(b); return a; Constructor Injection A constructor injection is another kind of injection. For example the definition: will cause that when a "b" instance is requested, container performs: A a = new A(); B b = new B(a); return b;Gamba Container Don't Works Lazily, just Eagerly In order to prevent unexpected exception throwing at run-time, all bean definitions are parsed and loaded in context loading-time (that is, when you calls GambaContainer.getContext(...)), performing a check of all defined beans, thinking about her future life-cycle. --> [Less]

A framework built around an AOP/dependency injection container

Simple template based Dependecy Injection framework for C++.

First of all let's talk about what is an IoC framework. It's a framework that implement the Inversion of Control pattern, most of the time to perform dependency injection to decouple an object from ... [More] its dependencies. Instead of hardcoding the dependencies of the objects, using the new operator or the factory pattern, you let the framework do it for you. To perform it, you just have to register your classes in the container, and then tell the framework to create an instance of that class. This kind of framework allows to develop solution easier and to reduce the cost of the change in the software. It allows to move configuration closer to the place it is used. To summarize, an IoC framework allows you to produce a more flexible and more configurable application. This framework is very similar to the Windsor Container framework, because that's the one I use and because it's configuration seams much more flexible to me that the Spring way of doing. Of course my framework doesn't perform as much things as Windsor, Spring or others, but my goal wasn't to develop a competitive framework but to do an interesting project. The particularity of this IoC framework is that it doesn't use Reflection to create objects dynamically. It only uses it to obtain the constructor definition (once for each component). To instanciate the component, it uses lambda expression from the LinQ framework, that's much faster than using Activator (the Reflection way). It manages different lifestyles for the components: Transient (the default lifestyle): creates a new instance of the component as requested. Singleton: creates only one thread safe instance of the component for all the application Thread: creates only one instance of the component per thread. Registering components can be made both by code and configuration file. Component name, type, service, lifestyle and specific parameters can be defined. This IoC framework don't implement setters injection to prevent from using Reflection and still having an efficient framework in any case. The framework is fully tested using MbUnit and NCover [Less]