views:

631

answers:

1

Here is the scenario:

  • I have a visual that displays some data
  • The data to the visual can come in one of two ways
    1. Via user input through the keyboard or mouse
    2. Via some backend source
  • Both these data inputs can be of one of two forms
    1. Control data or
    2. Raw data for simple display
  • Control data causes changes in the visual
  • Raw data is simply showed as is

In other words, the view is being served by two masters, viz user input and backend input. An example would be a multi-user game that has visuals controlled by user input but may also have the same visuals controlled by some backend input (say tcp/ip). Another example would be a terminal emulator that gets user inputs but also gets data from another source be it telnet or serial, etc.

I was thinking of writing a WPF custom control for the visual. In other words, it is a black box that will interpret the inputs and display the results. Getting user input into this custom control is easy since one can listen for the appropriate events and handle them as needed. However, how can one listen for the inputs from the backend? Exposing a dependency property that one binds to does not make sense but exposing a method on the visual that is called with the data also does not make sense.

Another choice is the MVVM architecture where the Model is the backend data source and the View Model does all the work. It gets both the backend data (via the model) and the user inputs (via appropriate command bindings or some such) and it makes appropriate sense of these and binds to the View to display these changes.

The advantage of the custom control is that it can be consumed as a control that takes care of itself so that the consumer has to do very little work to use it but the problem is getting data to it from the backend. The MVVM method is advantageous because it encapsulates the handling logic, view, etc neatly. The problem is that this pattern has to be repeated for every backend. Thus, making the visual very bare bones and exposing all the processing logic outside the control. Basically I want to make it very easy to consume so that someone can take it and use it without adding too much external logic to do processing etc. All they provide is their backend data source that feeds into the visual.

Sorry for this being a lengthy post but I am learning WPF and this is an interesting design question for me. All ideas, comments, etc welcome.

Thanks for reading.

+1  A: 

I would definitely use the MVVM pattern. You get a very nice separation of concerns in your code, and your viewmodel can also be tested outside of the user interface. You may also be able to edit you view in Blend. I don't think that hooking up the viewmodel to the backend is more complicated than hooking up a custom control. You may decide to use dependency injection or a service locator to connect things. By using all these design patterns you get a more decoupled and testable solution.

Martin Liversage
Martin,Thanks for your suggestions. I can certainly see the MVVM pattern being a good fit here but what I am having problems wrapping my head around is that I want to make this thing easily consumable and(with my limited understanding) I feel that adding MVVM into the equation breaks the blackbox nature of the design forcing whoever uses it to also follow the pattern and provide the appropriate hooks (read model) that plugs into the architecture. Perhaps I am missing some general design knowledge that will fix this issue.I will look into the design patterns you have suggested.Thanks.
HiteshP