Yip. I think you're on the right track. All looks good. Alan
----- Original Message ---- From: Matthew <[EMAIL PROTECTED]> To: CFCDev <[email protected]> Sent: Wednesday, October 22, 2008 5:15:07 AM Subject: [CFCDEV] Re: Message managment in OO programming Hello again everyone, After doing lots more reading I've formed the following picture in my head and would appreciate hearing if people agree: 1. Your application's business logic should be seperate and could contain your BEANS / DAO / SERVICE LAYER / FACTORY. This means the "M" in MVC should have no dependence on the "V" or "C" allowing it to be as reusable as possible (e.g. you could swap from one framework to another and only need to touch the "V" and "C" bits. 2. The "V" and "C" (which could be called the UI layer as per Barney's comments) should talk to the business logic (the "M") via the service layer (top layer in "M"). This would mean that your business unit as a whole can be consumed from various UI layers. Examples of UI layers: a. HTML views with some sort of controller architecture (perhaps Mach- II, Fusebox or a custom controller etc). b. FLEX would have it's own way of plugging into your business layer (not to sure how but in principle the Flex app you built would be the "V" and "C"). c. You may build a WEB-SERVICE layer (which would be a UI layer) - allowing remote users to utilise your application. Hence the views would be XML. So if I'm on the right track here than it makes sense to me to go with the concept of returning some sort of item (array, struct, object) from your business objects / layer which encapsulates any errors caused within the business layer process. Therefore the responsibility is on the UI layer to deal with the validation error / exception / message as it sees fit e.g. the HTML scenario would probably just show the error message on screen, the WEB-SERVICE scenario would include the errors in the packet (perhaps you'd want to wrap up some errors into CODES which the web-service consumer could detect and deal with in their own way), and FLEX would do a different thing with the errors. Am I on the right track (makes sense to me)? @Baz, Thanks for identifying those posts. I've just spent the last few hours reading through them and spidering off into various other articles. Cheers Matthew On Oct 22, 2:20 am, Baz <[EMAIL PROTECTED]> wrote: > Hey Matt, there are a couple of good threads that might help you. One titled > "[CFCDEV] Service Layer X OO Architecture" discusses the problem of passing > back both messages and an object. Another thread titled "[CFCDEV] Using > object "getters" after form validation fails" talks about having invalid > data - specifically with a User object. > What I do is this: > > <cfscript> > var User=getUserService().newUser(); > User.setMemento(form); > User.validate(Username,Password); > </cfscript> > > <!--- if there are no validation errors, load user using username and > password ---> > <cfif not User.hasValidationErrors()> > <cfset User.loadFromLogin() /> > <cfelse> > <cfset getSystemMessages().appendErrors(User.getValidationErrors()) /> > </cfif> > > <!--- pass back system messages (even if it is empty the view will know what > to do) and user object (so that I can repopulate the form with the bad data) > ---> > <cfset arguments.event.setValue('SystemMessages', getSystemMessages()) /> > <cfset arguments.event.setValue('User', User) /> > > The validator and DAO and whatever else is neatly composed within the User > object. The controller and service do very little leaving the hard work to > the User object. That way the domain model is NOT anemic (rich?). > > Thats just what I do. There are a million good ways to go about it - each > with its own benefits and constraints. > > Good luck. > Baz --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
