Closed cocowalla closed 5 years ago
IContainer
that shouldn't be valid on a nested container, but I can't say that I remember exactly what those are offhandcontainer.Configure
at some point?Oh, and don't ascribe to conscious thought what's probably the result of accidental evolution;)
The Configure()
thing is a huge mess internally and makes the internals crazy hard to deal with if you let folks change the configuration on the fly. With Lamar, I was mostly worried about two things, performance and making the project as easy as possible for me to maintain. To get there, I have purposely sacrificed some of the flexibility that StructureMap had.
I do remember now, I didn't use SErviceRegistry on purpose because you can't allow users to add any kind of policy.
I'm open to changes though. Like something that's a subset of ServiceRegistry maybe? And I wouldn't mind eliminating INestedContainer anyway
I was curious about the rationale for a couple of design decisions that have been pain points for me after trying Lamar on some new projects.
This isn't a criticism BTW, I'm genuinely just curious about the thought process behind these decisions :smiley:
Calling
Configure
on an existing container (I know you're not a fan of this, but it's done a lot) only lets you change config using a Microsoft-styleIServiceCollection
, rather than the Lamar-styleServiceRegistry
. This means you don't get the full power of Lamar (e.g. to add named instances), and is quite limitingWhy doesn't
INestedContainer
implementIContainer
? This severely limits how you can configure an existingINestedContainer
, and having 2 different types for the 'same' thing is a bit of a pain