Hi Alan, With my in-house framework, I have a lightbase.cfc that gets called and basically encapsulates everything. It starts by setting up all of the page request objects, site users, etc. It then calls the appropriate controller cfc (the controllers are injected into the lightbase singleton). The controller then makes the model calls (the service class singletons in the model are injected into the controllers that need them). I also happen to use cfc's for the view with cfincluded cfm templates so I can do things like display.maincontentarea() in my templates and it can call the injected display object - specifically it's maincontentarea(). Stylistically that works for me, but obviously it's more of a preference issue. I just like everything being wired together by the DI engine so I can skim my programatic config (for each business object, create service class and inject associated DAO, etc) and see exactly how the framework relates everything.
Best Wishes, Peter On Oct 22, 2008, at 8:17 PM, Alan Livie wrote: > @Peter, when you say 'The factory isn't specific to the model layer' > do you mean MVC in general or cf? > > In CF I tend to find my factories are always just handling the Model > object creation and DI. (I don't build display cfc's so maybe this > is why I'm thinking Model only) > > Can you explain how the Views in the cf world are involved with > factories? > > Thanks > > Alan > > ----- Original Message ---- > From: Peter Bell <[EMAIL PROTECTED]> > To: [email protected] > Sent: Wednesday, October 22, 2008 1:41:03 PM > Subject: [CFCDEV] Re: MVC seperation in OOP > > > Hi Matthew, > > Some miscellaneous comments inline below. > > Best Wishes, > Peter > > On Oct 22, 2008, at 4:57 PM, Matthew wrote: > > 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. > > The factory isn't specific to the model layer. Think of M V and C as > three different apartments in a condo. DI is like the plumbing used to > get water to all of them and between them. > > > 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. > > Yep - you could even swap from an HTML to a web service based front > end or a flex front end still using the same model (with a thin facade > for handling any controller/view peculiarities unique to that front > end). > > > 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: > > I don't know that I'd call the V and C together the UI layer. To me > the view provides the UI and the controller accepts requests from the > UI, calling the model and then (usually) passing any results from the > model call to the appropriate views(s). I suppose you *could* try to > argue the controller is part of the UI, but I don't frequently hear > things described that way. > > > 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. > > It's certainly true that these are three different "front ends" and > it's quite possible that each has a unique set of views and quite > possibly different controllers - so I guess you *could* call them > different UI's where UI = V & C. > > > 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. > > The error clearly needs to be returned to the "front end" which will > then make decisions like how and whether to display the error - or > what else to do. It can either be returned specifically - perhaps in > an error bean which may or may not be composed within the object that > threw the error, or an exception can be thrown which can then get > caught by the appropriate part of the app. Historically I've mainly > used explicit error information being returned by beans, but I think > that using error handlers is definitely a solid approach - maybe even > a better one. There are just plumbing issues to take care of to make > sure that your error handler has all of the information required, that > you can support multiple errors on the same request (e.g. a bunch of > form field validation errors), etc. I'm more familiar with returning > errors in the BO and find it easier, but I'm intrigued by throwing > errors and how it works in practice. > > > > > > > > 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 -~----------~----~----~----~------~----~------~--~---
