Showing posts with label WinForms. Show all posts
Showing posts with label WinForms. Show all posts

Thursday, August 9, 2012

WPF MVVM with WinForms Controls

This is the second part of my series on using MVVM with WPF. In the first article I discussed architecting disconnected applications and how MVVM was a great fit for WPF smart clients as well as Silverlight web clients. Now we move on to the process of refactoring an old Windows Forms application to use this new architecture.

The main concern with changing an underlying technology is the initial investment in rewriting code. To help mitigate this issue, WPF has provided a WindowsFormsHost element that allows us to host WinForms controls inside of a WPF Page. Obviously this limits how effectively we can leverage other features provided by WPF, however with a few workarounds it's a viable solution to avoid having to completely rewrite those old WinForms controls.

How easy is it to implement the WindowsFormsHost?
<WindowsFormsHost><wfh:WinFormsUserControl x:Name="LegacyUserControl" /></WindowsFormsHost>

Okay, it's only slightly more complicated than that. You will need to add add a reference to WindowsFormIntegration and possibly System.Windows.Forms (if it is not already referenced).

Now the question comes to how we interact with this control from our ViewModel since we can't use WPF bindings in our WinForms control. We can bridge this gap by adding events to our WinForms user control.


Then we wire up the events to our DataContext in our WPF Page code-behind.


While I generally prefer to avoid using the code-behind, we also don't want our ViewModel to be aware of the internal workings of our View.

The end result is our Windows Forms control interacts with elements in our WPF Page.

demonstration

Download Demo Source Code

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).