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 new features borrowed from dryioc (C# IoC)

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)

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 some new features borrowed from dryioc (C# IoC)
>
> 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!

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.

--------->8---------
> Container gets confusing with std.container.
--------->8---------

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

* SimpleInjector (C#) uses Container
* 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

Unity uses UnityContainer. So there can be a discriminator in the name.

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.
>

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)

?

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.

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?

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.