christav / diceioc Goto Github PK

This was replaced by LifetimeScope.

Quick, what's the difference between LifetimeContainer and LifetimeScope? Registrar and Catalog?

Come up with a better set of names for stuff, then apply them consistently.

Saves an extra line, so instead of:

using(var s = new LifetimeScope()) {
    var c = container.InScope(s);
    c.Resolve<IFoo>();
    /// do stuff
}

We could instead do:

using(var c = container.InScope(new LifetimeScope()) {
    c.Resolve<IFoo>();
    /// do stuff
}

Also consider adding InNewScope method to simplify the above using line a little more.

Would we be able to make lifetime containers and scopes look the same from the end user's point of view, so they don't need to know two concepts?

Provide a class users can implement that will register stuff in the container when new'ed up - allows for easy modularization/reuse of configuration.

TryResolve follows the usual TryAction pattern, returning a bool and using an out parameter. Which makes it impossible to call from an expression tree, which means we can't use TryResolve to resolve an optional parameter in a registered function.

Add an ResolveOptional method that will return default(T) if the type in question is not registered. This lets us support optional dependencies easily.

We have Resolve(Type) and company now, we should inline those too.

Provide a way to add additional disposable objects to lifetime scope at resolve time that will get disposed with the scope. Example usage: pooled lifetime, where when the scope goes away the objects get released back into the pool.

I should be able to do:

catalog.Register<IFoo, Foo>();

and the catalog should figure out which constructor to call based on what else is registered.

Define what our exceptions should be under what circumstances, and apply the design across the codebase.

Should we have a base exception? Or a couple? ConfigException/ResolveException, maybe?

Support setting properties through the container on an object that's already been created by some other means.

Would let us do something like this:

catalog.Register<IFoo>(c => new Foo(), Scope.Lifetime("perrequest"));
catalog.Register<IBar>(c => new Bar(c.Resolve<IFoo>()), Scope.Lifetime);

And let us have multiple instances of lifetime scopes at resolve time.

Catalog code is a tangled mess right now. Come up with cleaner design that allows easier composition of different catalog implementations.

Figure out a way to cleanly combine the various kinds of registrations into a single coherent registration API for end users that vectors down to the various catalog implementations.

1. Rename the class - ResolutionScope?
2. Remove the Scope class, move Lifetime property to ResolutionScope
3. Delete the Thread safe scope - why would you be resolving in the same scope in multiple threads?

On second thought, I could see "Use case wide" scopes that might hop threads. But still, shouldn't you have one composition root? Yeah, we can ditch this for now - bring it back if we find an actual use case.

It's really confusing as to what's where, the public stuff isn't consistently in any spot. Clean it up so it's obvious what feature is in what directory.

http://www.lightinject.net

Set up .nuspec file, build so we can have an easily usable nuget package.

We should be able to do Resolve<Something>() when Something is a concrete type that we can satisfy the dependencies of, even if Something isn't explicitly registered.

Playing with webhooks.