Hey Andrew, As far as the Hotel goes, if the Hotel "has" floors, offices, lounges, etc., that'd make them candidates for a composition relationship - much different than extends / inheritance. Composition is commonly called a "has-a" relationship, as opposed to inheritance, which is usually called "is-a". A Hotel has-a office, but you can't say an office is-a hotel. An office object could then be reused...a Hotel can has-a office, and so can JimmysUsedCarLot.
BO, DAO, MVC (and tons of other design patterns) are primarily vocabulary terms that provide common language to describe ways of doing things. I've learned (by shooting myself in my foot. err, feet. repeatedly.) that they're best understood/used once you understand the motivation for using them. Each exists for a different reason, and understanding that reason can be the hardest part! So, applying them to the example of an "employer," we could probably postulate that we want to do certain things: hold an employer's data in some sort of object, display/edit an employers's data (say, CompanyName and EIN [employer identification number in US tax parlance). Read/Write this data to a database. List a bunch of them. That's a bunch of different things to do: display UI, validate data, access a database, encapsulate business logic, etc. Personally, I fall on the "cohesive" side of the design fence, so _wouldn't_ put "everything related" to an Employer in the Employer.cfc. It's quite likely that some of the "related" things would change, and I'd like to keep the impact of the change to a minimum. Getting back to our problems, I'd probably address them as follows: 1. "Hold an employer's data in some sort of object" It may be a BO with a good deal of logic, or a simple Bean with nothing but properties and getters/setters, but we'll create something called Employer.cfc that encapsulates the properties and logic for an Employer. 2. "Read/Write this data to a database." This is where DAO can be handy. I'd probably create an EmployerDAO.cfc with methods like Create(), Read(), Update(), and Delete() that (respectively) insert a new employer using an instance of Employer.cfc, read an employer based on EmployerID, update based on an instance of Employer.cfc, and Delete based on EmployerID. Your implementation may vary, there's no right answer. 3. "List a bunch of them" Because [my implementation of] DAO is concerned with single-instance access, I use the Gateway pattern to handle multiple instance access. I'd create something like EmployerGateway.cfc with methods like Read(), ReadByEmployerId(), ReadByEIN(), all returning whatever queries I'm going to need in my application. [Intermission] Ok, so we've got a way to hold an Employer, Read/Write an employer, and get lists of employers. Now we need something that'll actually _use_ these CFCs to do something meaningful. I think this is one of the biggest hurdles CF developers face, and it's why I've written an article on MVC for CFDJ (see April 2005 issue) and the Model-Glue framework. MVC is just one way to do this (behavior partitioning), but it's probably the most popular I know of, next to MVP (Model View Presenter). MVC solves a basic problem: You've got this great set of CFCs for doing things (your Model), and you don't want to tangle their logic and function calls in with your great set of CFMs for displaying things (your View). MVC introduces a "Controller" in between the two that "glues" them together. (Aside: See, Model-Glue is a very nerdy pun, because the framework exists just to help you glue your Model to your View via Controllers.) Getting around to the end of your post: > I have read many articles on MVC so I understand that, but I am just trying > to get to grips how you guys/gals have separated business logic and dao. The > problem I have found is that there is many frameworks, but no real > discussion on how to separate the logic, and data objects. Well, I seperate business logic and dao by putting them in different files. Not meaning to sound like a smartass - just giving a low level, real world answer to a high level question. My business logic all lives in BOs, beans, and services. Data access just happens when I need to save (persist) something or recall something that's previously been saved, and it lives inside of DAOs and (Data) Gateways (DGs). How you choose to have them "play" together is up to you and your needs - sometimes I'll have my Controller directly take a BO and hand it to a DAO for persistence, and at other times, I may want to have a Manager in between the two. I think the best thing to do is to go ahead and take a shot at designing and implementing small-scale prototypes. Sometimes it's hard to see the need for things like MVC until you shoot yourself in the foot a few times - when something smells bad, take a look at your design, and see what can be refactored. Like S. Corfield says, "This stuff is hard." -- Get Glued! The Model-Glue ColdFusion Framework http://www.model-glue.com ---------------------------------------------------------- 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]
