Looks like this will be the first session today that Matt won't be beating me to the aggregators to cover (since he's giving the presentation). Again, sorry for the incomplete nature of the post - but these are my actual notes from the session - for further details you should follow up at the presenters blog since most of them post their preso online after the session.

Objects and the database: In reality we still have to deal with databases. At the application level, however, we focus on our object model. OO applications are nothing more then objects sending different messages to each other.

Cohesion and coupling. Very important concepts. Cohesion: the degree to which an object does one thing and does it well. Coupling: the degree to which objects depend upon each other. High cohesion/loose coupling is the goal.

Front end/UI/Presentation layer Controller layer - broker between front end and service layer. Service layer - exposes public API to business objects. Business object layer

Bus Obj layer - most important layer - protected from outside world (rest of the app). Should be reusable.

DB and OO - db does not necessarily map directly to objects. Don't try to match one to the other. Let each part do its job well. Data objects handle the communications and mappings between db and object model. ORM - another way to deal with the object model/relational db mismatch. Learn objects before using them!

Simple object - person bean is what models a person in Matt's sample app. A bean is more or less a dumb object that contains data (attributes) and methods (behavior) related to a person. Map single records in a db.

Getting data from the db - DAO - handle CRUD for single records.

DAO/Bean process - request for data - controller - service layer - DAO - Database - Bean - back to service layer - controller - front end (data requestor).

Pulling multiple records with a gateway. Gateways deal with multiple records/aggregate data. Usually return a query object (could also return a collection or array of bean objects.

Service layer - parts of the application (UI/controller) should not talk to the db directly. Creating a service layer provides an API to the entire business layer. Typically a thin layer that exposes an API to the business logic objects.

Controller layer - UI talks to controller. Can be homegrown or framework, etc. Should be relatively "dumb".

UI Layer - keep logic limited to presentation logic. If it isn't related it belongs somewhere else.

Why mess with all this? Integration with the front end becomes almost seemless and can be easily changed (AJAX/Flex/HTML) with minimal effort. Matt shows a circa 1996 (complete with blink and marquee tags), a Flex front end and an AJAX front end - all of which utilize the same business logic with zero or minimal effort.