> Subject: Re: [CFCDev] OO Concept - Crit Welcomed
>
> Hey Scott
Hi Pat,
>
> I like the idea. one thing that i notice is that while your
> code is probably really scaleable. do you end up writing less
> code (and therefore taking less time) to develop a blog app ?
Actually no, of course its one of these projects where you feel like you're hitting an anthill with a sledgehammer. It gets the job done, but is still a heavy burden.
The concept at hand wasn't more to do with the project but essentially it was to promote the idea of patterns and cfmx and how if wanted could be used. Mainly for me to illustrate a stronger OO presence inside my code for me to guage success/failures from (ie Do even need to keep DAO/DG separate..etc).
>
> for every entitiy you need to build 3 classes. and write all
> the select/insert/update/delete sql statements ? do you think
> there could be genericDAO class that could do all this work for you ?
I could, but not all is as it appears. One could argue Comments look after themselves aswell as entries? But in some lights the Entry could also stoe away the comments (depending on your implementation). I've strayed away from Models which use generic DB storage (for now) as while they cheat and reduce your development time I've not really found much major gain in having them. I still prefer to have 3 classes in front of them, as if I change the way the DB is stored or provide duplicate updates (ie storing parts into legacy aswell as "new" db tables etc) it kind of sets me up in that way. This being a blog of course, highly likely that won't happen - yet I code in a self-defensive way - always keeping an eye out for the unknown. Heh I even try to code stuff one-time-perfect which never happens (can't blame a guy for dreaming).
> do you think that you might need some kind of auto-code
> generator to build you BO's each time ?
That I do! Of course its only at the initial creation that I use it, I had once played around (taken a page out of Daemon's FOURQ) in using CFPROPERTY to autodeclare the setters/getters (ie cheat at runtime) it worked and really couldn't fault it other then if a setter *actually* carries out some business logic, then its kind of redundant and you're back to hand coding.
> what about composite objects. how would your concept handle
> this case ?
Yes, actually good point to bring up. I noticed yesterday afternoon that actually my configBO won't hold water. Firstly because I'm actually breaking basic encapsulation rules by making the appListener setup the configBO within mach-ii and all other listeners assuming its existance. I later found that this won't work - thanks to a bug in the frameworks configure process - which showed that A listener won't always have its configure invoked before the rest of them, resulting in the CFC workflow becoming desynched from one another.
To rectify this, I've for the moment (still not happy with this idea, something about it doesn't sit right) to create a domainSingletonFacade Class (hehehehe abuse of pattern naming or what!) which basically "has-a" domainBO inside it, stored within application scope.
Eg:
- com.listeners.appListener creates instance.domainFacade and passes in MachII.framework.PropertyManager as an init() argument.
- com.model.machii.domainFacade checks application scope for existance of domainBO, if not it creates it and initializes domainBO with properties out of
PropertyManager (ie DSN, FileUploadLoc etc).
* Note: I specifically put domainFacade in com.model.machii, as its allowed to be machii aware.
* Note: First Listener to invoke initialization, setups up domainBO for all others (StructKeyExists type solution)
- com.listeners.blogListener creates instance.domainFacade and passes in MachII.framework.PropertyManager as an init() argument.
- com.listeners.blogListener creates instance.blogService and passes in instance.domainFacade.getDomainBO() into its init()
- com.model.machii.domainFacade.getDomainBO looks up the application scope branch, finds a reference to the domainBO it created earlier and returns a direct reference to that BO (ie its now shared amongst other objects allowing other objects to change setters if context requires it).
* Note: On lookup If DomainBO does not exist in application Scope, it throws an exception (ie Application is not initialized correctly). I say this as all listeners that I use need to make sure they have the code that setsup the domainBO in the end.
** Things that erk me about this concept **
- The rest of the model assumes domainBO is configured correctly (ie dsn works, file locations are relevant or simply its been given data in the first place) I don't like assuming in some cases.
- making every single listener create a local instance of domainFacade kind of feels code intensive, in that feels like a cumbersome way to code. I'm almost inclined to simply create a baseListener and all extend that but all that's solving is lazy coding?
- Its almost as if Mach-II needs some kind of universal event object that you could extend (override events like onPostConfigLoad etc) which you could simply store objects like a domainBO/configBO for other objects to then use.. Dunno if that's holds merit but something needs to get the overall ball rolling with cfmx and its this spot where I need to store stuff like this... Application.cfm is I guess a good place as any but dunno.
- Another approach is to simply keep the domainBO/configBO separate and provide it with config.xml location (seems like double reading but sort of disassociates the listeners from being that clever..)
Your thoughts?
