The nitty gritty…

Behind every good man is a good woman… I know that certainly is true with me (right honey). Behind every good data application is a good domain model. Key components of this discussion are database choice, database schema, domain model, and data abstraction.

Usually the model will live (persist) in a database, but it’s important not to think of the model as the database. The domain of an application, in an object oriented design, is the set of object definitions for any object that will play a part in the application. For a bookstore application this would be books, customers, clerks, money and book accesories (among other things). In a simple bookstore application there may be a direct correlation between the domain and the database schema, but it’s important to note that the domain model does not have to be consistent with the underlying storage schema.

Optimizing a database for an application requires an understanding of the relationship of the tables and fields as well as an understanding of the queries (SQL, Stored Procedures) that will be performed most often. When you start to build your database schema, look to your  class diagrams as guides and you may find the model fits nicely into tables and fields that are identical to your diagrams. As you find database retrieval/persistence inefficiencies you may opt to modify your schema to give you better database performance or to enable some specialized scalability. Once the database schema is done it’s time to move on to the application.

I use, almost always, a three layer structure on the server. There is the Data Abstraction Layer (DAOs), the BI (Business Intelligence) Layer, and the Services Layer. With ColdFusion these are three sets of CFCs that perform specific functions. I use CFCs for the DAOs as they are defined later. I use a another small set of CFCs (usually one per category of objects) for the BIs. And then I have a set of CFCs that closely matches the BIs but offer a remote interface for interaction with Flex, CFMs (for generating reports, web forms, ajax…) or to be consumed as web services. Some specifics on the first of these layers…

Data Abstraction is the art (if I may) of creating SQL/Database agnostic code for your domain model. In ColdFusion this is a set of CFCs that encapsulate the SQL and offer a smart data interface to your applications. I have seen domain models that have basic CRUD (create, update, delete) functionality for each object providing a simple 3 method interface along with mutators and accessors for each property. I have also seen DAOs, very intelligently designed, that contained more specific logic in-order to decrease misuse or to simplify/enhance the business intelligence layer. I’m usually inclined to simplify my DAOs for the sake of reserving logic for the business intelligence. This allows the BI to extend the functionality very independent of the database and the original spec. Putting too much logic into the DAOs usually requires you to modify DAOs later – when you should only be modifying BIs.

Ok, that was long-winded… enough for now.