M-V-VM Building an ERP-system – part 8 of N – Rounding up customers

Skrevet - Friday, June 4th, 2010 kl. 22:09 | Kategori - * Coding, English posts

Okay, 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 the solution. Still we have a lot of classes involved and this alone creates a lot of complexity. We are paying the price for a very stable and easy-to-maintain solution down the road. I hope this will be easy to see when we start implementing entity number two – the order.

The first 7 posts in this series have been focused on taking baby-steps in order to get to the point where we have something to show. I’ve intentionally split this series into two – to show how I work when I develop ERP-solutions. I call it vertical slizing – ie. taking one core functionality and making that ‘finished’ before turning to the next functionality. Many of the ideas behind the design of the model is taken from Domain Driven Developement while a lot of patterns shine through in the class-design.

Room for improvement
Some things in the solution are intentionally kept simple to focus on the M-V-VM pattern. For one thing, the repositories are _very_ simple, but since most ERP solutions will be designed around an ORM, this is actually a non-issue. The repositories in the solution are fine for testing and not having to depend on schemas and other expensive (especially to change) friction makes you productive. If it costs you next to nothing to change into a better design, you will be easier to persuade to do it. The longer you can postpone the data-access, the clearer your approach will be when you decide to tackle it.

Next the CustomerCommands class is not exactly how I would do it in production code. I would put the wiring into a mediator class instead of a command – much of it is plumbing, and could easily be contained in a separate class. Some call it a Controller (MVC) – some call it a Presenter (MVP). I usually end up with a constellation of ViewModel, Model, View, Controller and perhaps a helper or two for specialized views (usually drag and drop functionality or a secondary ViewModel). Usually my Entity commands are one-liners using the IoC container and calling a method on the resulting class.

Third, we have the views – these are obviously not receiving the loving they are entitled to. WPF is a rich language and you can make absolutely stunning things here, but maybe I’ll look into that in another series. Again, the focus here is the ViewModels – not the Views.

Last, but not least – the order in which I showed the classes are not necessarily the order in which I design production code. The order has been slightly modified to better fit the logic flow of the series. I usually start out with the Model – when I have that working, I turn to UI basically specifying the bindings I’ll need from the ViewModel and then designing that last. So far things have been relatively straight-forward, but when we turn to Orders, things will become somewhat more complex.

After this short stop – I’ll turn to orders in part 9.

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!