Business Object Modeling

Business object (or domain) modeling is probably the most important concept in the framework. The entire framework was built around this concept. In fact, I’m not sure that the caching layer would work as it does now without this concept.

Say you have one or two “classes” with methods like getEvent(), getEventsByVenue(), and getFeaturedEvents(). In the getEvent() method, there is a giant query that returns everything there is to know about an event, given an event ID. In the getEventsByVenue() method, there is a giant query that returns everything there is to know about all the events occurring at a given venue. In the getFeaturedEvents(), there is a giant query that returns everything there is to know about all events marked as featured, after a JOIN with the featured_events table.

See the pattern? This is not object modeling. This is page modeling, and procedural query hell. There is some re-use, but it’s pretty much a straight line. Suppose I want to add a field to events, for example `sponsor`. I have to find every query that returns event information and add the `sponsor` field to the SELECT clause. Suppose I want something new, all featured events at a venue. If I modify the current getFeaturedEvents() method, I have to change its signature everywhere its used. Or I can add a new method, getFeaturedEventsByVenue(), but it would duplicate 95% of the getFeaturedEvents() method.

These aren’t real examples, but you get the idea. How can we compose objects such that they can contain one another, but don’t have to know anything about each other? Put another way, how do we get as loosely coupled as possible?

Pox was designed such that any and all code having to do with a certain class is contained in that class. So any code having to do with events is found only in the Event class, and any code having to do with venues is found only in the Venue class. But of course a venue has (or contains) events. Then the that relationship is coded in the Venue class, probably using an SQL query, but at most, the Venue class only needs the ID’s of its events. Each event can create itself, and provide any needed information itself at a later time.

You can read about a concrete example in the blog tutorial in the page about blog comments. In this example, a blog post has comments – I’ll quote from that page here:

Post and Comment are full-fledged business objects in their own rights, but a Post can
have Comments. So a given Post object knows how to retrieve all of its Comments on its
own, using its own ID, by simply representing the relationship with a SQL query. The
comments can create themselves and provide any needed data at a later time. Thus, all Post
code and Comment code are kept in their respective classes. Only the relationship is
coded. There is no need to write a query that returns all information for all comments in
the Post class. In fact, doing so would be wrong – code to return information about a
comment such as title and comment text, or any code having to do with a comment,
should only occur in one place in the whole system, and it should be in the Comment class.