simong96 / lightweightioccontainer Goto Github PK

Can you register and resolve only a Type without creating an referencing an interface for it?

Add a callback method (like UnitTestResolveCallback) to the IocContainer.

This method should be called on IocContainer.Resolve<>() and should only be used from unit tests.

Decide on a different name than Injector and refactor all its current occurrences.

• IInjectorContainer
• InjectorContainer
• IInjectorInstaller
• InjectorContainerTest
• check messages and exceptions
• comments
• Documentation

Create an example project to see how to use the LightweightIocContainer and to have a project where debugging is made easy.

See here for help.

Maybe use some tool like appveyor for this

Add Instance() method to DefaultRegistration to return the given instance when the registered type is resolved.

This should only be possible for Lifestyle.Singleton.

The user should be able to pass a parameter to the constructor of the registered class from the IIocInstaller. This has to be possible within the fluent registration of the type (similar to OnCreate()).

Initial idea:
Add a function Parameters(params object[] parameters) to IDefaultRegistration<> and pass the given arguments to the ResolveInternal<>() or the CreateInstance<>() method when the type is resolved.

Problem:
If multiple parameters of the same type are passed through different ways (passed directly to Resolve<>() or new Parameters() method), how does the container know when to use which parameter?

Simplify the registration process in an IIocInstaller:

• Make IocContainer.Register() private/internal
• Add Register<>() methods from RegistrationFactory to container
• Make RegistrationFactory internal
• Remove IIocContainer parameter from the RegisterFactory<>() methods
• Call RegistrationFactory methods from their counterpart in the IocContainer
• Change calls from IIocInstallers

Add an AssemblyInstaller that can take all IIocInstallers of an assembly and install them without the user needing to add them specifically.

Rewrite CreateFactory() method in TypedFactoryRegistration.

Decide how to change it for better readability and maintainability.

See here for problems with the current implementation.

For example check if type is already registered or not...

On IoC container dispose, created disposable singletons / multitons should also be disposed

Fix the important problems with the CreateFactory() method in TypedFactoryRegistration.
This is related to #4, but in contrary to that issue these are important bugs that need to be fixed as soon as possible.

See here for problems with the current implementation.

Add Lifestyle Multiton to Lifestyles.

• add Multiton
• adapt ResolveInternal() to handle multitons

Add a Validate() method to the IIocContainer that can be called from a test and checks if all registered types in the given installers can be resolved.

Add a public exception base type with InnerExceptions that can be handled by user applications.

Add a method to the IocContainer that checks if a given Type is already installed or not.

Change the List<> that is used for the _singletons and _multitons in the IocContainer to a ConditionalWeakTable<> to allow garbage collection once a TScope is destroyed.

• Multiton only inside specific class
• different user specific scopes?

Convert the used nuget packages to private assets so that if the LightweightIocContainer is used by another project the nuget packages aren't consumed by it.

See also https://docs.microsoft.com/de-de/nuget/consume-packages/package-references-in-project-files#controlling-dependency-assets

Create overloads of the Register and RegisterFactory functions in RegistrationFactory to enable registration of open generic types.

Is an abstract factory that has a Create() method with an argument with the params keyword working?

The OnCreate() method should not pass the registered interface to create an action:

It should pass the implementation that is registered for the given interface.
This simplifies #33 because we don't need to have multiple Action<T> for an OnCreate() method.

Test if the NoMatchingConstructorFoundException is working as intended when the first constructor that is found is not matchting but another matching one is found.

If an interface type is expected as a constructor parameter, but the given argument is of the type of the implementation, in the function ResolveConstructorArguments() the parameter can't be assigned to the correct parameter.

This happens because we only check for

fittingArgument = argumentsList.FirstOrGiven<object, InternalResolvePlaceholder>(a => a?.GetType() == parameter.ParameterType);

We also have to check for

parameter.ParameterType.IsInstanceOfType(a)

Allow the registration of multiple interfaces for one Type that are of the lifestyle multiton.

e.g. on resolve() if ABC ctor needs IDEF and IGHJ
display something like: could not resolve IABC because IDEF could not be resolved!

The non-generic register methods like IIocContainer.Register(Type, Type, Lifestyle) can be removed from the IIocContainer and the RegistrationFactory.

UnitTestCallbackRegistration is no longer needed, use WithFactoryMethod() from ISingleTypeRegistration instead.

Handle the parameter value null in method ResolveConstructorArguments().

• Create nuget package
• Check for all needed information
• Certificate?
• Publish nuget package

• Description
• Readme
• Wiki

Currently when trying to find a possible constructor, missing arguments are resolved if possible:

Whenever a constructor isn't selected there still might be arguments that get created.
If these arguments are registered as singletons they are created, added to the instances list and might not even be needed.

Try to find an option to check if constructors can be used without creating arguments first. If the constructor is selected the arguments can be created.

Make classes and functions as private as possible.

Change classes to internal when they shouldn't be used by a user.

Allow the registration of multiple interfaces for one registered type, e.g.:

The interface

public interface IFoo : IBar { }

is implemented by

public class Foo : IFoo { }

Users may want to get a IBar or a IFoo and both times need the implementing type Foo.
The registration should look something like this:

container.Register<IBar, IFoo, Foo>();

For registrations with Lifestyle.Transient this could be done by calling IIocContainer.Register<>() multiple times:

container.Register<IBar, Foo>();
container.Register<IFoo, Foo>();

What can be done for registrations with Lifestyle.Singleton? Every Resolve<>() call has to return the same instance of the implemented type.

Add an exception that gets thrown when none of the existing constructors match the given or resolvable arguments.

Use the existing try-catch in ResolveConstructorArguments():

Create a new exception type that derives from AggregateException and lists the constructors that can not be used.

Instead of the current registration append factory registration fluently:

IocContainer.Register<TInterface, TImpl>().WithFactory<TFactory>();

The following steps should be completed before a new version is released:

• Update version number in Properties
• Update version number in AppVeyor settings
• Create GitHub release
  • upload nuget package to release
  • update release notes for release
  • add fixed issues to release notes
• publish nuget package to nuget gallery
• update demo project with new features
• check for more old version numbers

Allow resolving of an implementation that is registered with an interface.

Registration:

container.Register<TInterface, TImplementation>();

Resolve:

TImplementation impl = container.Resolve<TImplementation>();

Add a check in ResolveInternal<>() to find circular dependencies and throw an exception.