Comments on: Property Injection in ASP.NET MVC with Ninject

By: eibrahim

eibrahim — Sat, 06 Sep 2008 19:40:28 +0000

Another valid point, but if I don't refactor the DI stuff then I will end up
with a lot of repetition in my unit tests and test fixtures. I might have
to post an example of how I am doing this, to get feedback from the
community. I might be experiencing tunnel vision, since I am the only one
writing, reviewing and refactoring the code…

By: TroyGoode

TroyGoode — Sat, 06 Sep 2008 18:57:18 +0000

I was doing it via the website. But this time I'm doing it via email.

My only concern about doing DI on your tests is that now your tests have
dependencies that you can't see while reading the test.

By: eibrahim

eibrahim — Sat, 06 Sep 2008 18:48:09 +0000

I don't have to use DI in my tests but I do because it is easier… I have
one method that just sets up my DI and all it is really doing is mocking all
the interfaces…
I don't know how deep the threads go… But we can find out :)… Are you
posting your comments on the site or are you just replying to the emails?

By: TroyGoode

TroyGoode — Sat, 06 Sep 2008 18:42:54 +0000

Hmmm, I'm not sure why you would _have_ to use DI in your tests rather than creating your controllers and manually injecting your dependencies (which will likely be mocks or stubs).

Btw, how deep can these threads go? =)

By: eibrahim

eibrahim — Sat, 06 Sep 2008 18:34:08 +0000

I see your point… I am actually using DI in my tests, which I would have
to do anyway to inject constructor arguments. Actually my DI code in my
test project didn't change when I moved from constructor to property to
kernel.get…
At points, I feel like kernel.get is a good solution and at other points I
feel it's not. I can't explain it :)…

By: TroyGoode

TroyGoode — Sat, 06 Sep 2008 16:35:16 +0000

Regarding my opposition to Kernel.Get:

From the testing angle I'd rather be able to pass my dependencies in via the constructor (or set via a property) than have to mock an instance of IKernel up.

Think about how you're going to write tests for the controllers that use that property. With the code listed above you would have to either (a) mock the Kernel or (b) actually wire up DI for your tests.

By: eibrahim

eibrahim — Sat, 06 Sep 2008 12:40:28 +0000

By: TroyGoode

TroyGoode — Sat, 06 Sep 2008 11:57:18 +0000

I was doing it via the website. But this time I'm doing it via email.

My only concern about doing DI on your tests is that now your tests have
dependencies that you can't see while reading the test.

By: eibrahim

eibrahim — Sat, 06 Sep 2008 11:48:09 +0000

By: TroyGoode

TroyGoode — Sat, 06 Sep 2008 11:42:54 +0000

Hmmm, I'm not sure why you would _have_ to use DI in your tests rather than creating your controllers and manually injecting your dependencies (which will likely be mocks or stubs).

Btw, how deep can these threads go? =)

By: eibrahim

eibrahim — Sat, 06 Sep 2008 11:34:08 +0000

By: TroyGoode

TroyGoode — Sat, 06 Sep 2008 09:35:16 +0000

By: Duncan Smart

Duncan Smart — Mon, 01 Sep 2008 17:42:42 +0000

Is there not a Generic version of Kernel.Get? e.g.
var Provider = Kernel.Get();

By: eibrahim

eibrahim — Mon, 01 Sep 2008 17:22:33 +0000

The SecuredController solution wouldn't work for me. Almost every controller needs to call the property CurrentUser which means every controller will inherit from SecuredController which defeats the point.

Why are you opposed to Kernel.Get? It seems like I can easily achieve the goal I want without having to force every derived controller from calling the base controller consturctor with interfaces...

I am trying to get away from doing this

class DerviedClass : BaseClass

public DerivedClass(IService1, IService2) : base(IBaseService1, IBaseService2)

By using Kernel.Get in the base class then I eliminate the use of base(IBaseService1, IBaseService2) in the derived classes constructor... I hope that makes sense.

By: TroyGoode

TroyGoode — Fri, 29 Aug 2008 22:41:50 +0000

For me the Kernel.Get's should be used as infrequently as possible. You say that you have a BaseController class, but only certain controllers will make use of the MembershipProvider property. Why not create a “SecuredController” that inherits from BaseController and adds the property? This way you're back to doing the injection at the IoC level and only doing it for the controllers that need it.