When a Form ISN'T a Business Object

However, I often find that there are a number of forms on simple websites that really don't need to relate to a business object at all. If someone wants to set an appointment online, you may well want an Appointment object with a bunch of business logic for setting them and managing them, but if you just want a simple "contact us" form or even an appointment form that is just supposed to send an email to a person to handle, it's probably not worth having a whole OO based system for processing those forms. This doesn't mean the form processor won't go through an OO framework - just that the form processing itself won't include populating and validating a form specific business object.

That begs the question, how do you determine whether a given form should have a related business object (or objects) . . .

I have generally used the rule of thumb that if something needed to be stored to a database (as opposed to just being emailed or saved to a file), I'd treat it as a business object. I don't think it's a terribly theoretically pure approach as the traditional benefit of business objects is the encapsulation of business logic with data, and if you have a form that is persisted to a database but doesn't *have* any custom business logic, there is very little benefit in an OO approach over a simpler procedural solution.

That said, it actually wasn't a bad rule of thumb for my use case as I already have some really slick infrastructure for describing business objects and their associated validations in a simple XML file that then generates everything from the db tables to the code required to list, view and process the forms. So, adding a new business object for me doesn't require anything more than describing the properties of the object and their associated validation rules in an XML file and everything is generated to make the solution just work. The only downside is that any substantive changes to the form (changes in the fields, their data types or their validation rules) requires a change to the XML file.

I'm currently rewriting my "non business object" form processor (you know, like a cgi form script - only in CF) and I'm trying to figure out how much it should be able to do. I definitely want it to support processing, validating, sending n-emails and persisting to a file, but I'm also wondering whether it makes sense for me to add some functionality so that a form can also generate and be persisted to a db table. On the whole I think it probably isn't worth it as once you start storing stuff in a db then you want to be able to list records, delete items, run imports and exports and maybe create reports - stuff which I already have the infrastructure to handle declaratively for business objects and which I'd just have to replicate in the form processor.

What do you think? Any opinions on how much your form processor should be able to do?