WCF behaviour configuration as .NET Remoting

Question

The Goal

Run a local server (WCF) containing business logic that tracks information while the computer is powered on (ran when a user logs in as an ordinary process). The local client (WPF) containing presentation logic can connect to the readily-available local server to present the tracked information to the end-user. Everything is local and non critical, security is not an issue.

The Implementation

Initially I wrote a local server based on the Remoting technology, which is considered to be legacy technology, and connected the local client to the local server. Each shared object was shared remotely and could be called upon.

The Problem

It was not possible to remote serialized Lambda expressions (refractor-enabled property name binding) and events. I am aware events can be bound using a remote-enabled object and invoking that on the server, however, this breaks WPF data binding. Event-driven programming is important.

What do I seek?

An example to create the architecture I mentioned, or, a base sample that shows how to configure WCF to behave in a similar manner as Remoting does. Every online resource I could find, including MSDN articles, are written for .NET 2.0. A lot has changed in WCF-world since .NET 2.0, and using .NET 4.0 is a requirement. Even links to samples, tutorials or articles for Remoting-like behaviour for WCF in .NET 4.0 is appreciated!

Answer 1

WCF is an excellent technology, howevery as others have commented, it sounds like you are trying to violate core principals of WCF. I might be wrong here but it sounds like you want to send your viewmodels across the remoting boundary?

The reason why it is wrong to send viewmodels across the remoting boundary in my opinion is an architectual reason. The reason being that I might have mutliple client apps, ie a web site and a wpf desktop app. That viewmodel is only relevant to the WPF app. It is largely platform specific (in most cases). Since viewmodels are platform specific they belong to the platform and not in your services.

Your DTO entities (ie service model classes) must be separate to your viewmodels, as your views requirements could change on any one client app, and your services might want to largely provide the same services as they were before. It is fine for your client apps to have dependency on your model entities. I usually put them in a common project that is common to my service project and my client app projects.

This about it this way. A good design should allow anyone to potentially consume it and do what they want with it. A web service such as flikr,facebook or amazon doesn't tell you how or suggest what information you should display on your application, and neither should yours. (Im not advocating to blindly follow their design, but it is a community example you can have a look at).

Your viewmodels should defaultly be using bindable datatypes by implementing the INotifyPropertyChanged interface etc, so updating the data on a viewmodel should be a very easy thing to do. The best thing to do when design an app is to think, if i did something which is not in my feature list how would I do it. Am I making it harder to say, expose my service to the public (even thought that is not my intent to do so). That will keep your design robust, and in good shape for when clients change their mind in what they want.