At the DevPartner conference in Chicago (http://conference.synergex.com) we announced an open source project called Symphony Framework. The Symphony Framework project is a Synergy .NET based set of libraries that assist with the migration of traditional Synergy cell based and UI Toolkit applications to a native .NET Windows Presentation Foundation (WPF) desktop application. The concept of the Symphony Framework is to simplify the Model-View-View Model (MVVM) design pattern and make it easy to migrate your traditional Synergy code.
An important aspect of any program is responding to user requests. In a UI Toolkit program this is typically based on menu entries – even ones that don’t exist and are signalled in code using M_SIGNAL(). A WPF desktop application is no exception and commanding is an important aspect of the program. In the MVVM model you utilise an interface called ICommand. This interface provides for three very important elements. Firstly, a hook, or entry point to be executed when the command is processed. Processing a command can be assigned to the click of a button on the UI, it could be the navigation event around a list, or even a line of code in your program. Secondly the ICommand model enables a status enquiry point –where the bound UI control can interrogate the command object and determine if it is enabled for execution. Generally a UI control bound to a command object will render itself differently depending on the executable state of the command. For example a button will appear greyed out and not clickable. And thirdly is the ability to notify the UI control that the executable status of the command has changed, which causes the interrogation of the command object to determine is executable state.
The Symphony Framework exposes a number of command types, the easiest to use is the GenericCommand, which can be found in the Symphony.Conductor.Commands namespace. This class utilises the ICommand interface and makes coding commands very simple. You can create individual command objects or one generic command. Here is an example of defining a generic command within your View Model class that can be bound to any number of UI control.
Firstly, reference the correct namespace:
Now create a private class member:
Now expose a public property which we can bind out UI control to:
Note in this code that if the private mCommand class field is null we create an instance of the GenericCommand class and assign it. We also define the logic to execute when the command is processed. Now we can write the event handler:
Notice the routine signature. The “parameter” string argument will be set to the value you assign to the bound command in the UI. As an example, here we are defining three buttons which all data bind to the Command property:
By using the CommandParameter attribute we can assign the required “operation” to each bound command. Now we can extend the logic in our event handler routine:
This example shows you how to easily utilise the GenericCommand class within the Symphony Framework.
There are many more examples that you can review from the Examples Explorer which is available when you install the full Symphony Framework. If you are interested in looking at the Symphony Framework code and becoming part of the development community search www.codeplex.com for “Symphony Framework”.
During the past few years, the process of designing an application has gone through another revolution of terms. When I started out in computing, data was in records and you wrote programs that have subroutines to perform repetitive tasks. Then there was the short-lived foray into 4GL’s, More recently with the introduction of OO-based languages, we had to learn about data in structures, instance objects, methods, enumerations and a whole host of new terms. At the same time, we got into client/server and N-tier application design. Mostly, these were just variations on what we were already familiar with, although making the most out of the new terminology can require a new way of thinking. In the past few years, the way you design applications has sort of been through another evolution. I say “sort of” because what’s happened is that some new terms have entered common usage. One of which is design patterns. Design patterns are just what they say, a pattern that you use when designing an application. They define/redefine some of the practices that we have been following for years. Two design patterns I want to highlight are MVC and MVVM.
MVC is Model-View-Control. This is where the Model (business logic & data) is separated from the View (what you see) and the Controller (dispatch logic). The Controller monitors both the Model and View components, and acts as the communicator between these two components. When you are using a well- designed UI Toolkit application, you’re probably using a MVC design. If you have your real business logic abstracted away from the UI Logic (which UI Toolkit doesn’t really help you implement), you have the Controller logic separated from your View, which is part of the MVC pattern. At a very simplistic level, the Synergy UI Toolkit List processor is the controller part of a MVC pattern, the load method is the Model and the list window is the View. The UI Toolkit code is partially agnostic to the actual data being processed – you just pass it the data as a parameter and the forms processing inside UI Toolkit takes care of the rendering of the data on screen. In a recent project, I created wrappers for the Synergy UI Toolkit logic in order to implement a formal MVC design, such that almost all of the logic required to drive the UI was abstracted into standard routines. So as far as the application developer was concerned, all they had to provide were the window scripts that defined the View, and the various business logic routines that were registered with the Controller.
MVVM is Model-View-ViewModel. This is a variation of the MVC, where the controller is replaced by the ViewModel. The ViewModel component instantiates instances of the Model component and it exposes public properties that the View component consumes. In a MVVM design, the Model is oblivious to the ViewModel and the View, and the ViewModel is oblivious to the View. MVVM seems to be the design pattern of choice for WPF applications, and was used by Microsoft when they developed Expression Blend. Because the View is separate to the ViewModel and Model components, it’s really easy to apply a new skin to an application that is implemented with this design. Synergy applications have been moving in this direction since the release of xfNetLink/xfServerPlus, so it’s a natural evolution to consider this design practice when updating the UI of an application.
In addition to the two I mentioned there are other variations in application design patterns (e.g. MVP). In the course of reading up on the various application design models, I came across a reference to a blog by Josh Smith on The Code Project, where he states “If you put ten software architects into a room and have them discuss what the Model-View-Controller pattern is, you will end up with twelve different opinions.” In a lot of cases, you’ll have an in-house design pattern that you’ve been using for years, but as you continue to develop your Synergy application, you should consider reassessing all the available design patterns to determine which pattern is the most appropriate for future-proofing your application.