Why no private properties injection yet?

Nov 30, 2013 at 7:01 PM
Edited Nov 30, 2013 at 7:19 PM
I'm working with Unity for many years but even at this days it still doesn't have the ability to inject private members values, which seems lame as to me. You do have the DynamicMethodPropertySetterStrategy class and particulary the GetValidatedPropertySetter method that searches for the member's non private setter, which has a code comment that in future you may open this method for overriding to be able to return private members' setter method.

So why don`t make this method virtual instead of static to make your users life easier?
Nov 30, 2013 at 8:43 PM
Don't blame Unity for your bad design.
Nov 30, 2013 at 8:56 PM
Edited Nov 30, 2013 at 8:56 PM
@dotNETjunkie: Good try but missed. I'll decide by myself what is good and what is bad for me. I don't think that injecting private members when I don't want to make them publicly available is a bad design. Now you can auto-inject public members but for private ones you need to do that manually and I'm sure you do that as well (I mean assigning private members). That`s lame as it could be done by overriding just one method. Especially that they have a comment in code "we could consider opening this up for private property injection".
Jul 5, 2014 at 5:26 PM
I agree with @armsoft—private property injection could be useful (though not strictly required). Here's a perfect use-case for allowing private property injection: attributes. Consider this: you have an attribute, say a custom ASP.Net MVC AuthorizationFilterAttribute that requires a dependency on a service that gets information about the currently logged on user. Obviously, you can't use constructor injection on attributes. My next thought was, hey, I'll use property injection since I have a good default! However, as @armsoft mentions, the property must be public. OK, fine, no problem. Oops, there's a problem. When specifying the attribute on a controller class or action method, the public property shows up in intellisense as one of the Named Properties that are available to be set in the attribute's constructor. That to me smells. If the property is merely there as an implementation detail and for the sole use of dependency injection, why have it show up in intellisense? With private property injection, this problem wouldn't exist.

Until private property injection is supported, the next best way to accomplish the above is via method injection. Is there a significant difference between method injection and property injection in the above scenario? No. I just felt like property injection looked "cleaner". It's not a slam-dunk use case for why we must have private property injection, but I would've preferred to use it had it been available.
Jul 6, 2014 at 5:48 PM
@fourpastmidnight: Your problems exist because you are mixing data and behavior in the same class and this is causing the problems you are having. Attributes should be mere data containers as explained here by me and here by Mark Seemann.
Jul 6, 2014 at 7:38 PM
Edited Jul 6, 2014 at 7:38 PM
dot_NET_Junkie, you're trying to decide what to do and how to do for others, which is lame as to me. I will decide it by myself. If it's useful in my project I'll use it, if it help me in my project I'll use it. I would not ask you or anyone else. And tools should provide actually tools that can to do what you need, but don't force you to don't do this because someone think it's bad design.
Jul 7, 2014 at 7:59 PM
You may be right about that @dot_NET_Junkie ;) Unfortunately, I do not have the power to change this at the moment. :/ Good call, though.