This page provides a brief context of Web Apps, illustrating where business logic fits in. This discussion presumes you are familiar with the key elements of object technology.
Web Applications - multi-tiered architecture
Consider how we might a web application. Such applications read data from a database, present it to the user, and provide buttons to save/submit changes back to the database. There are some key elements worth noting.
You can generate/process HTML directly, but nobody does that. There are many frameworks
that enable you to define pages, put data on them, and get control (handle events
) when buttons are pressed, for example to save changes back to the database.
Database Access: JDBC and Hibernate
JDBC is a standard for accessing relational databases. It is effective but clumsy: it returns arrays of strings rather that Beans, so programmers typically don't prefer it. Who wants to remember that the 3rd column is the balance?
/ JPA is a newer standard that builds on top of JDBC to provide a more Java-friendly database access mechanism, including reading results into Beans (not arrays), and dealing with inheritance. Hibernate code looks like this:
Purchaseorder theNewOrder = new Purchaseorder();
... // similar code to create the line items
hibSession.save(theNewOrder); // TODO... compute customer balance, check credit... where??
As noted in the last line above, the "save" logic (such as computing the balance and checking the credit limit) is not encapsulated into Purchaseorder Domain Object. This idea of "save logic" gets us into 1 area of Business Logic (the term is vaguely defined, often meaning simply "all the code that is not User Interface).
So where is this code (what is the architecture)? There are many, many (strongly held - a heated topic!) opinions, including:
- Make POJOs DAOs (Domain Access Objects) - this just means add "crud" methods (create, read, update and delete) to the POJO. But this raises all sorts of questions, such as "why is Order responsible for the integrity of Customer"?
- Hibernate Events - Hibernate surfaces Events (beforeUpdate, afterUpdate etc) where you can add business logic. But these are very complicated, with many subtle restrictions on accessing and updating data
- Introduce a Service Layer - others feel that they need to build an entire layer over Hibernate that provides specific APIs for each transaction, such as a PlaceOrder method that accepts parameters of Order and Lineitems, and stores them (via Hibernate) and enforces all the relevant logic multi-table.
Not to step into that debate, but there is one area where experts agree: the business logic must be broken out of the User Interface code. Why?
- Sharing reduces your code bases - code takes time. Write less, go faster.
- On a purely aesthetic basis, shared code is like a factored equation
- But it goes much deeper - errors / omissions in business logic result in bad data going into the database, bad business decisions (e.g., selling products for less than they cost) and bad results for our customers (e.g., selling discontinued products)
In any case, the business logic is a lot of code.
In a typical online update application, it may account for half
your code. You can review our sample
, which contrasts conventional business logic with automated business logic.
And that's why we wrote ABL. We can significantly reduce this code (like by 100:1), and eliminate the design complexities. This makes your organization more agile, and improves quality. Here's how
As noted above, once you have factored out your Business Logic from screen logic, this logic can be used to process messages received from other systems. Not only does this shared logic reduce code base, it means for example that an order placed online will be "get the same answer" as one received electronically.