What do you put in your Base Object?
On the one hand, it's great to have some standard methods available to all of your objects. On the other, it lessens portability (your objects now all depend on an inheritance hierarchy starting with your base bean) and it can be a temptation (if you're not careful) to create a “kitchen sink” base object where you throw in a full set of utilities for everything from validation to notifications which is not a very good way to design an app.
Personally, I use a base object to provide for language extensions that I want to have available for all of my CFC's, so I put generic getters and setters into my base bean as well as a dump() method to allow for easy CFDumping within a cfscript block. For CF8 apps I'll also drop in a standard onMissingMethod() for handling getters and setters and other missing methods.
Do you use a custom base object for your applications? If so, what do you put into it, and why?
So I might have a Person class that extends my Base class, and have dependency information in the Person class like so:
variables.dependencies = arraynew(1);
variables.dependencies[1] = structnew();
variables.dependencies[1].name = 'emails';
variables.dependencies[1].class = 'email';
variables.dependencies[1].type = 'onetomany';
// etc with more dependencies if needed
The base class checks for a dependency array when it is instantiated, and if one exists, it runs the injector method. The object service passes itself to the base class when an object is instantiated, so any object can instantiate another object from within itself, to facilitate the injection.
Are you using some kind of DI framework (ColdSpring, LightWire, etc.) and what kind of cases do you find putting the dependencies into the bean to fit better for?
I suppose the downside is that you can't "see" the overall dependencies without cracking open the class file itself - but on the other hand, if you're wondering "what dependencies does the Person class have" you can just open Person.cfc and have a look, without sifting through any XML.
It's all part of an ORM framework that uses db introspection and builds objects on the fly from the db metadata. My goal was to make it so metadata only exists in the database. So, the database *is* the API, rather than re-describing the metadata in XML or some other way. It's taking DRY to the extreme.
When you instantiate the framework, the datasource metadata is introspected from the db into the application scope. This metadata is then passed in to each object via the object service, for use in setting the object properties and defaults. This way when you add a new property to the Person table for example, such as "birthdate", the new property gets sucked into the object without any additional configuration (of course you have to restart the app so the metadata gets refreshed). It's just "there" for you so when you say person.get('birthdate') it will work.
It probably violates encapsulation, though I've set it up so only properties that exist in the metadata are settable/gettable. In other words, you can only set or get the property "firstname" of the Person class if the field "firstname" exists in the Person metadata, i.e. it exists in the Person table in the database.
The whole framework is four files: baseClass.cfc, baseDAO.cfc, objectService.cfc, and dbintrospect.cfc. Then you build out your specific classes on top of that.
It's all for fun, I wouldn't recommend it for production use at the moment. I'm sort of using it to see what the capabilities of ColdFusion are if you throw out a lot of the rules.
That said, if those issues don't map to your problem space, it's certainly a very quick way of generating apps!
As it stands the custom classes are light, containing just a call to super.init(), maybe some dependency configuration, and a few display methods (displayTableRows() for example) so there's plenty of room for any additional methods I may need.
And, I've adopted the IBO methodology for the baseClass so the performance issue of instantiating a bunch of objects is negated.