Presented by Matt Woodward.

Why back to front? Starting with the database and moving forward is a good way to understand how all the OO pieces interact. Typically though, you want to start with the UI, and then develop the database according to that.

The most important part of the app isn’t necessarily the database; it’s the object model. This is obviously related to the database. OO applications should be thought of as nothing more than objects communicating with each other. So the database is irrelevant in that perspective.

Cohesion and coupling. Cohesion is the degree to which an object does one thing and does it well. Coupling is the degree that objects depend on each other. High cohesion–have lots of objects that do specific things. Low coupling–the objects have to speak to each other, but shouldn’t be highly dependent on how each other is organized.

Front End / Presentation Layer
|
Controller Layer
|
Service Layer
|
Business Logic Layer

Databases and OO. The DB may not map directly to the objects! Don’t try to force-fit objects to the database! Don’t do one-to-one mappings necessarily. Data objects will handle the mapping between your business objects and your database.

This is where object-relational mapping (ORM) comes into play. Helps a lot. But build some objects on your own before depending on ORM.

Sample Object: Person “bean”. Esentially maps to a single record in the database. It could contain data from numerous tables, for instance, when there is composition (i.e. phones and locations of a person).

DAO/Bean process. Request for person data –> Controller –> Service Layer –> DAO –> Database. DAO puts it in the bean, which gets passed back.

When pulling multiple records, you now may use a Table Gateway. Deals with multiple/aggregate data. Contains methods like getAllPoeple(), search(), etc. Typically may return a query object, because collections or arrays of objects can be pretty slow. Can be done if necessary though, and will perform a bit faster in CF8.

Table Gateway Process. Request –> Controller –> Service Layer –> Gateway –> Database. Gateway returns a query, which is acted upon.

Service layer. The UI and the controller layer should NOT talk to the database directly. Create the service layer and this layer is the API to the entire business layer! So, usually pretty thin in its purpose. But it is very important to make your controller and UI layers easy to maintain.

Controller layer. UI talks to this layer. Can be home-grown, or this is where a framework may jump in. Controller will then talk to the service layer.

User Interface layer. Keep logic limited to presentation logic. No queries.

Compare the controller layer to the service layer: Controller is more concerned about the front-end. Service layer is an API to the business logic. So the controller talks to the service for the UI. The controller is like the behavior of the UI. It’s a traffic cop.

Good example described by someone in the class: If your code was a married couple, the UI is one and the business logic is the other. They go through a divorce. The UI has a lawyer and the business logic have a lawyer. The divorcees don’t talk to each other; their lawyers talk to each other.

This may seem like a lot of work, but now your back-end can be used in multiple ways. For instance, you could use it in Ajax or Flex. Matt has an example where he replaces the circa-1996 page with a newer-looking interface built with ColdFusion 8 using Ajax. Then changes the UI again with a Flex front-end. Admittedly, he had to build a remoting facade for some of the functionality for the Ajax and Flex front-ends, but the facade was pretty light.

Conclusion

A call to arms: Try this stuff out! The old way is, well, old. You need to develop a comfort level by just trying it. It really is a better way to build things. Remember, the UI may be the last thing we think about as developers, but the UI is the application from our customers’ perspectives. Ajax and Flex give that richer experience.