Goblincave

After part 3, we are getting ready to tie things together and as many might know, WPF contains the really nice ICommand interface that implements well with buttons, menus and inputbindings (go .Net 4.0). Back when I started out with WPF I used a lot of standalone implementations of the ICommand interface. It made for very nicely encapsulated commands, but there were problems. I put them into ResourceDictionaries for sharing them between views, but soon I had an overwhelming number of them, and naming became a problem. Also, maintainability proved troublesome. Having scattered business-logic scattered out into all these little classes that I couldn’t use DI (Dependency Injection) on proved a maintenance nightmare and ResourceDictionaries proved brittle (magic strings, anyone?). Testability wasn’t all that great either, and most of the commands were mostly doing boxing and un-boxing and IoC (Inversion of Control) resolution.

After part 2 – we now have a model to work from – and it is time to create the first ViewModel.

After some carefull consideration – I’ve chosen that we need a list of Customers where we can perform CRUD (Create, Read, Update, Delete), to make things a bit interesting, we want to have a paged view as we expect our customers to range in the thousands

As discussed in part 1, we need to implement the model somehow. The solution-source code shows the refactored result. There are 3 major implementation details that I will touch here:

• Validation
• Equality and Identity
• Collections

I’ve decided to post a series on how I would start out designing an ERP solution with focus on Model-View-ViewModel. To fully understand the reasoning, this first part mainly discusses the model in which I work. Many of the later choices should be clearer if you understand the reasoning behind it.

First of, there is no ‘one way’ to do M-V-VM – and how you use it, will determine, how (and if) you benefit from it. I design ERP-systems (Enterprise Resource Planning) which are typically rich on business-logic and have high demands for user-friendliness especially in dataentry screens. Thus, if I did UI-designing like I did back in the VBA-days, I would end up with a jumble of spaghetti-code with UI-concerns creeping into the cracks of my business-objects. So, the main focus for me is getting rid of all things not business in nature and isolating it in ViewModels.

Having started on the endeavour it is to create an ERP system (this time for real), I’ve put a lot of thought into the structure of the project. Having worked on our solution for transport for nearly 3 years has of course given me a lot of insights into what does not work, but also [...]