On Thursday, Jul 17, 2003, at 17:02 US/Pacific, Mike Mertsock wrote: > With an MVC approach (FB4 and FuseQ are very friendly to MVC), it may > make a lot of sense to instead have particular developers working on > fuseactions in one particular circuit, for example, a "model" circuit > devoted to shopping-cart transactions. A well-designed and > well-documented application would allow the developer with the most > database/etc. knowledge to work purely on shopping cart "model" > fuseactions, while other developers may work on view and controller > fuseactions that all come together to create one page.
Agreed. Our team usually splits work up according to skill sets so that one developer might build the model behind an application while another developer builds the view and another builds the controller. A good example on macromedia.com is the membership system: one developer was responsible for the CFCs that model the underlying database entities and transactional elements; another developer built the controller facade CFC layer (actually multiple CFCs that extend a base CFC); yet another developer wrote the HTML (CF) view; a fourth developer write the Flash view. See: http://www.macromedia.com/special/under_the_hood/report1/#coldfusion- flash MVC is very amenable to this sort of workload distribution. FB4 is MVC-friendly, Mach II is specifically an MVC framework and even in FB3, the display / action / query fuses could easily be handed out to different developers. I think this may be why a lot of one-man shops find FB to be an unnecessary overhead: it is a framework that allows easy distribute of work 'parcels'. > I know FB4 and FuseQ are not equivalent to MVC, the formers are > architectures and the latter is a design methodology. Hmm, FB4 and FuseQ are frameworks, not architectures. MVC is a design pattern, not a methodology. Frameworks are often implementations of architectures, e.g., Mach II is an implementation of implicit invocation (an event-based architecture). Benoit's MVCF is a methodology based on the MVC design pattern. > But FB4 intrinsically encourages structured design methodologies such > as MVC, so MVC happened to provide a good context for explaining my 2 > cents. I actually think that's a bit of a strong claim and somewhat unsubstantiated: developers can still (very easily) create terrible code using a framework unless they are *also* following good design practices. I'm sure people will write terrible applications using FB4 just as people have written terrible applications with other frameworks and without frameworks. People can even create terrible MVC-based applications. A good framework provides structure and structure removes some of the degrees of freedom that allow developers to write bad code. Poor developers will continue to write poor applications, regardless of their framework, until they learn about good design and understand it and start to practice it. Sean A Corfield -- http://www.corfield.org/blog/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
