Intelligence design…

When you have access to your data you must create rules, based on the specification, that keep that data safe yet enable it’s modification. You do this in the BI.

The BI is a set of objects (in my case very few objects) that create an application interface between the very open DAOs and the very specific Services. In a bookstore app I would have Objects like OperationsBI and CustomerServiceBI. OperationsBI may contain methods for stocking books and fulfilling orders where CustomerServiceBI might have methods for creating customer logins and placing orders. Anytime that I am going to run a process and interact with multiple DAOs I use a BI. In fact, I also use BIs as a gateway to the DAOs. I always have the Services Layer talk to the BI using DTOs and never DAOs. The only time there is a direct access to the DAOs from the service layer is for large, fairly static lists. For instance, When I need to present geographical states to the UI I usually have a Factory in the abstraction layer that provides me with an xml document containing countries and states arranged appropriately. This is then provided through the services layer (or for very static lists sometimes directly from a template into an E4X variable at design time).

I like to reserve security for the Services (remote) layer and to block unwanted traffic I use Application.cfc as  directory cops (and make sure you log their activity). Most of the data validation I move into the DAOs and I throw specific Exceptions to give the BI and Services Layer a way to build invalid data logic.