I am using WPF, Prism and Unity to develop the user interface for a .net application. The UI will run from a PC, but I also need to develop a separate complex server component that will provide services to the PC component via WCF.

Prism and Unity have proved to be of great value in creating a modular application, at least as far as the user interface is concerned. I would also like to make the server component modular, but I cannot find anywhere what techniques, patterns and technologies are suitable. I have considered:

  • Unity or one of the other DI containers
  • Selected parts of Prism, such as modules and events

Are these suitable for developing a modular server component? Or are these UI technologies only and should I be looking at something completely different?

  • 1
    Your question isn't clear. Is the "separate, complex server component" a UI or is it another set of (WCF) services?
    – user53019
    Oct 8, 2012 at 14:23
  • No, not a UI. Definitely more a set of WCF services, which would store user's configuration data in a database and communcate with another external system on a server (that part not by WCF).
    – nubbers
    Oct 8, 2012 at 17:16

2 Answers 2


There are a couple of good guidelines to follow to ensure modularity of your server side components, one good rule of thumb to keep in mind as you're designing the assemblies and their responsibility boundaries can be to make it easy to fulfill the client side requests in-proc on the client side. This will help you design the server side component so that it will be capable of completing it's tasks in multiple scenarios more cleanly.

I would suggest reading through this: http://apparch.codeplex.com/releases/view/19801

That said, here's my general suggestions:

  • DI, yes. However you do it, use it to abstract the layers of the service.
  • Design and implement the crux of what you want your server side piece to be, in a class library with no references to service pieces
  • Recognize the fact that it's a "service" is merely an effect of it's hosting process, and should not be an inbuilt piece of the business logic itself.
  • At the very least, the horizontal segmentation should create a boundary between service hosting, and logic components, likely for modularity you'll want more horizontal boundaries than this one.
  • Make everything below your hosting layer, completely ignorant of other services as much as possible. You want external dependencies to hang off your graph as near to the top of the stack as possible.
  • I notice that the Service Architecture Guide that you link to bears the same 'Microsoft patterns & practices' stamp as the Prism guide for WPF. I was completely unaware of its existence before now, but it is definitely the right resource for me to continue with.
    – nubbers
    Oct 8, 2012 at 22:43

WCF services and MVVM are more than sufficient to provide the functionality you describe in loosely coupled, modular, and scalable fashion.

I suspect your confusion may be coming from viewing the Model and the WCF services as only a means to retrieve data. A service can be much more than just another layer in the data feed stack though. Services can be used to trigger ad-hoc actions, calculations, or just about whatever else your application may need. For that matter, Models and Services can both be composed of calls to one or more other services.

At an abstract level, a service is merely an invokable function that fulfills a contract. It doesn't care if the contract actions are data or server oriented.

Your models may not have much to them if all that is required is invoking a particular service without exchanging any data beyond authentication tokens, if even that. That's perfectly okay in some scenarios, depending upon what the service is doing.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.