Hi Matt, this is similar to what i did in my initial post.
http://github.com/lanwin/Autofac.WindsorAdapter
But maybe it it really a batter solution to use MEF since Ayende did it
in Raven.
On 30.01.2011 21:06, Matt Burton wrote:
Sorry, just getting around to this... Looks a lot better for sure -
much simpler. Something occurred to me as I was about to wax poetic
about not spreading implementation knowledge over multiple sources
(i.e. the saga type warnings/hints for the user that are duplicated in
both the Castle and StructureMap implementations) why do we
necessarily care whether StructureMap or Castle or Autofac or whatever
is driving the entire framework? Why not pick one, and then add an
extension point that would allow a component to be resolved from an
external source on demand? Almost like a service locator but not
quite.
Let's say Castle was the core framework - I could create a
subdependency resolver that defers to another component to resolve
dependencies, no? So let's say you make an IDependencyResolver, like
this:
interface IDependencyResolver
IResolutionContext CreateContext();
interface IResolutionContext : IDisposable
T Resolve<T>();
So I can create an AutofacDependencyResolver, etc... and feed it my
container instance where I've registered the dependencies I care
about. I could take it a step further and implement my own
ISubscriptionStorage if I wanted to replace that part of RSB for some
reason because the subdependency resolver in RSB is smart enough to
check the IDependencyResolver I registered first, then fall back on
whatever it wired up internally.
The IResolutionContext bit (doesn't sound right, IComponentContext?)
is all about component lifetimes and avoiding inadvertent memory leaks
due to unreleased components. Basically the main place this would be
used would be the execution of a consumer - something like this pseudo
code:
using (var contextContainer = new WindsorContainer())
{
using (var context = resolver.CreateContext())
{
contextContainer.Kernel.Resolver.AddSubResolver(new
ExternalDependencyResolver(context));
container.AddChildContainer(contextContainer);
var consumer = contextContainer.Resolve<MyConsumer>();
...
}
}
Then you could internalize the IoC container RSB uses entirely and
even ILMerge everything together for a single assembly delivery of the
framework. (i.e. so I don't keep forgetting to reference
Rhino.Queues.dll even though I'm only using MSMQ<grumble>) I used
Windsor as the example here, but the internal IoC container could just
as easily be Autofac, StructureMap, Funq, etc... just as long as the
needs of the core framework are satisfied in terms of component
lifetime expectancy, etc... The framework would obviously have a
default resolver built in that would either be a no-op or defer to the
internal container instance.
The only limitation I can think of is something in my container, a
dependency of a dependency of a dependency sort of scenario relies on
something that only the internal container knows about, like
IServiceBus, but perhaps there's a way around that. Regular message
consumer dependencies would be served up by a combination of the
internal container instance and the external resolver, so at that
level there wouldn't be any issues, just the scenario I mentioned
above would be problematic. The only way around that is to offer the
ability to register components as well through this DI abstraction and
then RSB uses that to register all of it's internal components as
well, but that always leads to sacrificing container-specific features
for the sake of creating a generic abstraction.
Of course I'm tired and burning both ends of the candle on my current
project, so this could all be written off as a delirious rant, you
tell me. Thoughts?
On Thu, Jan 27, 2011 at 11:41 AM, Corey Kaylor<[email protected]> wrote:
I finally got some breathing room to work on this a bit more. I ended up
going another way. With the *single* class to register things wrapped behind
an interface. This allowed the container implementation to be much simpler
and removes any conditional concerns. I have implemented a StructureMap
container, which I'm very doubtful works at this point, but I'll begin to
work through some tests to make sure it's all wired up correctly. I did a
rebase this time against the current master so if you pulled it down before,
you may need to remove your local branch and pull again if you want to take
a look.
-Corey
--
You received this message because you are subscribed to the Google Groups
"Rhino Tools Dev" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rhino-tools-dev?hl=en.
--
You received this message because you are subscribed to the Google Groups "Rhino
Tools Dev" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rhino-tools-dev?hl=en.
