Title: Message
Hello All,
 
Just want to make sure that after reading all the books, I'm actually doing something sensible with my code . . . .
 
Lets say I have an entity (in this case "Page"). I have the Page class, PageDAO for abstracting persistence and PageService for wrapping all general page services (I'm including Gateway within DAO in this particular case). PageDAO is only ever called by PageService.
 
Now imagine there are few enough pages that it makes sense to lazy load them into memory.
 
Right now I have a PageService.getPagebyFilePath() which returns a Page object for the appropriate page (filepath is the unique page key available at runtime to the controller)
 
It does an:
   if(not isDefined("THIS.page.#Arguments.FilePath#"))
    {
    Local.TempPage = createObject("component","prototype.entity.systemsforge.Page").init();
    THIS.page[#Arguments.FilePath#] = Application.PageDAO.LoadPage(Local.TempPage,"#Arguments.FilePath#");};
so if the page doesn't exist in the PageService's THIS scope (the service is application scoped), it creates the page and then calls the DAO to load data into it.
 
Originally my code called the DAO which created the object and loaded it, but then I though "why should a DAO know how to create a page - it should only know how to load it"
Then I tried putting the call to the DAO into the init script of the Page object itself, but then I asked myself the question: why would a page know where it's data was and hence where to load from.
So I ended up putting the DAO call into the Service which is responsible for orchestrating pages within the framework and therefore might well be expected to know both how to create a Page and how to load data into it.
 
Does this make sense? Am I going vaguely in the right direction with this? Any potholes in the road ahead I should be looking out for?!
 
Any input much appreciated!
 
Best Wishes,
Peter
 
Please note that I'm effectively using the PageService as a factory for returning Pages (and taking care of lazy loading/caching) as it didn't seem to be enough extra work to bother with a separate PageFactory class.
 
 
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).

An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org

Reply via email to