Thanks Barney and Sean. That guide is great and I really appreciate how much you both have contributed to Mach-ii and this list.
Take care, Justin -----Original Message----- From: Barney Boisvert [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 14, 2003 6:00 PM To: [EMAIL PROTECTED] Subject: RE: [CFCDev] Mach-ii Managing Transactions Here's how I've done it, though I'd like to hear other's opinions just as much as you. Listeners contain all the controller logic. They take the very coarsely grained events and convert them into the set of actual business tasks that are needed to perform the action. They are the only objects that should know anything about the Mach-II framework, every other object should be framework agnostic. This means that it's the listener's job to announce all secondary events, and to pull information out of the MachII.framework.PropertyManager and pass the data to all other objects in the app. That keeps your other tiers flexible so you can (if you need to) put a different front end on the app with a minimum of fuss. Or you might even need two have two front ends on the same model at the same time. The model CFCs contain a centralized location to get all information that anyone will need from the application, and are completely divorced from the set of events the application accepts. There will very likely be multiple CFCs at this level, though that's not a requirement. I usually name them with a Manager suffix, UserManager for example. This is the place that all business objects are created (getNewUser(), getUserById(id), etc.). The business objects contain type-specific information, validation rules, and whatever else. They are the go-between for the model and the persistance layer. Since the contain validation rules, they are really part of the business-logic layer. For passing data to your views and persistance layer, you should be using lightweight DTOs, rather than the BOs. Every BO has a getDTO() method that returns a DTO containing the same instance data, but without any way to manipulate it (getters only, in other words). The BOs also will need a reference to the relevant model CFC so they can get information to enforce their business rules (such as your unique names). The persistance layer is totally up for grabs as to the implementation. I usually have a persistance object for each manager that is bound to a BO. So I'll have a UserPersister, but if I have a SecurityManager (performs authentication and authorization) I won't have a SecurityPersister, because there is no Security type. A security system is pure business logic, so it doesn't need persistance. Also, check out Sean Corfield's Mach-II dev guide. I haven't read it yet (just skimmed the first third or so), but it looks like an invaluable resource. He's got a fantastic head on his shoulders, and the ability to communicate his ideas very clearly. I know I'm going to read it in detail as soon as I get a chance. http://corfield.org/coldfusion/coding_standards/machiidevguide.html I suspect we have similar concepts (we tend to agree on OO design stuff), though he definitely goes into more detail, and probably is more easily understood as well. And, as a bonus, it is tailored to Mach-II development, which makes it doubly valuable. A lot of this is preference. There was a long discussion on here a week or two ago about different algorithms and organizations for solving the same problem, and the consensus was that the specifics are totally irrelevant as long as you have good encapsulation and abstraction in your code, be it OO or procedural. However, OO design requires a lot more planning that procedural design. On the flip side, I've found the coding of an OO app can be completed much faster than a corresponding procedural app, because you're basically just translating the app design into code, rather than actually having to build the system while you write. cheers, barneyb > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Justin Balog > Sent: Tuesday, October 14, 2003 4:05 PM > To: '[EMAIL PROTECTED]' > Subject: RE: [CFCDev] Mach-ii Managing Transactions > > > I am sure it did kept you in better shape =) I doubt any of us will be > taking time from the list to compete in next year's Olympics? > > You have opened my eyes to some neat ideas for my Mach-ii applications. I > would like to take a sec to clarify the concept of modelCFC, persistorCFC, > etc. > > modelCFC - has all the business rules(those being data validation, > etc)....what are some other types of business rules you would > forsee in the > Model? Should all the object populating methods be in that one modelCFC or > is there a better way to organize it? The ModelCFC then talks to the > persistorCFC which has all the dB calls? > > persistorCFC - has all the calls to the dB, XML, any persistent mechanism? > Again, should this all be in one cfc or is there a better way to organize > it? > > I am guessing that this is a preference choice, but just curious > how you are > doing it if you have 100ds of objects, and storedprocs? > > Thanks again Barney, > > Justin ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the word '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] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the word '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]
