M-V-VM Building an ERP-system – part 7 of N – Views
Okay – part 6 was ViewModels – now it is time for the eye-candy and unleashing the power of the ViewModels. All views (save one) will implement the IView<TViewModel> interface which has a single method: void SetViewModel(TViewModel viewmodel). I’ll explain later why there are no more methods…
Now for the Views – I’ve implemented two relatively simple views – CustomerDetailView and CustomersView which will handle editing a single customer and showing customers respectively. I’ll not show the code here as that is not the intention of this series, but only give a few small notes:
Why is there so many small sections – shouldn’t it all be in one long XAML?
It’s a matter of preference mostly. I like to declaratively show what a view is comprised of. Some use comments inside the xaml, but I prefer having small sections that can be tied together into a larger picture. When I come back to the view 6 months later – I can quickly see where to go to change things. Some might think that it is for reusability, but that is only true for a very few controls – namely the DeicdeSaveSection and the PagingSection which will be used in the OrderDetailView and OrdersView later. When it comes to templating this is a much more valid point.
The Shell
Every application needs somewhere the user can select what he wants to look at. I call it a shell – a term stolen from Prism (the Composite Application Guidance from Microsoft). Basically, the Shell keeps track of what is possible in any given context and handles where the Views should be placed and how. The Shell does not know how many Views there are, nor what they show – it is a ‘dumb’ container responsible for layout’ing the views in relation to each other. One other responsebility is showing the ‘switchboard’ – here the ShellCommands.
There is a bit of styling in the Shell to allow it to show web 2.0-style popups. This will effectively enforce the problems around multiple transient Customers/Orders – making sure that only one new entity can be edited at the same time. Again nothing fancy, but you may notice that the Shell is responsible for creating the Commands it can activate. This is a bit of a shortcut – but since noone else is using the ShellCommands, I chose the pragmatic simple way.
Now, the glue to making it all function – we need to somehow create all the classes involved in the views. And we want to make sure that none of our classes need to know actual implementations, but only rely on the interface. This is called Dependency Injection (DI) and Inversion of Control (IoC). I chose something that is a bit of an anti-pattern – the static IoC. Since this is still a simple example, I don’t want the added complexity of passing the IoC container around at startup. So, bear with me on that one. Okay – a brief explanation of the static IoC – basically I use the App.xaml.cs to register which implementations I will use for each interface. Then when it comes to actually use the implementations, I call the Resolve<TService> method on the static IoC. Then the IoC will ‘magically’ find all the dependencies and resolve everything so that I do not need to worry about it. (It is of course not magic – the IoC container keeps track of which interface should resolve into what and instantiates them according to the constructor parameters of the class to be resolved). The resolve-method is used in the CustomerCommands and ShellCommands classes.
For http://goblincave.net/06/2010/m-v-vm-building-an-erp-system-%E2%80%93-part-8-of-n-rounding-up-customers.php, I’ll take a breather and look back on what we have actually done so far.
About the series:
The solutions introduced here are not entry-level material. You should understand generics and basic patterns to fully utilize the material presented. The solution represents about 3 years of experience working with one ERP-solution. Some of the choices taken are heavily influenced from the large-scale solution and may seem overkill for the simple examples here, but the idea is to show the end-result of my experience and hopefully you as the reader will at least see a new way of doing things. The solution is built in .Net 4.0 with heavy use of WPF’s capabilities. Here you can find the source-code for the series. You are free to use this code for any purpose, but it is presented as-is with no guarantees. Enjoy!
Goblincave » M-V-VM Building an ERP-system – part 8 of N – Rounding up customers said,
June 6, 2010 at 22:32
[...] we have successfully created a small application in part 7 where the user can add, edit and remove customers. Not bad considering the small amount of code in [...]