Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updating Container #4

Open
vector-man opened this issue Apr 11, 2017 · 5 comments
Open

Updating Container #4

vector-man opened this issue Apr 11, 2017 · 5 comments

Comments

@vector-man
Copy link

vector-man commented Apr 11, 2017

Hi. How do you update an existing container?

With Autofac, for example, you could do this:

var builder = new ContainerBuilder();
// Register someething using builder...
 .....
// Update container
builder.Update(container);
@jgauffin
Copy link
Owner

It's been a design decision to not do it (for simplicity). Griffin.Container valides all build paths, dependecies etc at start. All that have to be done again if I had allowed updates. But more complex since instances are tracked. So since I've not needed to do that I have simply not implemented it.

If you need changes you typically use one of the creational patterns (factory, builder) and register that factory/builder class in the container.

If you describe what you want to to do, I might be able to propose an alternative.

@vector-man
Copy link
Author

vector-man commented Apr 11, 2017

I'm using ReactiveUI, which uses it's own service locator. It is possible (and sometimes necessary, if using an alternative container) to hook an existing container into the framework (sort of like this: https://github.com/alexeyzimarev/ReactiveUI.Autofac/blob/master/src/ReactiveUI.Autofac/AutofacDependencyResolver.cs)

But, the problem is, ReactiveUI's locator assumes you can register and resolve. This would require updating the container somehow.

(Note: the named registration code is not required as far as I know)

@jgauffin
Copy link
Owner

I would just keep the ContainerRegistrar in the GriffinContainerDependencyResolver and build a new container after each new registration (and replace the one in the _container field).

As long as there won't be thousands of registrations it shouldnt hurt performance or memory.

@vector-man
Copy link
Author

I got something together that works based on your suggestion. Thank you!

@jgauffin
Copy link
Owner

np. just glad that I could help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants