Lots of great info. Hopefully by the end of this there'll be one less spaghetti coder out there.
-----Original Message----- From: Stephen Milligan [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 01, 2004 12:04 PM To: [EMAIL PROTECTED] Subject: RE: [ cf-dev ] MVC In order to get the modelling process right, it is a good idea to read up on design patterns. Some links and books below: Links: http://www.netobjectives.com/dpexplained/download/dpmatrix.pdf http://www.dofactory.com/patterns/Patterns.aspx http://www.agcs.com/supportv2/techpapers/patterns/papers/patexamples.htm Books: http://www.amazon.com/exec/obidos/tg/detail/-/0201633612/ref%3Dpd%5Fsl%5 Faw% 5Falx-jeb-6-1%5Fbook%5F2130131%5F3/104-2367846-5866322 When modelling, keep reminding yourself that each component should be doing only one thing and doing it well. If you find that you have several components that do similar related things then you might need to broaden the scope of what you mean by 'one thing'. Also, no component should use information that is not explicitly passed in. That helps reduce the coupling in the app. A lot of people will tell you that you can't learn OO by looking at code. This is true if you only look at a single code sample. If you look at 20 or 30 samples of code written by different people to do the same thing, you begin to see where the similarities and differences are and with a bit of luck begin to understand how to model your own apps. Beware of relying too heavily on this though as there is an ungodly amount of badly designed code out there. One last thing is that with object modelling, you can never get it 100% right. That is to say, there is always an alternative approach that may or may not be better than the approach you have taken and you will always have to compromise in order to get anything done. I tend to try to keep the following 3 things in mind when desigining and building apps. Reduce coupling in the app Increase cohesion in the app Ensure that the app is not more complicated than it needs to be An excellent article illustrating of the last point is here: http://www.phppatterns.com/index.php/article/articleview/103/1/1/ Spike -------------------------------------------- Stephen Milligan Code poet for hire http://www.spike.org.uk Do you cfeclipse? http://cfeclipse.tigris.org >-----Original Message----- >From: >[EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] o.uk] On Behalf Of Sam Clement >Sent: Tuesday, June 01, 2004 4:39 AM >To: [EMAIL PROTECTED] >Subject: RE: [ cf-dev ] MVC > >Thanks Spike. Any recommended books/resources? > >-----Original Message----- >From: Stephen Milligan [mailto:[EMAIL PROTECTED] >Sent: Monday, May 31, 2004 4:57 PM >To: [EMAIL PROTECTED] >Subject: RE: [ cf-dev ] MVC > > >When you run into a situation where one part of the system >appears to be >duplicating what another part of the system is doing it usually means >that you have either not chosen the names for the methods/classes well, >or you have not modelled the functionality well. In order to figure out >where things are wrong I usually boil it down to 'what is the one thing >that this component is suppposed to be doing'. > >In your case it looks like you want the model to be responsible for the >data access for the Users and the ManagerUsers component to figure out >when to call each method in the model. I would normally call the data >access component something like UserDAO and give it 4 starting methods >called createUser(), updateUser(), deleteUser() and getUser(). Those >methods may be renamed and added to later, but it's usually a safe >place to start. > >The controller component would probably have a method called >processUserForm() that would inspect the form scope and decide what >methods needed to be called in the model to provide security checking, >data validation, transfer object/bean creation etc. > >The controller is supposed to be deciding what happens in the >application, so you ought to be delegating as much of the flow control >logic as possible to it. That's why I would only have 1 entry method >for the Users CRUD operations. That method would probably call some >private methods such as >validateUserForm() and checkPermission() which would do >validation/security checking before calling the UserDAO component to do >CRUD operations as appropriate. > >Having said that, exactly how the components and methods are >designed is >very specific to the application at hand, so don't take the >above as the >gospel on 'how to do it'. > >my 2 cents > >Spike > >-------------------------------------------- >Stephen Milligan >Code poet for hire >http://www.spike.org.uk > >Do you cfeclipse? http://cfeclipse.tigris.org > > > > >>-----Original Message----- >>From: [EMAIL PROTECTED] >>[mailto:[EMAIL PROTECTED] >o.uk] On Behalf Of Sam Clement >>Sent: Monday, May 31, 2004 7:48 AM >>To: [EMAIL PROTECTED] >>Subject: [ cf-dev ] MVC >> >>I'm learning about the MVC methodology and looking for good resources >>for beginners. I've found some good stuff from Benoit Hediard (blogmx >>code) but would like some more 'theory put into practice' type stuff. >> >>Currently I'm worried about not de-coupling my controllers from the >>model layer enough. They basically seem to mirror >each other: >> >>Controller: >>ManagerUsers >>add/edit/delete user >> >>Model: >>Users >>Add/edit/delete user (maybe add authenticate/islogged/isAdmin etc.) >> >>Is it wise to break up the model layer into smaller separate >>cfcomponents or is it best to create larger cfcomponents that >>encapsulate separate business processes? I guess the skill is knowing >>which trade-offs are worth it (overly complex components vs. simple >>de-coupled components but a more complex architecture with more >>dependencies). >> >>Any help appreciated. >> >> _____ >> >>Sam Clement >>ABOVE Studios >>Boutique Design Solutions >> >>32 Clifford Street - Belmont >>Trinidad + Tobago - West Indies >>T: (868) 621 5159 W: abovestudios.com >> >> >> >> >> >> >> >>-- >>These lists are syncronised with the CFDeveloper forum at >>http://forum.cfdeveloper.co.uk/ >>Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/ >> >>CFDeveloper Sponsors and contributors:- >>*Hosting and support provided by CFMXhosting.co.uk* :: *ActivePDF >>provided by activepdf.com* >> *Forums provided by fusetalk.com* :: *ProWorkFlow >>provided by proworkflow.com* >> *Tutorials provided by helmguru.com* :: *Lists >>hosted by gradwell.com* >> >>To unsubscribe, e-mail: [EMAIL PROTECTED] >> > > >-- >These lists are syncronised with the CFDeveloper forum at >http://forum.cfdeveloper.co.uk/ >Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/ > >CFDeveloper Sponsors and contributors:- >*Hosting and support provided by CFMXhosting.co.uk* :: *ActivePDF >provided by activepdf.com* > *Forums provided by fusetalk.com* :: *ProWorkFlow provided by >proworkflow.com* > *Tutorials provided by helmguru.com* :: *Lists hosted by >gradwell.com* > >To unsubscribe, e-mail: [EMAIL PROTECTED] > > > >-- >These lists are syncronised with the CFDeveloper forum at >http://forum.cfdeveloper.co.uk/ >Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/ > >CFDeveloper Sponsors and contributors:- >*Hosting and support provided by CFMXhosting.co.uk* :: >*ActivePDF provided by activepdf.com* > *Forums provided by fusetalk.com* :: *ProWorkFlow >provided by proworkflow.com* > *Tutorials provided by helmguru.com* :: *Lists >hosted by gradwell.com* > >To unsubscribe, e-mail: [EMAIL PROTECTED] > -- These lists are syncronised with the CFDeveloper forum at http://forum.cfdeveloper.co.uk/ Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/ CFDeveloper Sponsors and contributors:- *Hosting and support provided by CFMXhosting.co.uk* :: *ActivePDF provided by activepdf.com* *Forums provided by fusetalk.com* :: *ProWorkFlow provided by proworkflow.com* *Tutorials provided by helmguru.com* :: *Lists hosted by gradwell.com* To unsubscribe, e-mail: [EMAIL PROTECTED] -- These lists are syncronised with the CFDeveloper forum at http://forum.cfdeveloper.co.uk/ Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/ CFDeveloper Sponsors and contributors:- *Hosting and support provided by CFMXhosting.co.uk* :: *ActivePDF provided by activepdf.com* *Forums provided by fusetalk.com* :: *ProWorkFlow provided by proworkflow.com* *Tutorials provided by helmguru.com* :: *Lists hosted by gradwell.com* To unsubscribe, e-mail: [EMAIL PROTECTED]
