KWPro.net

The author here has some good points.  A lot of it boils down to what your technical requirements are.  I'm reading things here such as maintenability, performance, code bloat, etc.  It really comes down to two areas in my world: maintenability vs. performance.

I'm someone who's a heavy believer in maintenability over performance.  Why is that?  The performance of computers will continue to rise and become cheaper, but code doesn't necessarily get easier to work with and yet sticks with you for long periods of time.  So the real bottleneck for me is always maintenance (and don't forget the saying: maintenance is probably the highest cost in software).

That said, I've never truly seen a good, consistent methodology for managing business logic.  Some people call services "business logic".  Others describe stored procedures or DAOs as business logic.  You can even say that data validation, as my previous article suggests, can be considered business logic.

So with all these areas being talked about, what is business logic?

For me, I use the process of elimination to determine what business logic truly means in a way.  First, I do not consider DAOs as business logic because DAOs only are methods for accessing the data.  They do not create process flows nor the relationships in a meaningful, business-oriented manner.  They ought to be, for the most part, CRUD operations.

Second, a service does not necessarily imply business operations.  A service reminds me of services on your unix/linux/windows systems.  An echo service or a time service.  You send it data, you get a response.  How that response is processed is the business logic part.  But the service itself might be composed of various processes that interrelate in order to create that response.  Hence, it is not business logic, per se.

Data validation, according to my previous article, is just ensuring that your lower levels are getting expected data.  It enforces the cleanliness, to a degree, of the data being passed back from the input parameters.  But that in itself should not indicate business logic.  It only indicates the types of data that the application wants.

I don't think the C as in Controller in the MVC design pattern is a clear indicator of business logic either (nor the model, since the model is a representation of a business unit, but is not a process in itself).  The controller for me has two meanings: 1) it's an event watcher (as it follows the observer pattern); and 2) it's a pipe, as in the UNIX terminology.  It only directs the flow of information from one part to another.  Since most web controllers are pretty strictly defined, I find the controller area to have little or no reuse (unless you have some sort of base controller that contains properties for a class of web applications).  Because of this, I dislike putting little or any business logic in this area.

That doesn't leave much left.  But there is something that I keep reiterating, the keyword "process".  Business logic is the processes/operations that mimic your business, at least from a backend point of view.  The pattern used here might be a business delegate or a session facade, if you're into the EJB realm.  The session facade, in essence, is a session bean that manages the workflow of your entity beans (the model layer).  So let's say you want to create a new user.  Perhaps, your user is composed of several tables in the database, an address table, a user table, and some extended information.  When you go to create a user, you need to essentially perform three inserts and perhaps check to see whether or not the user's information already exist.  You can have four business operations right there.  But you can also have one general operation that handles all four.

This is the power of business logic.  By segregating your business operations, you can re-assemble them to form larger, more complex operations.  From a controller's viewpoint, it only would care whether or not the operation succeeded and the fact that it needed to use that operation.  Beyond that point, it wouldn't have to know about whether or not the extended information was created or not.  If the operation did not succeed, we could throw a business specific error message, telling the user that the operation had failed (perhaps because the user's id already exist).

Here, the key is that this is a potentially reusable function.  Imagine now that you expose this function via web service and allow other websites to create users through your web service.  If this logic was located in the controller, you probably would be forced to copy and paste this logic into a new controller that is specific for web services (if you use controllers for web services). Or perhaps you want to just create an internal user like an admin user for your company.  And let's say that you were partly intelligent in your database design and centralized all user information inside one table.  Now, you can reuse this function with a customized front end for your intranet.

Once again, the idea of business logic to me is similar to the notion of the session facade.  Whatever data access mechanism you have gets managed by the facade.  It hides that level of detail while providing higher level functions that are reusable.  At times, some of these functions may seem redundant.  Perhaps, all you're doing is forwarding your create user statement to a dao insert statement.  This is fine since you're now separating concerns of the application.

One thing I've noticed in my design of business logic is that while there's a great deal of reuse in being able to call functions within other functions, there's little opportunities for OOP style reuse.  Perhaps, your business logic layer may have a few common operations such as DAO injection, logging, and getting/setting of services.  But I think this is about as much reuse from an OOP viewpoint that you're going to see.  Most of the functions probably are stateless since the business logic is organized more through workflows and operations that are functional rather than requiring specific attributes to be instatiated at request time.  Because of this, I recommend making this type of object as a singleton with static methods.