What is the suggested approach in 4.0 for having an Application Server in a WinForms/WPF architecture with disconnected state?

In 3.9.5 we would expose a domain object via .NET remoting.

This thread was imported from our support forum. The original discussion may contain more detailed answer.

asked Feb 18 '10 at 21:08

ara's gravatar image

ara
395838791


One Answer:

Currently you can:

  • Create "fake" Domain with in-memory database on the client (fake, because this database will be actually never modified)

  • Create server-side WCF/.NET Remoting service providing serialized DisconnectedState as response to any client request - let's call it data provider

  • Create server-side WCF/.NET Remoting service applying OperationSets sent by the client to the server-side entities - let's call it operation processor.

So:

  • When client needs some data, it queries data provider, gets a DisconnectedState and either uses it, or merges it with some existing one.

  • To send the update, client takes OperationSet of DisconnectedState and sends it to the operation processor.

Advantages:

  • Client-side entities are equipped with all the services we provide, such as local transactions, INotifyXxx, paired property sync, version & change tracking, etc.

  • The same logic works on the client. Although you can use some different logic there - see Session.IsDisconnected and Session.DisconnectedState properties.

Disadvantages:

  • Server-side serialization must be carefully tuned by filtering just allowed types - to ensure everything is secure. That's one of TODOs we have.

  • DisconnectedState itself currently isn't WCF-serializable, and probably, it won't be (but let's see). So you can send it via WCF only as blob. On the other hand, if you need POCO-like representation, there are O2O & ADO.NET Data Services, but in these cases client-side entity representation will be different (= advantage listed above is lost).

Possible future improvements:

  • A sample application demonstrating this approach in action.

  • Special "remote://" protocol for client-side Domains allowing to connect them directly to server-side Domains. Less secure (client will be able to execute arbitrary queries, etc., so technically, it can flood the server), but more convenient (no need to develop any of server-side services). Since all data modifications will be processed by the same way, we have nearly the same level of security here.

answered Feb 19 '10 at 00:20

Alex%20Yakunin's gravatar image

Alex Yakunin
29714412

Your answer
Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!
toggle preview

powered by OSQA