Hi everyone,
I’m taking the time to write this little post because I came across a great design pattern to handle interaction between the Business Layer (BL) and the user interface (UI).
This problem usually arises when creating multi-layers application which can be used by different kinds of users. As this blog is mainly dedicated to finance, I’ll take as an example an application which provides access to the financial time series of different assets.
When you implement this kind of programs, you might want to consume the business objects from, say, a backtesting platform to see how a strategy performs over some interval. However, you might also simply want to create a UI in WPF to see how the different assets performed using your favorite charting library.
The thing is, when you tackle user interaction, your objects need to be “interactive”. That is, you might want to rename you asset, or you might want to be willing to assign an asset to a different asset class, and you want the UI to update automatically.
Let’s take a simple example. You have a list of assets displaying the assets names. When you click on an asset in the list, the details show up in a form somewhere else on the window. If you were to modify the name of the asset, you would like the change to happen also in the list. To do so, you need to notify the list (the UI) that the (business) object has changed, otherwise, nothing will happen.
To notify changes of a property, you can implement the INotifiedPropertyChanged interface from the .Net framework.
However, there is a problem with implementing such interface within your Business Layer. Indeed, this means that your objects will handle the notifications, even when no UI is looking for it (in the backtesting platform for example). This could result in useless computations and reduce the efficiency of your computations.
This is why you would like to use the MVVM design pattern (for Model-View-ViewModel). The idea is to create enhanced versions of the objects which implement all the features required for user interaction. This object would be implemented in a different project which include the Business Layer. In our example, we would create a class called, for example, AssetViewModel which has a private property containing the business class Asset and providing access to all necessary properties with notifications upon changes.
This pattern can then be extended to represent the data available behind a complex window, as described in this article by Josh Smith. You then just set the View Model of the window as its DataContext, which allows you to bind the UI elements to it, and simply remove all the code behind.
Finally, another great advantage of MVVM is that you can test the UI workflow using simple Unit Test on your ViewModels.
For more information, you can also read the following book:
See you next time!
Leave a Reply