Archive for the ‘cqs’ Tag

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.

Advertisements

Distributed WPF Application

I’ve been going over some ideas (not my own ideas of course) that have been focused around distributed loose-coupled message driven systems, WPF XBAP portals, enterprise architecture, and domain driven design. I’m hoping to post the outline of the ideas as a means to aggregate the ideas in one place, which will hopefully help my and others understanding.

My additional requirements of to be aware of the common symptoms found in system design. From Principles, Patterns, and Practices [Martin],
The symptoms are:

  • Rigidity: The design is difficult to change.
  • Fragility: The design is easy to break.
  • Immobility: The design is difficult to reuse.
  • Viscosity: It is difficult to do the right thing.
  • Needless complexity: Overdesign.
  • Needless repetition: Mouse abuse. [copy/paste programming]
  • Opacity: Disorganized expression.

In addition, I was looking to follow the SOLID principles of programming.
As detailed in Principles, Patterns, and Practices [Martin],

  • Single-Responsibility Principle (SRP): A class should have only one reason to change.
  • Open/Closed Principle (OCP): Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.
  • Liskov Substitution Principle: Subtypes must be substitutable for their base types.
  • Interface Segregation Principle: Clients should not be forced to depend on methods they do not use.
  • Dependency-Inversion (DI) Principle: High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.

See Unlce Bob’s Principles of Object Oriented Programming Article for more detail (or his PPP book).