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.

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.

The ground up…

Starting at the bottom of the application climb is the design specification. That can be the most time consuming part of the application and arguably the most important. I recommend Agile Development and Extreme Programming as some good reading. It’s important to start programming with a good definition if you don’t want to start more than once. However, I should mention that a truly complete specification is almost impossible to come by. Even in a small project the specification usually changes very soon (the only reason it was a small project was the spec wasn’t truly finished).

In my world you: 1). try to get a solid, hard-copy specification for an application 2). get some confirmation on the design and 3). start to quickly deliver small parts of yor application for acceptance testing from the client. This gives everybody something to feel good about and keeps you from having a overly worked-on specification for a project that is already starting to late.

Many people know what UML is and for those who don’t here is a primer. The hard-copy of a design specification can be pages of text that give you the clients ideas/instructions, but for a better start you will also have a set of visual diagrams to quickly relay key concepts to you and/or your team. These visual diagrams: Class, Use Case, Activity, Sequence and State Machine should be part of your initial efforts to define the specification before you go any farther than interface prototyping. Some would argue that you can’t start anything without these diagrams, however, I feel there are times when you need to solidify parts of the spec by getting some useful feedback from the client and that sometimes requires toys!

Up next I hope to talk about database design, where you can stick your SQL and not thinking too abstract…

As a side note (not a paid advertisement) I would recommend Agilian by Visual Paradigm as an excellent (possibly daunting at first) tool for implementing design diagrams into your application development process. A dry-erase board, notepad and copy machine works too.

The Cairngorm Framework…

Cairngorm – If you are using Flex without it for anything more than a very simple application, please give it a try.

There are many who will state that there is no reason to code so many pieces to get a small application up and running. I believe that if you aren’t creating applications that will grow then you are fine to be in that camp. I hardly ever work on applications, even for my own personal use, that are small enough that they don’t grow. The growth of an application gets exponentially more difficult (time-consuming, error-prone) as you repair and extend the application over a long period of time especially if you are working on more than one project. The smaller and more defined (with a socially accepted convention) the chunks of your applications, in a team or alone, the easier it is to step into a project and know right were to go. I often still get a laugh when I go into a large project (Flex or otherwise) to fix or add a small feature and can wrap the task up (and test) in a half-hour. Because the structure is so second nature, the application tells me where to go to make the change. And this is true of any application where you effectively employ good design patterns.

There are some key Design Patterns, most of which can be found here J2EE Design Patters . Some you may be using and not even know the name. I hope to blog soon about some specific implementations using ColdFusion and Flex in the near future.

Bloging about Flex…

For the most part I intend to use this blog to tout the power, elegance and simplicity of Flex. I will undoubtedly spend a great deal of time discussing ColdFusion, J2EE Design Patterns, and Cairngorm – why they are an important part of my development and what they can mean to you. RIAs (Rich Internet Applications) are becoming a big thing both in the browser and on the desktop, and I hope to learn a lot and educated some on the richness of the king of the Rich Internet Application technologies Flex.

Flex, ColdFusion and Flash Remoting make the job so simple. Really, when you are setting out to prototype you can’t beat Flex Builder for pulling together a great looking mockup that you will more than likely be able to use all the way to production. The ability to get designers and developers (or those of us so endowed to do both equally well) using the same IDE for drawing an interface or scripting one together in xml (mxml) is a huge advantage in team work exchange.

here i am…

I’m new to writing anything but code…Why would I start?

I’m trying to get some information out there and see what blogging can do for me. If all goes well this blog will be of use to someone.

Let me know!