After I covered some basics about WCF Services and setup a server, we need to connect a client. In this post I want explain a little more the overall design philosophy. Than in followup posts we come closer to coding and bring it all up.
First, lets talk about some basic design stuff. There are many choices and crossroads when it comes to front end design. The first and most important choice is about “what is my target platform?”. Its so important because there is almost no way back without a complete redesign if you decide changing from Web platform to Desktop later. The other way around would be not that critical due to the fact there will be converters available to transform your desktop UI to e.g. HTML5. But this may be a separate topic for additional “Technology Screening” post later…
My platform of choice is .Net and WPF because of performance and support. Also I like the fact to have everything in one programming language (yes I know , XAML is different to C# …) and the IDE I used to. So fasten your seat belts and prepare your stomach for a couple of posts about WPF client UI creation with strong focus on MVVM pattern.
MVVM is programming model that helps a lot keeping the code extensible and easy to maintain. It generates some additional effort in programming once, but on a long run it saves time. This is true for larger Apps with complex Views and many sub-Views and controls. Each View get its own View-Model where all the data are provided to become displayed by the View. The main benefit is to have a strict separation of data processing and data visualization. The View is just a stupid mask for visualization and devotedly displays any data it get from View-Model. If you want to change you View cause you like it better to have it another way, or need to change the UI cause of user request, you need to touch only the code from View. Or other way around – for instance, if you need to change some calculation of data processing because user want to have metric system, you only need to change the View-Model and all UI-Elements which display data from this View-Model are fine.
So lets start with some basics when you create a WPF application. The first thing is – there is no obvious entry point like “static void Main()”. You can create a WPF project in Visual Studio and you will find something like this:
As you can see there is no Program.cs file for the entry point. Instead of this Visual Studio creates two Classes MainWindow and App in our project. This Classes are part of their “xaml” container. But as you know the CLR is looking straight to a static void Main() method for entry – and you find under App.xaml.cs.
Please notice that the Main() method becomes created automatically in a separate file located in \obj\Debug\App.g.i.cs and its not implemented in App.xaml.cs. Also the InitializeComponent() method is implemented in this separate file , which becomes created automatically with the solution.
OK, now its clear that its about the MainWindow container and we know about its starts up process. Now lets add a class library for all the ViewModels we will add. During the client post series I will add some more class libraries for interfaces and command dispatching. But lets do it step by step to keep the overview and make it easy to follow the process flow.
As baseline lets create some basic entities in addition to the ClientApp project and the above mentioned class lib ViewModels. Its not surprising that we find another class library named “Views” in the Solution. By this, the MVVM pattern is represented in general. But in practice we need to have some more entities like common classes and a kind of broker library I named VMDispacher. Together with some modifications or better say additional implementations in App.xaml, we can start to create a simple client application using the MVVM pattern.
This sketch of basic client solution needs some additional flavor. Unfortunately WPF has not much convenient templates and reference implementations on board. It gives developers a very powerful programming model and collection of primitives, but each dev need to extend it on his own guess. This opens the door to smart guys who develop 3rd party libraries on top of the basic Microsoft stuff.
I use several 3rd party libraries too, but try to reduce the number not to bloat the solution. If you take look over Nuget package manager, it like a candy shop. In general its is worth to take a little pain and solve a issue or two by your own custom implementation instead downloading a powerful package, create many dependencies just to solve one isolated problem.
Here comes a list with 3rd party lib’s I use for my client application:
Another library I use is from Microsoft, so I would not count it under 3rd party library – but decide by your self…
In the next post of this series I will cover the basic mechanics of the View <=> ViewModel interaction. I will do it by continue the implementation of our example Solution. Some additional class libraries become added as well as functionality will grow. The target of this series of posts is to have a client app to connect to the server app covered in previous topic. Both I will extend in upcoming post-series to add further functionality to closer to chapter 1 goal creating a tool-chain for collecting financial data and basic manual trading.
If you have suggestions or comments, feel free to let me know. To get a preview about upcoming topics or what was posted in past, please have a look here: Content++.