Hey Scott 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 ?
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 ? do you think that you might need some kind of auto-code generator to build you BO's each time ? what about composite objects. how would your concept handle this case ? Pat On Mon, 10 Jan 2005 13:00:35 +1100, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Hi, > > I've got a concept I want to float past you all, and would appreciate some > feedback on it. > > Files: > ----------------------------------------------------------------------------- > // Core Objects (abstract from both Model / Mach-II) > > com.core.configBO > > // Mach-II Objects > com.listeners.appListener > com.listeners.blogListener > > // Blog Services / Factories > > com.model.blog.blogService > > com.model.blog.DLAbstractFactory > com.model.blog.DLFactory_SQL > > // Entities > com.model.blog.entries.entryBO > com.model.blog.entries.sql.entryDAO > com.model.blog.entries.sql.entryDG > > com.model.blog.comments.commentBO > com.model.blog.comments.sql.commentDAO > com.model.blog.comments.sql.commentDG > > > Initalization Procedure > ----------------------------------------------------------------------------- > - Mach-II Initializes itself. > > - com.listeners.appListener.configure(); > - appListener creates var configBO > - appListener invokes getProperties(), reads the config XML and > populates configBO with various "config" properties (ie DSN, FileLoc etc) > - appListener stores this configBO inside the mach-ii "setProperty" > for other listeners to use.. > > - com.listeners.blogListener.configure(); > - blogListener creates instance of com.model.blog.blogService and passes > in configBO via getProperty() > - blogService.init() creates DLAbstractFactory and defines its type > as "SQL" (or whatever was set via config.XML) > - DLAbstractFactory creates local instance DLFactory_SQL which > has methods like (getEntryDAO, getCommentsDG etc) > > > Example "createEntry" Procedure > ----------------------------------------------------------------------------- > - Form is submitted via VIEW, with event=admin.createEntry > - com.listeners.blogListener.createEntry() is invoked (based on > event-handler notify concept) > - blogListener creates local var of com.model.blog.entries.entryBO and > populates it based on form collection / arguments > - blogListener invokes > blogService.saveEntry(com.model.blog.entries.entryBO) > - blogService.saveEntry then validates() to make sure BO information > is valid (if invalid throw exception) > - blogService.saveEntry then invokes > blogService.DLAbstractFactory.getEntryDAO().save(entryBO) > - com.model.blog.entries.sql.entryDAO.save() is invoked, it does > a DB check to see if data is new or old, if new insert else update. > > - this request is then closed and onto next event/procedures etc.. > > > > Summary > ----------------------------------------------------------------------------- > I've tried to keep the Listener as light as possible and deligate business > logic to the "services", allowing multiple listeners to use the one said > service (ie i probably should put blogService inside "setProperty" creating > a single version of it inside memory cache). > > I figure the Listeners are Mach-II aware and event context aware, so they > are better suited to break apart the form scope for various data, and > then pass this data via setters into relevant Business Objects (I'm straying > away from the word "bean" here). Which simply carry out a setXXX routines. > > Once they syntatically get set (ie they've passet the setter concept without > exceptions), that BO is then passed into the "service", which then validates > it or does whatever it wants to it before saving. Once thats completed and > aok, it then begins a typical DAO concept, find the relevant DAO object, > initiated a "create/update/save" sequence and that goes into its own > lifecycle. > > I should note, that the ConfigBO is the weak link, if its not initialized > properly or changes, the rest of the model needs to be aware of this. I > prefer this concept mainly due to the "Data Layer aka Persist Layer" can > either be XML or SQL - furthemore some hosting providers require CFQUERY to > have username/password attributes - while others may not... so i needed a > universal object that can either provide DSN information or Directory > Locations... > > Ontop of that i figure it could even have other generic "configuration" > settings aswell (File Upload locations etc). So the Object still sort of > becomes re-usable and abstract from whatever application you are developing > in (ie its not Mach-II aware or Application specific). > > > Any thoughts / suggestions / code refactoring needed, please reply as i'm > keen to implement this concept officially (i have prototype / working > application) just at a final "heres what i have basically, whadda ya think > > > > > > Regards, > > > -------------------------------------------------- > > Scott Barnes > > System Development Engineer > > > > Goro Nickel Project > Level 8, 201 Charlotte Street > Brisbane QLD 4000 > Email: [EMAIL PROTECTED] > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
