In a recent project I worked on I created a "fileAccess" object.  This object was responsible for very few things.  Creating files, reading them, updating them, etc.. Basically CRUD operations on a file.  It was generic and basically just served as a wrapper to the cffile operations except that it was also responsible for creating locks, and making sure files ended up in the correct location within the application structure (a specific storage directory and it's subdirectories). So it took care of some of the management overhead.

However, this was because I have to deal with a large number of different files.  If I was only dealing with one or two files I probably wouldnt' have abstracted out that far until I needed to (additional file(s) and operations were required).  I don't know your problem domain well enough.

However, if you do follow the path of having some form of object that deals with file access I think you can view it as your "database driver" your database just happens to be a bunch of plain text xml files.  Then your DAO would get the full chunk of data back from the requested file and it would be responsible for filtering/updating the data etc to either pass back to your calling object or to the fileAccess object to be rewritten/deleted what have you.

In the end I would Keep It Simple and decide which usage scenario best fits your applications requirements.  If I have a few XML files to deal with then I probably wouldn't add the extra layer yet; at least not until I need it.  That is what refactorings for right





----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] 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/[email protected]

Reply via email to