Making a First Attempt at Hooking the UI to the Domain Model

I once started describing a new architecture from the bottom up. I mean, I started describing it from the database. One of the readers told me in no uncertain terms that I should start talking about what the architecture looked like from the UI programmer's point of view. If it wasn't good in that perspective, there was no point reading on. I decided that that way of thinking had its merits, so it's now time to have a first look at the Domain Model we just sketched from a UI programmer's viewpoint.

A Basic Goal

I want you to consider whether you think we are fulfilling one of my basic goals, which is providing "simplicity to the left" (or "simplicity to the top," depending upon how you visualize the layers in a layered architecture). What I mean is providing a simple API for the UI programmer so he or she can easily see, breathe, and understand the model, and can focus on UI matters and not have to think about complex protocols for the Domain Model.

Skipping data binding is not a basic goal, not at all, but I will skip data binding here in the first discussion about the UI. Data binding won't be the focus at all in this book, but we'll touch some more on that in later chapters.

The Current Focus of the Simple UI

I think the Domain Model might be somewhat abstract at the moment, but discussing it from a UI point of view might change this a bit. The scenarios I think we should try out are the following:

• List orders for a customer

• Add an order

Again, I won't use ordinary databinding right here, but just simple, direct code for hooking the UI to the Domain Model.

List Orders for a Customer

I need to be able to list orders for a customer. When the Domain Model is built later on, I just need to add a "view" on top of the Domain Model and fake some Orders. I'm thinking about a form that looks something like the one in Figure 4-14.

Figure 4-14. List orders for a customer

Note

You might think that I'm fighting the tool (VS.NET or similar form editors), but because I'm in extremely early sketch mode, I decided to visualize the form ideas with pen and paper. (But for this book, I'll provide images that were rendered in a graphics program.)

This is plain and simple. To make this possible to test and show, we need to write a function that could be called from Main() for faking a customer and some orders.

The user will probably choose a customer from a customer list form, and we provide the customer instance to the constructor of the form to show details of a single customer (let's call the form CustomerForm). The form stores the customer instance in a private field called (_customer).

Then the code in _PaintCustomer() method of the form could look like this:

//CustomerForm private void _PaintCustomer() {     //Get the data:     IList theOrders = _orderRepository.GetOrders(_customer);     //Paint the customer:     txtCustomerNumber.Text =         _customer.CustomerNumber.ToString();     txtName.Text = _customer.Name;     //Paint the orders:     foreach (Order o in theOrders)    {         //TODO...    } }

Something that is worth pointing out is that I expect the usage of Null Object [Woolf Null Object] in the previous code when I paint the orders. Because of that, all orders will have a ReferencePerson (an empty one), even if it hasn't been decided yet, so I don't need any null checks. In my opinion, this is an example of a detail that shows how to increase the simplicity for the UI programmer.

Having to write the code by hand for filling the UI was a bit tedious. But looking back at it, isn't it extremely simple to read so far? Sure, we are trying out simple things, but still.

Add an Order

The other form example is one for making it possible to add an order. I'm envisioning that you have first selected the customer and then you get a form like the one shown in Figure 4-15.

Figure 4-15. Form for adding an order

To make this happen, first an Order is instantiated, and then the order is sent to the constructor of the form.

The code for _PaintOrder() could then look like this:

//OrderForm._PaintOrder() txtOrderNumber.Text = _ShowOrderNumber(_order.OrderNumber); txtOrderDate.Text = _order.OrderDate.ToString(); //And so on, the code here is extremely similar in //principle to the one shown above for _PaintCustomer().

To avoid having a zero value for txtOrderNumber, I used a helper (_ShowOrderNumber()) that perhaps shows "New" instead of 0.

What Did We Just See?

One way of describing this type of UI is to use the pattern Fowler calls Separated Presentation [Fowler PoEAA2]. The idea is to separate the logic from the code that manipulates the presentation. It's a basic principle that has been recommended for a long time; however, it's very often abused. We get it at least to a degree more or less automatically and for free because we use DDD.

Again, this section was mostly to give us a better feeling about the requirements by thinking about them from another perspective, the UI. From now on, we won't discuss much about UI-related things until we get to Chapter 11, "Focus on the UI."

Now let's move on to yet another view regarding the requirements.