KWPro.net

Having been working with web architectures for a while, I've come to realize that the common paradigm of MVC (Model-View-Controller) doesn't seem to scale too well in terms of development.  My problem with this paradigm is that I've often run into situations where I require ways of improving the centralizing of business logic.  Some people believe that the business logic should reside in the controller while others say that model objects should retain these characteristics.  I feel that neither are sufficient for this purpose.

If we look at the strict definition of what the Model and Controller are, we can see how the business layer truly does not fit either.  Models represent abstract entities of the business.  They support some logic but are themselves simply entities.  They are not themselves processes and in reality represent some row in a table for a database.  Controllers are a form of the Observer pattern and signify a simply notification and kind of triggering device.  In the web paradigm, they receive an event with information (the request), perform some limited data manipulation and hand off the data to the view/response for display purposes.  However, I've found the controller to be more or less a throwaway object with limited purpose in the context of web programming.  If you house all your business logic within the controller, then extending this logic to other objects becomes difficult, and even more difficult during testing.

In a layered architecture, we're now encountering several common but additional functionality in authentication, authorization, validation and some form of business logic (usually CRUD).  I tend to place the security aspects like authentication and authorization as being more at the controller level rather than making them strict business functionality (although the actual code can be housed in a class or package that handles authorization and authentication).  Next, I tend to split most validation off from the business logic.  Of course, some validation is required at the business logic level, for instance checking to see if a credit card number already exist in a database prior to creating the card.  But validation, for me at least, in the web sense takes into account simple, non-application specific type of rules such as checking if a string consists of all numbers, ensuring that an input field exists, or disallowing for non-email address formats using a regular expression.  I usually insert this piece of logic prior to the routine in the controller that handles the processing of the incoming data.

The business logic layer though is quite ambiguous but I think that EJB's notion/use of session beans to handle the lifecycle of entity beans is what I would consider to be appropriate.  Concretely speaking, I see this layer to be the one that manages the lifecycle of the model, not the controller.  Lets say for instance that you wanted a routine to create users.  If we placed this at the controller level, we might be limited to using one controller for this function.  What if we wanted to expand this to a web service?  What if we wanted to expand this to various types of web services that outputted various formats?  We'd either have to inherit the controller and make that method private or do something funky.  In some cases, we may not even have that choice because of how a framework might limit what we can do with that controller.  In those cases, we might be forced to create multiple controllers with no chance to extend.  So in the end, we'd be forced to do a lot of copy-n-paste code.

Not very reusable.

The business layer would eliminate this notion by providing a middle ground.  It's not a proxy for requests.  I see it as multitiudes of mini-functions that do a single operation.  Method names would be at a high level such as createUser, removeProject, isAccountEmpty, etc.  From this, you could easily compose other bigger functions.  For instance, a removeUser method might invalidate or remove all related entitlements such as projects the person owns or access rights.

I think one of the difficulties of a business layer is the formalization of how it should be used.  If we again compare this layer to be the EJB session bean layer, this situation would make these objects stateless.  I don't see much chances for object inheritance here.  Perhaps, these objects would have only a few common features like logging, or access to factories that create models or services.  Beyond that, these objects would be essentially static method calls that perform no more than one operation.  They would be able to interact with the controller, service and model layers using value objects or associative arrays to communicate between layers.  Meaningful exceptions should be thrown to the controller level or between business calls.  For example, one could have a BalanceLessThanZero type of exception if somehow a person was attempting to withdraw more money than he had in his bank account.

I think this concept needs to be introduced to the web paradigm and that the MVC notion updated overall to include the business layer.