AntiPattern: BusinessObjects in the driving seat

When you have a rich domain model with a business object centric design, and a Windows forms GUI, it can be very tempting to start putting significant process logic in the business objects. After continuing along this path a little further, you may realise that the process needs some sort of user input, and you use events or some sort of notifier pattern to gain user input required by the process, while still maintaining layering in terms of referencing. Then additionally you may need to access some sort of external service.

Here is an example:

class Order : BusinessObject
{
 public void SendOrder(INotifier notifier)
 {
   if (ReadyForDelivery ||
       Confirm("Are you sure you want to send order lines?"
             + " They are not ready for delivery."))
   {
     OrderLine[] orders = GetLinesToSend();
     foreach(OrderLine line in Lines)
     {
       SendLine(line); // send line using a web service?
     }

     Notify("Lines sent successfully.");
   }
 }
}

interface INotifier
{
 void Notify(string msg);
 bool Confirm(string msg);
 OrderLine[] GetLinesToSend();
}

I would like to suggest that this is an anti-pattern and a trap. Although there is no direct reference from the Business Layer to the GUI layer (INotifier is implemented in GUI and passed down), the Business Layer now requires the ability to stay instantiated, pause while waiting for responses from the notifier, and then continue execution. This will work for rich client applications, but not in a stateless web environment. The ideal of being able to swap in/out the GUI layers on top of the Business layer is now compromised.

Instead, it would be possible to drive form the GUI layer, and call a service to send the Order Lines. In pseudo code below:

void SendMenu_Click(...)
{
 if (Order.ReadyForDelivery ||
     MessageBox.Show(...) == DialogResult.Yes)
 {
   using (ChooseLineForm chooseLineForm =
            new ChooseLineForm(Order))
   {
     chooseLineForm.ShowDialog()
   }
   SendingSevice.SendLines(chooseLineForm.selectedLines);
   ...
 }
}

If the logic in the GUI layer became much more complex, it may be a good idea to pull it out into its own class (eg, LineSender). This class would be a type of GUI level controller, responsible for orchestrating the send process.

Using this approach, there are a number of benefits:

• BusinessObjects have no reliance on GUI implementation, so can be used for Rich Client and Web Client indiscriminately.
• Web developers are free to implement the user input process in stateless way more appropriate to their platform.
  
• Functionality for sending Order lines (some sort of integration with a web service?) is pulled out into a service class which can be reused elsewhere (potentially sending other types of objects?) and unclutters the Order business object and removes its dependency on an external service.
• Code is simpler and easier to follow.