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 -~----------~----~----~----~------~----~------~--~---
