Code Comparison

This page contrasts the actual code: Automated Business Logic vs. Traditional Hand Code.


The actual code in the following sections, and briefly summarized below.

Traditional Code Count

Focusing just on the code replaced by the 5 rules, we wrote approximately 500 lines of code.  This is of course in addition to the design time to work through the issues discussed here.

 Class    Lines Notes
 RequestProcessorManual (135) Not counted, since similar amount required for Business Logic version.  But note that this might be eliminated with a good UI framework that automated read/write of domain objects.
 SCustomer    139 
 SPurchaseorder 159 
 SLineitem 155 
 SProduct   65 

See for example sLineitem#setQtyOrdered().  The basic operation of the Service Objects is as follows:
  • Change Analysis
The program must first detect what has occurred: an insert, update or delete.  For updates, we also must determine which attributes change (though we have taken a significant simplification by saving changes after a single field is altered)

  • Change Propagation
Next, the code must force the recomputation of dependent data.  In our example:
  • SLineitem#setQtyOrdered() calls #updateAmount()

  • SLineitem#updateAmount() updates the amount, computes the delta change, retrieves the Purchaseorder, and calls SPurchaseorder#updateAmountTotal(delta) 

  • SPurchaseorder#updateAmountTotal(delta) updates the amountTotal, retrieves the Customer, and calls SCustomer#updateBalance()

  • SCustomer#updateBalance() updates the balance and calls checkCredit()

  • SCustomer#checkCredit() checks the credit limit

Automated Code Count

There were approximately 60 lines of logic.

Declarative version - Automated Business Logic

The first version is the declarative code: it consists of just a few methods, all of them empty since, in this simple example, all the work is done by the annotations.

Traditional version - Hand-written Java

The second version is the hand-written code required to duplicate the same functionality without ABL.

The business logic tends to be scattered across classes and methods. This is very brittle -- it's very easy to forget a call in a method, leading to a potentially non-obvious bug.