www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Endovena: a dependency injection framework.

reply "Orfeo" <orfeo.davia gmail.com> writes:
Hi all,

I'd like to announce the initial version of endovena, a 
dependency injection
framework.

It's based on dejector, a great work by Jakub Stasiak, with some 


I would be glad to see any feedback,
Thank you.

* [endovena] https://github.com/o3o/endovena Boost License 1.0
* [dejector](https://github.com/jstasiak/dejector)
* [dryioc](https://bitbucket.org/dadhi/dryioc)
Oct 17 2014
next sibling parent "Dan Cirnat" <dan alt.md> writes:
On Friday, 17 October 2014 at 22:55:24 UTC, Orfeo wrote:

 Hi all,

 I'd like to announce the initial version of endovena, a 
 dependency injection
 framework.

 It's based on dejector, a great work by Jakub Stasiak, with 


 I would be glad to see any feedback,
 Thank you.

 * [endovena] https://github.com/o3o/endovena Boost License 1.0
 * [dejector](https://github.com/jstasiak/dejector)
 * [dryioc](https://bitbucket.org/dadhi/dryioc)


Looks awesome, can't wait to try it!
Oct 21 2014
prev sibling next sibling parent reply "Chris Williams" <yoreanon-chrisw yahoo.co.jp> writes:
On Friday, 17 October 2014 at 22:55:24 UTC, Orfeo wrote:

 * [endovena] https://github.com/o3o/endovena Boost License 1.0


I would suggest naming the class something other than 
"Container". "Injector" or "Factory" or something.

Container gets confusing with std.container.
Oct 21 2014
parent reply "Orfeo" <orfeo.davia gmail.com> writes:
--------->8---------

 Container gets confusing with std.container.


--------->8---------

I agree with you, but 'Container' is widely used in DI context, 
for example:


* LightInjector uses ServiceContainer
* Autofac uses ContainerBuilder
* LightCore  uses ContainerBuilder
* Hiro uses MicroContainer
* LinFu uses ServiceContainer
* HaveBox uses Container
* Spring (Java) uses Container
* Hypodermic (C++) ContainerBuilder
* Poodins (D) uses Container


Furthermore std.container doesn't have a class named Container, 
so it's
difficult to confuse class endovena.Container with module 
sdt.container...anyway, I'll think about it.

Thank you very much for your feedback
Oct 22 2014
parent reply "Kagamin" <spam here.lot> writes:
Unity uses UnityContainer. So there can be a discriminator in the 
name.
Oct 23 2014
parent Rory McGuire via Digitalmars-d-announce writes:
Eeek please don't rename, people that find names confusing can use `import
endovena = o3o.endovena;` or something like that.

Keep names concise, although there are a lot of C++ devs in the D community
so perhaps you could just call it Contnr :D we all know how c++ guys like
their shortened names for no reason.

On Thu, Oct 23, 2014 at 9:17 AM, Kagamin via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:


 Unity uses UnityContainer. So there can be a discriminator in the name.
Oct 23 2014
prev sibling next sibling parent reply "JN" <666total wp.pl> writes:
I may be ignorant, can someone explain what's the difference 
between:

Container container;
container.register!(IGreeter, Greeter);
auto greeter = container.get!IGreeter();
writefln(greeter.greet)

and

auto greeter = new Greeter();
writefln(greeter.greet)

?
Nov 01 2014
parent reply "Gary Willoughby" <dev nomad.so> writes:
On Saturday, 1 November 2014 at 16:36:02 UTC, JN wrote:

 I may be ignorant, can someone explain what's the difference 
 between:

 Container container;
 container.register!(IGreeter, Greeter);
 auto greeter = container.get!IGreeter();
 writefln(greeter.greet)

 and

 auto greeter = new Greeter();
 writefln(greeter.greet)

 ?


It's the fundamental way dependency injection containers are 
used. Instead of having complex dependencies on other resources 
you can just rely on the container to serve resources as needed.

For example if you have a class which needs the Greeter service 
you will either have to embed that service using composition or 
pass it into the class via a constructor or setter. A container 
is a single place where this and many other services can be 
retrieved. This also means that anything wanting to use the 
container is also dependent on it but this is sometimes less 
complicated than dealing with all the other dependencies 
individually. Also some dependencies have complicated rules for 
creating them which some dependency injection containers deal 
with, again removing this code from where the resource is 
actually being used.
Nov 01 2014
parent reply "JN" <666total wp.pl> writes:
On Saturday, 1 November 2014 at 18:54:04 UTC, Gary Willoughby 
wrote:

 It's the fundamental way dependency injection containers are 
 used. Instead of having complex dependencies on other resources 
 you can just rely on the container to serve resources as needed.

 For example if you have a class which needs the Greeter service 
 you will either have to embed that service using composition or 
 pass it into the class via a constructor or setter. A container 
 is a single place where this and many other services can be 
 retrieved. This also means that anything wanting to use the 
 container is also dependent on it but this is sometimes less 
 complicated than dealing with all the other dependencies 
 individually. Also some dependencies have complicated rules for 
 creating them which some dependency injection containers deal 
 with, again removing this code from where the resource is 
 actually being used.


But then you have to pass the container around? Or you make it a 
singleton?
Nov 01 2014
next sibling parent "Kagamin" <spam here.lot> writes:
Usually an object receives all needed dependencies with the 
constructor and thus doesn't need the container itself. Well, 
either way, it's better to pass one object around instead of ~10 
or more.
Nov 01 2014
prev sibling parent "Gary Willoughby" <dev nomad.so> writes:
On Saturday, 1 November 2014 at 19:19:51 UTC, JN wrote:

 But then you have to pass the container around? Or you make it 
 a singleton?


Basically yes.
Nov 02 2014
prev sibling parent reply "George Sapkin" <george.sapkin gmail.com> writes:
On Friday, 17 October 2014 at 22:55:24 UTC, Orfeo wrote:

 Hi all,

 I'd like to announce the initial version of endovena, a 
 dependency injection
 framework.

 It's based on dejector, a great work by Jakub Stasiak, with 


 I would be glad to see any feedback,
 Thank you.

 * [endovena] https://github.com/o3o/endovena Boost License 1.0
 * [dejector](https://github.com/jstasiak/dejector)
 * [dryioc](https://bitbucket.org/dadhi/dryioc)


Am I missing something or is this a Service Locator anti-pattern? 
More about it here: 
http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern/
Nov 19 2014
parent "o3o" <orfeo.davia gmail.com> writes:
 Am I missing something or is this a Service Locator 
 anti-pattern? More about it here: 
 http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern/


Service Locator is *really* an anti-pattern, but endovena (and 
also dejector) is a Dependency Injector (DI) framework, opposite 
of Service locator 
(http://www.infoq.com/articles/Succeeding-Dependency-Injection)
DI is the solution to the principle of Inversion of Control 
(IoC), and DI Framework is a Framework (!) that help you to 
implement DI.

So, using Mark Seemann example:


public class OrderProcessor : IOrderProcessor
{
     public void Process(Order order)
     {
         var validator = Locator.Resolve<IOrderValidator>();
         if (validator.Validate(order))
         {
             var shipper = Locator.Resolve<IOrderShipper>();
             shipper.Ship(order);
         }
     }
}
```

Using DI you should write:

```D
class OrderProcessor : IOrderProcessor {
     private IOrderValidator validator;
     this(IOrderValidator validator, IOrderShipper shipper) {
       assert(validator !is null);
       this.validator = validator;
       this.shipper = shipper;
     }

     void Process(Order order) {
         if (validator.Validate(order))   {
             shipper.Ship(order);
         }
     }
}
```
in this version of OrderProcessor there is no Locator: the 
dependencies (IOrderValidator and IOrderShipper) are passed 
through constructor.

But... where is DI framework?


Endovena helps you to inject service into clients:

```D
import endovena;

void main() {
    Container container = new Container;
    container.register!(IOrderValidator,OrderValidator);
    container.register!(IOrderShipper,OrderShipper);
    container.register!(IOrderProcessor,OrderProcessor);

    auto processor = container.get!IOrderProcessor();

    processor.Process(order);
}

```


DI isn't easyto understand, but it's a very powerful pattern.

Some links:

* 
http://www.theserverside.com/news/1321158/A-beginners-guide-to-Dependency-Injection
* 
http://geekswithblogs.net/chrisfalter/archive/2008/02/15/new-statement-considered-harmful.aspx
* 
http://comoyo.github.io/blog/2013/02/06/the-inverse-of-ioc-is-control/
* 
http://www.loosecouplings.com/2011/01/dependency-injection-using-di-container.html
Nov 19 2014