Good technologies for developing a modular server component in .net?

Question

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?

Answer 1

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.

Answer 2

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.