Building the Model : Business Objects

As part of our recent evaluation I developed a simple demo application for each of the MVC frameworks that we were considering here at Amcom for use on future projects.

I'll be writing several posts describing how I went about building the demo, what technologies were used and just general impressions and opinions about using ColdFusion to build object oriented applications. I plan on breaking the posts up into roughly these topics:

• The Model : Business objects
• The Model : Service Layer and Gateways
• The Client with Coldbox
• The Client with ModelGlue
• The Client with MachII
• The Client with Flex

This first post will be about designing and implementing the business objects for use within the Model and throughout the application as a whole.

First off, I've always found "Business Objects" to be a pretty vague term that can mean different things to different people. The way that I try to think of them, is as the nouns that one would use to describe the business that the application deals with. So if the application is for a company that makes widgets, you'll have a widget object, probably some invoice objects, customer objects etc... Most business objects will also tend to be stored in a database. So here lies one of our first challenges.

The design goals for a database and the design goals for an Object Model are different. A database is more concerned with efficiency and data integrity while an Object Model is more concerned with representing the real world business "things" and how they should behave and interact. There is a pretty commonly held view (excellent description here), that when building an object oriented application you should start by designing the Object Model, not by designing the Relational Model. Because in a perfect world there would actually be no need for a database at all, computers would have an unlimited amount memory and they would always be on.

But here in the real world, we do have to persist our data somehow and that is usually in an RDBMS. In practice I've found that starting by designing the Object Model can be difficult or not possible since a lot of development is done on existing applications with an existing database. Also there are a lot of applications that are not complex enough to really warrant much differentiation between your tables and your objects. And finally it can be just plain hard for people so used to working with the database (as many of us in the CF world are) to break away from that mentality and start thinking about the objects.

So how do we handle this? Well, I say let's strive to build our objects based on the data they represent and the behaviors we want them to exhibit as an ideal, but be prepared to accept that in our implementation there will sometimes be a strong correlation between our object model and our relational model. And also that it's ok for either one to influence design choices in the other.

Let's get to it then. For this demo, I'll be doing yet another contact manager type thing. So we are going to be modeling people in an organization, some of them will be users, some will just be contacts, you could extend this to include employees or basically any type of person that you want to keep contact information for.

I think it is helpful to first design a fairly abstract model, which will then get iteratively refined as we progress. So here is a simple class diagram representing our model. In all of the diagrams that I'll be showing I make the assumption that properties will have accessors and mutators, so they needn't be included, I'll only include them if they do some kind of calculation or logic. Also notice that this is a fairly anemic model at this point, since for this demo we are mostly just going to do some data access and manipulation.

Ok so that will be the start of our model for the business objects in this application. It will get a more flushed out as we go along, and since I'll be using an ORM the specific details will look a little different, but I wanted to show a more general diagram first.

So the question then is, how do we implement it? Like everything in computer engineering we have several choices. If you know me, I think you can guess what I'll choose... I'll be using Transfer and Coldspring as all good children should.

If you aren't familiar with either of these, do yourself a favor and look into them. Coldspring is absolutely essential (in my mind) for any OO development in CF, and Transfer gives you a nice head start on building business objects, makes database interaction pleasant and non repetitive and it also boasts an advanced caching mechanism to boost performance as well as a pretty cool event model. But this series isn't really going to be a tutorial on either of these, there are plenty of those. Although I will try to cover enough of each as we go along so that if you're not familiar with them you can still see what's going on.

Tune in next time for some Transfer love...