@Barry, so it sounds like you are saying that if you had a business layer and decided to add a FLEX UI layer you'd have to first create a "facade" which would be the communication between FLEX and the business layer... that makes sense.
Anyone else willing to comment on the concept of "MVC seperation in CF OOP". Here is the question again: ---------------------------------- 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)? ------------------------------- Cheers Matthew On Oct 22, 5:37 pm, "Barry Beattie" <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
