Tuesday, July 24, 2012

Disconnected WPF Applications

I was recently tasked with presenting a plan to turn an existing WinForms program into an enterprise level application. They wanted to stick with a Windows client, but since each form would already need significant rework to extract the business logic, I suggested moving to WPF using the Model-View-ViewModel (MVVM) presentation pattern.

MVVM is basically a type of Model-View-Presenter (MVP) pattern that makes use of declarative bindings. State and logic are stored in the Presenter (ViewModel) which presents an abstract view of the UI with no knowledge of what View will implement it.

With the Presentation Layer taken care of, it was time to address the heart of the Application. The immediate need was for a smart client, however the solution was still very young and continually changing so it seemed a Service Oriented Architecture (SOA) would provide the most flexability and reuse. The question was how a disconnected client would use services.

Microsoft used to offer an application block for this specific purpose. The Disconnected Service Agent Application Block helped maintain a queue of web service requests while working disconnected (offline), then submit them to the server when it became available. Unfortunately, it is no longer being maintained and I have not found a suggested replacement. My guess is that they would encourage use of Sync Framework, which is designed to synchronize databases and files, but can use custom providers as well.

We're using Sync Framework to replicate data down to the client for offline use, but to utilize SOA and keep business logic/validation on the server we need a way of queuing web service calls and resolving any conflicts that occur. I'm currently in the process of researching whether a Sync Framework custom provider would be a good fit or if the old disconnected service agent application block would be a good starting point.

The existing relies very heavily on SQL stored procedures. Fortunately, Entity Framework (EF4) supports calling the existing stored procedures so they wont all have to be rewritten immediately. The plan is to gradually move business logic up into the application layer and use entity model. I've also added a generic repository to allow mocking.

I welcome feedback and suggestions. If you've tinkered with custom providers for Sync Framework or have suggestions for how to best queue and resolve service calls I'd love to hear from you, either by leaving a comment below or on twitter (@gainesk).


  1. Nice article. I'm not sure if I would choose Entity Framework if it were me but that's just personal preference. There are cases in which I have used Entity Framework and I found a very nice T4 template that will read your EF model and generate UnitOfWork and repository classes/interfaces based on your model. Please let me know if you are interested and I'll see if I can't dig up the source. Very nice diagram as well.

    Buddy James


With so many attempts to post spam in comments, I'm forced to approve each one before it is visible. Please be patient as I may not get to it right away.

Note: Only a member of this blog may post a comment.