Introducing Vessel
Thursday, October 31, 2013
Sorry to frighten you on this Hallow's eve, but this post is not about yet another mediator. :-]
After finishing Liaison, I found myself coding in anger. What else could I cull from my stack? The obvious answer:
Kill the IoC Container.
Inspired by Ayende's IoC container in 15 lines of code, I wrote Vessel as a stripped down IoC on which to hang the mediator and any other singletons. I bloated it up with some extra features, like registering a constructor function, but it's still small enough to read without scrolling. Vessel doesn't even have it's own GitHub repo yet.
For so few lines, I was able to remove both Autofac packages from my project. Right away, I'll stipulate that my container usage on this blog is beyond trivial. If I find myself in trouble, I can install-package my way back home again.
I think I am seeking bedrock. I want to know the pain that causes me to use a framework or library. I am way up the abstraction hierarchy here, but digging.
One interesting discovery I made through this exercise: a controller is a class that has exactly one dependency and that dependency is IMediator. I think this fact can be exploited in the future, but for the moment, I'm happy with this small victory.
If you see a mistake in the post *or* you want to make a comment, please submit an edit.
You can also contact me and I'll post the comment.
The one thing I'm not sure about is how you've IoC component depends on MVC. If I wanted to use this in a console app or a WPF project I'd have to create a reference to MVC for the IDependencyResolver interface.
**you're not you've :D
I guess if I want to edit my previous posts I shouldn't be posting as a guest.
It doesn't depend on MVC, only VesselDependencyResolver does: https://github.com/kijanawooda...
And that only exists to connect Vessel to MVC. The rest you can take use wherever.
If this was in nuget, VesselDependencyResolver would be in a separate package named Vessel.Mvc. As is, don't copy paste that class. :-]
Makes sense. I guess if your framework is typically constructing a top level object (like a controller or an SVC file or whatever) you have to wire in your container somehow.
Yeah. That is asp.net MVC's way to wire in your container: IDependencyResolver.
They actually have quite a few hooks into the pipeline, but for most folks, you pick your IoC and use it's IDependencyResolver implementation. This is AutoFac's version I was using: https://github.com/kijanawooda...
Isn't life cycle management a 'key' (read: core) feature of an IoC container? And that leads to dependency life cycle management. I look at it as a smell when an application uses an IoC container but delegates no object life cycle and dependency life cycle management to the container.
Vessel provides Singleton and also "Instance per xyz" via the Func registration. Whether the instance is "per request" is determined by usage. This is inline with other IoC containers that have separate nuget packages to do per request. https://code.google.com/p/auto.... That makes sense because "per request" means something different in a web app vs a standard console app vs a wpf app.
Using Vessel with Liaison, "requests" are always funneled to one call within the mediator, so resolving once and using several times in the mediation works as "per request".