Distributed WPF Application: Part 1

So, in the spirit of a distributed WPF application, let’s focus on the User (shocking).  The capital U in user is intentional. They are the all knowing (well, they know what they want to do…), the all powerful (well, they are paying the bills…) and the all something else (I needed a third) driver of the application.

For WPF, the possibilities are to have a desktop style application, an XBAP portal, or use Silverlight. For this series, I’ll be examining using an XBAP. Although not my favorite of choices, it does provide the User a sense of comfort in seeing the application running within the Browser (IE). Of course, this comfort is an illusion and in fact is very, very different from the web paradigm the User may be so comfortable in experiencing. Hopefully more on that later…

A key difference, in my opinion, between XBAP and web application is the deployment. The XBAP deployment through ClickOnce is more aligned with desktop applications than with web applications. This fact alone will affect so many architectural and technological decisions alone that it should not be taken lightly.

If the preceding warning still has you wanting to pursue having a XBAP application that takes full advantages of the benefits of WPF while running a thin presentation that consumes services on application server(s), hopefully this series will benefit you. If not, hopefully this series will provide some insight into your architecture.

In terms of implementation of the UI, follow the current best practices – enlightening ain’t I…
At the time of writing, this is MVP, MVVM, or some hybrid that allows for reality.  I’ll refer to the Josh Smith in his article here.

It terms of the model that is used, I would suggest starting with an object that fully meets all requirements of the UI. If the UI needs a combobox, add a Dictionary<int,string> to it so that the UI can bind to it. Use the object the UI binds to, the ViewModel, as a report – but with some extra metadata that will aide you.  For example, a User doesn’t care about a Dictionary<int,string>, They care about the string – however, the int will go a long way later on in resolving that string.

All the data necessary to show information to the User, in the clearest way possible, should be available in that ViewModel. In that vein, make sure that the data you are showing to the User is necessary for that screen. Try to focus on the User’s task at hand. A generic editable list of items (aka Excel) may be what the User is used to, but really try to extract what they are trying to use those row edits for.

Unfortunately, this least technical aspect will likely affect the overall implementation of the architecture – and the importance of structuring your screens to match this can not be undervalued.


No comments yet

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: