Comments on: Too Much of a Good Thing? Constructor Injection Overload http://christopherdeweese.com/blog2/post/too-much-of-a-good-thing-constructor-injection-overload IArchitect, IBlog, ILeader Fri, 02 Jul 2010 14:23:42 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Chris http://christopherdeweese.com/blog2/post/too-much-of-a-good-thing-constructor-injection-overload/comment-page-1#comment-115 Chris Thu, 21 Jan 2010 15:46:40 +0000 http://christopherdeweese.com/blog2/post/too-much-of-a-good-thing-constructor-injection-overload#comment-115 Surely they can and that is something I should dig into because I'm pretty big on letting containers do the work. I guess the counter to that is you probably shouldn't rely on that behavior 100% of the time because what if it changes. One thing that Uncle Bob pointed out in his article, is to keep those details out of your app. It is pretty rare that I make container calls directly from my classes and if I do it is through some type of factory abstraction. The testing inconvenience can be painful, but using something like Moq you can setup just the pieces you need for the test to run. Good comments, now I'm thinking I should update the post. Surely they can and that is something I should dig into because I’m pretty big on letting containers do the work. I guess the counter to that is you probably shouldn’t rely on that behavior 100% of the time because what if it changes.

One thing that Uncle Bob pointed out in his article, is to keep those details out of your app. It is pretty rare that I make container calls directly from my classes and if I do it is through some type of factory abstraction.

The testing inconvenience can be painful, but using something like Moq you can setup just the pieces you need for the test to run.

Good comments, now I’m thinking I should update the post.

]]> By: Mark http://christopherdeweese.com/blog2/post/too-much-of-a-good-thing-constructor-injection-overload/comment-page-1#comment-114 Mark Thu, 21 Jan 2010 15:34:39 +0000 http://christopherdeweese.com/blog2/post/too-much-of-a-good-thing-constructor-injection-overload#comment-114 Shouldn't your IoC container be able to create a proxy for you to do lazy instantiation, even if it is a constructor injected dependency? It's an inconvenience, especially when testing, to pass so many dependencies in, but if you're worried about all that instantiation affecting performance, would you be better off dealing with it via the container?...maybe even via config of the container where you could tell it these dependencies of the class are always needed and these others are lazy. Shouldn’t your IoC container be able to create a proxy for you to do lazy instantiation, even if it is a constructor injected dependency?

It’s an inconvenience, especially when testing, to pass so many dependencies in, but if you’re worried about all that instantiation affecting performance, would you be better off dealing with it via the container?…maybe even via config of the container where you could tell it these dependencies of the class are always needed and these others are lazy.

]]> By: Chris http://christopherdeweese.com/blog2/post/too-much-of-a-good-thing-constructor-injection-overload/comment-page-1#comment-112 Chris Thu, 21 Jan 2010 14:18:15 +0000 http://christopherdeweese.com/blog2/post/too-much-of-a-good-thing-constructor-injection-overload#comment-112 You bring up another good point that has been on my mind too -- how many dependencies is too many? Because some class has to be responsible for the overall composition: who calls who to do what. IoC helps remove some of the worries about how you resolve and load those dependencies but it does not solve the problem of how you structure the app overall. Even if you refactor to smaller classes (which I totally am in favor of) someone still has to know to compose all those smaller classes to get work done. So perhaps you use smaller classes with fewer constructor dependencies then you have a few "dirty" classes that know who to call? From a guy who works with the VS team I thought you'd have this all figured out? :) You bring up another good point that has been on my mind too — how many dependencies is too many? Because some class has to be responsible for the overall composition: who calls who to do what. IoC helps remove some of the worries about how you resolve and load those dependencies but it does not solve the problem of how you structure the app overall.

Even if you refactor to smaller classes (which I totally am in favor of) someone still has to know to compose all those smaller classes to get work done. So perhaps you use smaller classes with fewer constructor dependencies then you have a few “dirty” classes that know who to call?

From a guy who works with the VS team I thought you’d have this all figured out? :)

]]> By: Jason Barile http://christopherdeweese.com/blog2/post/too-much-of-a-good-thing-constructor-injection-overload/comment-page-1#comment-111 Jason Barile Thu, 21 Jan 2010 14:13:35 +0000 http://christopherdeweese.com/blog2/post/too-much-of-a-good-thing-constructor-injection-overload#comment-111 Perhaps it's just my limted personal experience with IoC, but I'm not convinced (yet) that making my classes more complex by adding calls to factories that abstract away calls to service locators (or worse, making my classes depend directly on the IoC containers themselves) is all that much better than a few extra parameters being passed into a constructor. Perhaps another valid approach would be to consider why the class has so many different contexts that not all of the dependencies are used in every case and refactor it down to multiple classes. In the end, I'm sure there are cases where both approached make sense - thanks for pointing out the design consideration! Perhaps it’s just my limted personal experience with IoC, but I’m not convinced (yet) that making my classes more complex by adding calls to factories that abstract away calls to service locators (or worse, making my classes depend directly on the IoC containers themselves) is all that much better than a few extra parameters being passed into a constructor. Perhaps another valid approach would be to consider why the class has so many different contexts that not all of the dependencies are used in every case and refactor it down to multiple classes. In the end, I’m sure there are cases where both approached make sense – thanks for pointing out the design consideration!

]]>