"How it works?" part for README about stronginject HOT 4 CLOSED

Thanks for the suggestion.

I think there's definitely room for that in the Readme. I'll have to think about how exactly to structure it.

In answer to your questions:

Why do I need IContainer, do I need multiple containers?
Do I need one container for every single dependency to be resolved? That sounds awful lot of boilerplate code compared to current IoC solutions.

I'll answer these together.

T in IContainer<T> represents your top level services you need to resolve. This is the service that you'll actually directly use. Ideally there would only ever be one of these, and everything else would be a dependency of this service.

So for example, if you have a bunch of components, Service1 Service2, Service3 etc. which are all used by an App class your container would look like this.

[Register(typeof(Service1))]
[Register(typeof(Service2))]
[Register(typeof(Service3))]
[Register(typeof(App))]
public class AppContainer : IContainer<App> {}

And usage would look something like this:

new AppContainer().Run(app => app.Run());

In cases where you have many top level services, you still don't need to create multiple containers, as you can implement IContainer multiple times:

public class MyContainer : IContainer<TopLevelService1>, IContainer<TopLevelService2>, IContainer<TopLevelService3> {}

The purpose of IContainer<T> is to tell StrongInject what methods it needs to generate. For any container there's an infinite set of things StrongInject can resolve from that container (e.g, if you register MyClass, it can resolve MyClass, MyClass[], MyClass[][], MyClass[][][] etc.). Generating an infinite set of methods is obviously impossible, so instead we use IContainer<T> to tell StrongInject exactly what methods to generate.

How is compile time safety ensured and in what cases it is not (erm asp.net core?)

This is simple.

If you implement IContainer<T> StrongInject will make sure you can always resolve T. However if you integrate with other DI containers, StrongInject can't guarantee whether they will error.

from stronginject.

I am asking this because after scanning through the README file multiple times I still have no idea how does it work, some random questions appear like:

• Why do I need IContainer<T>, do I need multiple containers?
• Do I need one container for every single dependency to be resolved? That sounds awful lot of boilerplate code compared to current IoC solutions.
• How is compile time safety ensured and in what cases it is not (erm asp.net core?)

And more.

from stronginject.

I'm thinking of adding a section as follows. I would appreciate your input on it!

How It Works

To use StrongInject, you first need to tell StrongInject the top-level services you would like to resolve. You do this by adding a new class implementing IContainer<T>. This will be your container. If you want to resolve multiple top-level services, then you can implement IContainer<T> multiple times on one container, or create multiple containers. StrongInject will then check at compile time that you've registered everything you need with the container to enable it to resolve all the top-level services. If you haven't, the compilation will fail with an error explaining what's gone wrong.

For example, if you want to resolve MyApp you might try doing this:

using StrongInject;

public class MyService {}
public class MyApp { public MyApp(MyService myService) {} }

[Register(typeof(MyApp))]
public partial class MyContainer : IContainer<MyApp> {}

When you try compiling, it will fail with the following error: SI0102: Error while resolving dependencies for 'MyApp': We have no source for instance of type 'MyService'.

Now you fix it by adding a registration for MyService:

using StrongInject;

public class MyService {}
public class MyApp { public MyApp(MyService myService) {} }

[Register(typeof(MyApp))]
[Register(typeof(MyService))]
public partial class MyContainer : IContainer<MyApp> {}

And this time when you compile, it will succeed and generate all the code needed to resolve an instance of MyApp at compile time.

What do I mean by a top-level service?

When using an IOC container, sometimes you request an instance from the container directly. These are top-level services. Most of the time the container resolves something though, you never ask for it explicitly - instead it's needed as a dependency for something else, which may itself be a dependency or a top-level service etc.

Ideally you want IOC containers to be non invasive - this means you write all your code as if there was no container, and then just use the container once to bootstrap your code. When writing code like this there should only ever be one top-level service. Sometimes this is not possible - for example when integrating with Asp.Net Core your controllers will usually need to be top-level services, but you should always try to minimize the number of top-level services where possible.

The next section will go into more detail about exactly how to register stuff with containers, and how to use them.

from stronginject.

Now added to readme

from stronginject.