Dependency Injection is Dead! is the somewhat provocative title of an interesting post of Simon Ince.
Simon indeed proposes another approach: AOP-powered Dependency Resolution. The idea is to use aspects on fields or properties to resolve the dependencies on-demand, when the property or field value is retrieved. Technically, it would be enough to turn the old good [Dependency] custom attribute into an aspect.
I won't copy-paste Simon's stuff, so please read from the horse's feather on his blog.
A refreshing view on a topic that tends to become sanctified and therefore unchallenged in our community.
Even if this approach does not solve all the use cases of Dependency Injection, covers a lot of them in quite an elegant way. While it would be theoretically easy to use this approach with dependency injection frameworks (because dependency resolution is obviously one the major components of a DI framework, the other big one being the object builder), I noticed that Unity does not offer the functionality at the required level of granularity. A pity, which I have notified in illo tempore to the Unity team. Maybe some day wind will turn...
Happy PostSharping!
-Gael
6 Comments:
Pleased you liked it!
I'd be interested if you think there are better ways of doing this - as you're *the* PostSharp expert... :-)
Yes I liked it.
Actually I posted a comment on your blog, but apparently it somewhat got lost.
You could use an "instance tag" to cache the dependency. You could also use the OnFieldAccessAspect to do the same on fields.
A CompositionAspect may help associating an instance to a context at instantiation time, so that a same instance is always resolved according to the same context (see PostSharp4Spring).
And finally... it would be nice to integrate it to some IoC framework like Unity. Unfortunately this framework does not provide the required level of granularity, at least at sufficient level of ease.
All these frameworks are far too complex for what you/we want to do: easy things done easily.
It's also me who posted your post on dotnetkicks and on alt.net -- a heated discussion :)
Gael and Simon,
I liked the approach took. I think it's not only better, but sometimes simply needed. I've tought to do the same thing, but found kinda complicated to use PostSharp to optimize OB/CAB, specially because PS isn't working on CF. We are working on the Mobile Client Software Factory, which uses a version of CAB that targets the Compact Framework.
Obviosly the main benefit would be to move costly reflection time from runtime to compile time :) A great plus for our users.
Gael and Simon,
I liked the approach took. I think it's not only better, but sometimes simply needed. I've tought to do the same thing, but found kinda complicated to use PostSharp to optimize OB/CAB, specially because PS isn't working on CF. We are working on the Mobile Client Software Factory, which uses a version of CAB that targets the Compact Framework.
Obviosly the main benefit would be to move costly reflection time from runtime to compile time :) A great plus for our users.
I am working on CF and SL support.
@ Gael,
that's bad news - checked my comments list and there's nothing from you, so it must have gotten lost. I certainly didn't avoid publishing it :-)
Good stuff though - thanks for the thoughts. And I hadn't seen the alt.net conversation - makes for an interesting read, it's good to get people's views on this kind of thing.
Simon
Post a Comment
Links to this post:
Create a Link