.NET, C#, WPF
Four years ago I wrote one of my first WPF applications. It was named 'BackUp' and enabled you to keep directories in sync (similiar to Microsoft's SyncToy).
Actually I learned a lot of the WPF stack by creating this application, but since I did use code behind instead of the MVVM pattern, it was a good occasion for refactoring the code and applying a new UI.
In this post I will present the new Metro UI and describe my experience in using event-based components for the synchronization workflow.
As a fan of minimalist UIs, I really like the Metro design. The twitter client MetroTwit has brought me to the idea to create a Metro inspired UI for BackUp.
This was the old UI:
And this is the new UI of MetroBackUp:
Creating the Metro UI required some XAML styles. An other possibility would have been to use Metro Toolkit or MahApps.Metro.
Flow Design (Event-Based Components)
After looking at the visual part it's time to explore the synchronization workflow.
Since synchronization consists of several consecutive steps, I decided to use Event-Based Components (short: EBC) for the implementation of the workflow. In Flow-Design notation the process has the following high-level components:
EBC + WPF
EBCs are a programming paradigm spreaded by Ralf Westphal. The basics of EBC are explained on the project page of Event-Based Components Binder.
EBCs are not aware of a WPF UI, so we need an approach to trigger an EBC workflow from a WPF view. This can be done by using an ICommand implementation that throws an event when it gets executed. This event can be used to trigger the workflow. The ICommand can be bound within the view; e.g. to a button.
EBCs worked very well in my usecase. My viewmodels only contain some ICommands that trigger EBC actions. The synchronization code is spitted into some high cohesive EBCs, which can be understood easily.
EBCs were only used for the synchronization workflow, other actions are just implemented in the viewmodel (e.g. adding a new synchronization task). I chose this pragmatic approach, since the effort would have been disproportionate to the benefits.
Perhaps there will be a chance to use EBCs in a larger project. Would be interesting to see, how they work in long term scenarios.
- High cohesive classes with one functionality can be easily archived
- Components are composable, testable and exchangeable
- Interception can be applied without changing components
- Without a design sketch it's hard to understand workflows within an application, since you can't simply navigate from component to component
- Binding components together can be complex
The installer and source code is available for download and can also be found on Codeplex.