dialogs in services?

Aug 25, 2008 at 5:22 PM
I'm having a discussion with some guys on my team. I'm pretty sure that you don't want to put UI-related things (e.g., modal dialogs) directly in services (and controllers, as in the "C" in MVC, for that matter). It makes them hard to unit test. Am I being a bonehead, or is this actually the right idea?
Aug 25, 2008 at 6:29 PM


“A service is an object that provides functionality to other components in a loosely coupled way through an interface and is often a singleton.” (Source: Composite Application Guidance Help)

Therefore by adding “UI-related things” to a service you would be coupling it to a specific implementation of the UI which could change over time (e.g. to become a Label instead of a Dialog Box for instance). Thus not enabling you to re-use the service, which is one of its objectives. In general UI related elements are placed in views.

Please, let me know if it helps.


Damian Schenkelman


Aug 25, 2008 at 6:43 PM
Yes, thank you, that does help. As for singletons, well, I'm not convinced that they lend themselves to loose coupling (http://codebetter.com/blogs/jeremy.miller/archive/2005/08/04/130302.aspx), but that's a different topic. Thanks again for the help.
Aug 28, 2008 at 8:53 AM
@ID10T - I think you may be missing what is meant by "Singleton" with regard to a CAG service.

Jeremy is warning against depending upon a Singleton class because that couples your code to a particular concrete class and, therefore, to whatever that class delivers as its lone instance.

That is NOT what is meant by a "singleton" service in the CAG context. In CAG, the service instance is chosen and configured, typically at some early stage (e.g., bootstrapping), well before the client attempts to consume that service. When the client asks for the service (explicitly through ServiceLocation or implicitly through Dependency injection), the container delivers this externally determined service instance. Change the container configuration, and you change what the container delivers.

Thus there is no coupling of your client to any particular class as there would be if your client made a direct reference to a concrete Singleton class. 

Let's see that in code terms.

Singleton (don't do this):  "FooService fooer = FooService.Instance" 
ServiceLocation (could do this):  "IFooService fooer = container.Resolve<IFooService>()".

In the first case, you are coupled to the FooService class ... which is what Jeremy is warning against. In the latter expression, you get an implementation of IFooService ... but you don't know which one. You actually can't be sure if the service you get is the same instance everyone else is using (the "singleton") or perhaps a brand new instance made just in time for you. It all depends upon how IFooService was registered with the container.

You may well imagine that the real service is registered in production and a suitable TestDouble is registered during testing.

I hope that helps.
Aug 28, 2008 at 12:46 PM
Excellent explanation - thanks, WardB!