M-V-VM Building an ERP-system – part 10 of N – OrderLines

Skrevet - Sunday, June 6th, 2010 kl. 22:15 | Kategori - * Coding, English posts

I’ve saved the goodies for the last post. We are now ready to edit an order after post 9 – and we want to do it in style. We want to present the user with a really nice interface for fast input. We could have done it the old-fashioned way with an ‘Add’ button for adding an orderline in a new window, but hey, we got a shiny ‘new’ DataGrid in 4.0 – so let’s put that for a spin:

public interface IOrderDetailViewModel : IEntityViewModel<IOrder>
{

DateTime OrderDate { get; set; }
ICustomer Customer { get; set; }
ObservableCollection OrderLines { get; }
IAvailableCustomerSelection AvailableCustomers { get; }

}
public interface IOrderLineViewModel : INotifyPropertyChanged
{

IOrderLine CreateUpdatedOrderLine();
decimal Quantity { get; set; }
string Description { get; set; }
decimal PriceEach { get; set; }
decimal TotalPrice { get; }
void SetInvoiceLine(IOrderLine orderLine);

}

Okay – that should provoke a few comments…

You made a typo – shouldn’t the ObservableCollection<OrderLineViewModel> be of <IOrderLineViewModel>?
Actually no. The problem lies with the DataGrid – when there are no items in the collection, it will not show the ‘new item placeholder’ since it does not know whether it is possible to do so. It needs to know which class is to be instantiated and that class must have a default no-argument constructor. And since the ViewModel exists to please the View – there’s nothing for us to do, but satisfy the whims of the View.

But you still made the IOrderLineViewModel interface?
A valid point. It is mostly for consistency – I don’t like it when 99% of a the same type of class has interface and the last 1% doesn’t – it makes me think too much. “Why was it that class didn’t have an interface…” – “Argh, why is there two more classes than interfaces for ViewModels…” – those kinds of questions pop up every once in a while, and they are noise. The interface doesn’t cost me a whole lot of time, but it saves time when I don’t have to wonder why it isn’t there 6 months from now.

Why are there setters on the properties in the IOrderLineViewModel – IOrderLine doesn’t have them?
Remember that the ViewModel isn’t the Model – it’s a View of it. Here the OrderLineViewModel acts as an input-helper for the user. It allows the user to input orderlines without respecting the constructor of OrderLine. Basically, the user can come back to an orderline and change it before committing it to the order. And it gives the semblance to the user that the order line is editable, when it actually is not.

I will not go into further detail of the implementations – I’ve already made 5 more posts than originally planned and 10 is a nice round number. So, what have I tried to show you, the reader? First off, I’ve tried to give you a glimpse of what I do, when I program ERP-systems – second, I’ve shown you how I handle (some of) domain driven design in the UI and finally third – I’ve given a few pointers and ways to handle collections, null and properties that does not exist in the Model. I hope you enjoyed the series – and hope, I’ve shown you a few things that might help you get past a few hurdles using M-V-VM.

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!