Sometimes people without an object-oriented programming background get confused by what ColdSpring does because it solves a problem they don't yet know they have. I'd start by throwing your objects into an application scope to get a sense of the problems that causes. Once that starts to become a problem, head on over to www.coldspringframework.org and it should make perfect sense!

If you know what an Active Record pattern is and find yourself wishing that ColdSpring was optimized for injecting dependencies into transient Business objects as well as singeltons (which it isn't), you might want to check out LightWire at http://lightwire.riaforge.org.

Understanding the Controller
The most misunderstood part of a well-designed object-oriented application is the controller. In the past our "controller" methods often did a lot of work. In a well-architected OO application, they do very little indeed. The job of a controller is to do two things. First it should take values from the URL, form, and (possibly) session scope to make well-parameterized calls to the appropriate method in the model. Second it should take the information returned by the model and pass it to the appropriate view for displaying on-screen. That's pretty much it!

Recently there have been a lot of questions about how to integrate Model-Glue and Mach-II with Flex front-ends or Web Service calls. The answer is that you don't. The Flex front-ends and Web Service calls should speak to the model directly (well, actually via a simple remote façade to handle any differences in data formatting between the model and the remote system). They shouldn't speak to your HTML controller (such as a Mach-II or Model-Glue controller) at all. If you feel you need to make your Flex applications or Web Services speak to your HTML controller because otherwise you'd have to replicate business logic, that's a perfect sign that you've put too much business logic into your controller and that you need to refactor that and put it into your model instead.

Looking at Views
The goal of a view is to display the information that the model provided to the controller along with any templates, formatting, and the like. There should be no business logic in the views (such as calculating prices or deciding what value to display based on business rules). The view should never include a cfquery that runs against a database (a query of queries for sorting or ordering a recordset may sometimes make sense).

Other than the general rules above, there aren't well-accepted patterns in the ColdFusion community for handling view issues like skinning, view composition (so you can reuse parts of your views on multiple pages), and view helpers (to provide a separation of concerns by removing any programming logic from your templates so designers can safely edit the templates without breaking view-specific code like alternating row tables or "records per page" display logic). However, there are many approaches being explored so it's well worth looking at them.

Conclusion
Using cfcs for your application can make complex applications much more maintainable, but there's a substantial learning curve. Wherever possible, start with small test applications and then as you get more confident using the patterns you'll find your development speed increasing. If you have to start with an existing system, solve one problem at a time. Pull your data access logic into DAOs. Then start to add a service layer and remove business logic from your views and controllers one at a time. The trick? Lots of little steps!