Take the 2-minute tour ×

This is somewhat specific scenario, but I'm having trouble around this. In my current project this is the first time I'm applying everything I consider good practices; so there is MVC/MVP for UI, DDD Onion Architecture at core, IoC, everything is currently unit / integration tested. But consider following: when Exception bubbles in my controller, I want to show that to the user in a special made form so to unit test this one way would be of course to have my controller take another view dependency via constructor (cumbersome for every controller) so I have a global screen repository where I can call:


Problem is, you can't really mock singletons, but here I would say they are clean design in a way. What I am missing is a architectural concept of how would you organize your code to solve this problem. I can again rephrase the question to make it clear: how to unit test this, and by unit testing how to adjust architecture for that? (I strongly believe that unit testing adjusts my architecture to a much better design, so please no comments like don't let tests rule your code or something...

What my IoC does now: wiring of controller & views, repositories and such, so I could say that I have a central place for calling IoC.Resolve<ISomeController>().

Edit: I don't use mocking frameworks that could expect a call on not-virtual not-interface methods...

share|improve this question

1 Answer 1

up vote 1 down vote accepted

In your specific case where you want to inject the dependancy to all controllers I would have a BaseController which will have a property of type IScreenRepository

public class BaseController
  private IScreenRepository _screen = NullScreenRepository.Instance;
  public IScreenRepository Screen {get { return _screen; } set { _screen = value; } } 


You can set you IOC to inject the property dependency for all your controllers. It's also good to have a NullScreenRepository to make sure if you dependency is not injected it won't break code that instantiates controller directly and not from the IOC container (like unit tests).

This way you will be able to use it in all controllers without worrying where it came from. And you can mock it and fully test your controllers.

share|improve this answer
I'll accept this for the sake of the idea, although I still haven't decided yet on this ... Thx –  Denis Biondic Jun 20 '11 at 12:44

Your Answer


