wouldn't Flex be connecting to a facade? an abstraction layer that would act as a front door and not to the business layer directly? that's the "view" that would translate the exception to something meaningful for Flex. the SWF is just a view type: IMHO controller and model shouldn't care too hoots about what type of view is being used.
but hey, that's how I do it - works for me. On Wed, Oct 22, 2008 at 4:26 PM, Matthew <[EMAIL PROTECTED]> wrote: > > One other comment: if this is correct than the idea of "throwing an > exception deep down in the business layer and leaving it to bubble up > to the view/controller to deal with it" doesn't make sense because how > would FLEX deal with this? > > Cheers > Matthew > > On Oct 22, 4:33 pm, Alan Livie <[EMAIL PROTECTED]> wrote: >> 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 -~----------~----~----~----~------~----~------~--~---
