Framework

Well I've finally read thru Sean Corfield's framework comparison post, presentation and have decided to dive into the CF framework world with Model-Glue. My background includes some VB.NET windows application development & I'd like to hear from anyone willing to post. Whether you're using Model-Glue or not, and what you like about the framework you are using - as well as what you don't like. I know this has been beaten to death but we all know that once we decide to learn something new we have to ask for ourselves. TIA, Donna

From my investigations, MG-Unity is a very good choice for the OO style framework. It combines MG, Coldspring and Reactor and the way each of these does things makes a lot of sense. > Well I've finally read thru Sean Corfield's framework comparison post, presentation and have decided to dive into the CF framework world with Model-Glue. My background includes some VB.NET windows application development & I'd like to hear from anyone willing to post. > > Whether you're using Model-Glue or not, and what you like about the framework you are using - as well as what you don't like. > > I know this has been beaten to death but we all know that once we decide to learn something new we have to ask for ourselves. -- CFAJAX docs and other useful articles: http://www.bifrost.com.au/blog/

I'm liking MG:U too.  Seems to be pretty sense-icle.  Reactor really made sense to me, I started using it before I went the MG route, but found that I really liked alot of the stuff MG brought to the table. Now my main concern is modeling the stuff right, making the right bits and pieces an object or whatever.  Seems to be the hardest part anyways, no matter what route you take. I'm tempted to put a lot of the stuff in my Reactor objects, which I don't think is quite OO enough, but stems from using it first, and the fact that with Reactor alone you've got a pretty good framework to do stuff. I'm still rolling frameworks around in my mind, in general, but I do like many of the concepts... mostly the idea of strangers being able to work on some code, but it turns out that you can have spaghetti code with frameworks too.  Oh No!!!!! :-) Good stuff though, and nice to know how to work within 'em, no doubt. ----- Excess quoted text cut - see Original Post for more -----

Mach-II and Model-Glue are both Implicit Invocation architectures. Having played with both extensively (with projects in both) I personally like Model-Glue, especially Unity. I recently did a small contract job, a football pool application that a local mortgage broker wanted to run for his friends and his clients. 8 to ten screens in all, including administration, 4 database tables with a lot of relationships, and a tight deadline. It took me longer to figure a few things out (with reactor) than it did to write the actual application, but I was approaching it as a paid learning experience from the start. All in all it took a little over four hours of work, mostly in my event, scaffold, and reactor object definitions, and a small bit of stylesheet work and modifications to auto generated templates (plus three or four custom methods within the controller and gateway CFCs). From a project architecture point of view it definitely forces you to plan out your applications in advance, but also provides enough flexibility to accommodate changes. Having the framework build an extendable processing foundation for you (all of your db CRUD, plus views/events for them) saves a lot of time (and saves more if you only turn on debug when you need it.) I really enjoy it, and will definitely continue using it. Cutter ____________ http://blog.cutterscrossing.com Donna French wrote: ----- Excess quoted text cut - see Original Post for more -----

<shameless plug> Let's not forget that MG:U has the ability to take adapters from other ORMs, so you aren't tied into using Reactor if you don't want to be... And look at that, an ORM Adapter for Transfer is totally being worked on right now... </shameless plug> (sorry.. I hate doing that sorta stuff.. but I just couldn't resist) Mark ----- Excess quoted text cut - see Original Post for more ----- -- E: mark.mandel@gmail.com W: www.compoundtheory.com

I'll throw in another vote for MG:Unity. I've built applications using Mach-II, and Model-Glue seems cleaner and easier. But that's just me ... Either works well for application building. I will say that MG makes it so simple to separate pieces of your presentation that I'm currently using it for what is essentially a static site, just to keep the pieces of layout and content discrete. -- Thanks, Tom Tom McNeer MediumCool http://www.mediumcool.com 1735 Johnson Road NE Atlanta, GA 30306 404.589.0560

I'm wondering if anyone can make any recommendations on a good book on Model Glue, as well as some of the other popular frameworks.  I've never worked with any of them and I'm thinking about taking the plunge. On 9/13/06 9:19 AM, "Tom McNeer" <tmcneer@gmail.com> wrote: ----- Excess quoted text cut - see Original Post for more -----

I'd also like to know... books or online resources. I'm wondering if anyone can make any recommendations on a good book on Model Glue, as well as some of the other popular frameworks.  I've never worked with any of them and I'm thinking about taking the plunge.

> I'd also like to know... books or online resources. No books yet. Online stuff only. Sample apps seem to be more plentiful than anything. Depending on your background, the trickiest part of either MG or Mach II will be the OO side of it. Learning how to structure the backend side (i.e., model) will take some trial and error. The sample apps are good for this. Any official documentation is on the respective websites for Model Glue (http://model-glue.com/) and Mach II (http://www.mach-ii.com/). Docs are also included in the download. Join the lists for each if you have questions and to follow developments. Sean Corfield has sample apps in both. So does Brian Kotek. Matt Woodward and Peter Farrell are the guys for Mach II. Go to their blogs and filter by category. Also see MachBlog.org for full blown blog built in MachII. Probably the best tutorial to get you going in Model Glue is Raymond Camden's. This is a pre-Unity tutorial, but I would actually recommend first learning the pre-Unity version. That way you are focused only on the MG framework. Then learn ColdSpring and Reactor. Then see how Joe Rinehart took the three and created Unity. FYI - Mach II also plays well with ColdSpring and Reactor. The Mach II guys have decided not to incorporate those directly into that framework, but to do so yourself is quite easy. Brian has his sample bookstore app in this. I can't remember if Sean did M2/CS/Reactor or not. Rob Gonda has AJAX examples in both MG and M2 Use google to search on names mentioned -- Matt Williams "It's the question that drives us."

If I may take a brief break from the admittedly well-deserved praise for MG:U and discuss why I am choosing not to use it. I was using MG 1.1 but I have decided to switch to Mach ii because I, personally, am not fond of the integrated MG:U/Reactor. I know you can use MG without Reactor, but that doesn't seem to be the focus of it (and I know I have seen posts mentioning that Reactor can impact your load times unless you specifically disable it in MG:U). I have on my blog expressed my dislike of three things that you need to consider when choosing MG:U (some of which specifically relate to the Reactor integration). One is the active record pattern, which Reactor uses. I think the active record pattern reduces the flexibility of your application - I always use the example that if you decide that Reactor is too much of a drag on your site's performance, you will have a hell of a time ripping it out or trying to recreate aspects of it. I also am not fond of scaffolds, as I think in most cases they aren't very useful - however they are totally optional I suppose so I am not going to make a big fuss about them. Lastly, I just don't think Reactor is there yet. It is a great concept that Doug has put a lot of work into, but it seems to me that enormous scope and complexity has caused it to be error plagued. I am on the list and I often feel inundated with Reactor issues. Personally, I have chosen to move to Mach ii. I believe it is a solid framework and isn't all that different from straight MG (i.e. like the 1.1days) - mostly some verb changes. I like that it wants to be a solid framework and only that. If you want added functionality, there are a number of plugins available from the community (and some pre-packaged but not pre-loaded). I am also finding it is not as complex as it is portrayed - I compare it to driving stick while MG:U is automatic. I prefer stick...I like the fine tuned control it gives you. Anyway, as this post is full of MG:U fans, I am not ripping on MG:U or trying to start some framework flame war. I just think that you need to get past the hype a bit when choosing a framework. This may mean that you still choose MG:U, but it is worth considering the alternatives (Mach ii, Fusebox and ColdBox). -- - Brian Rinaldi blog - http://www.remotesynthesis.com/blog CF Open Source List - http://www.remotesynthesis.com/cfopensourcelist Boston CFUG - http://www.bostoncfug.org

To add my 2c, Denny, Reactor isn't really a framework. It is a way to automate the persistence of objects. In OO programming, you often create DAOs and Gateways (data access objects and table data gateways) to abstract your database access code for single records and recordsets. Firstly, I have some issues with the idea of Gateays returning queries, but that is neither here nor there. Reactor just auto creates those. You probably want to create a set of service objects (one per object - singletons created using a factory or ColdSpring if you want to be fancy!) for doing all of the business logic and the business objects themselves will often have logic (Product.getPrice() may calculate price based on your discounts or whatever). Then you need a controller which you can write yourself or use Model Glue (classic - not Unity!)  or Mach -II for. If you are only getting started with OO, I'd thorough recommend checkout out all of the great blog postings on OO programming and would start there. I think it's quite a leap from procedural CF straight to MG Unity, and if yu had to jump straight to a framework, I'd consider mach-ii or Model Glue without Reactor and ColdSpring. ColdSpring solves a real probvlem, but have the problem first and then enjoy the relief i provides. Reactor also speeds development, but I don't think you'll fully understand the trade offs until you've written a few DAOs and agonized over where to put the code for joined objects (how you you get all of the Users in a Company - CompanyService.getUsers()? and if so, what DAO does it call - CompanyDAO or UserDAO). Once you've played with that for a while, you'll be able to choose between Reactor, Transfer (which is looking very interesting - Mark keep up the great work and the shameless plugs!), cfhibernate, or rolling your own ORM. Best Wishes, Peter

>I know you can use MG without Reactor, but that >doesn't seem to be the focus of it I think it's a bit short-sighted to drop MG just because it has added some optional components you don't like... If you don't have Reactor installed, MG starts up without it and scaffolding and GDMs (Generic Data Messages) are simply disabled. No big issue. You get Model-Glue 1.1 compatibility with the added option of using ColdSpring for configuration. The only difference is that ColdSpring is required to run MG:U - but you, yourself, don't have to use it. >One is the active record pattern, which Reactor uses. I think the active >record pattern reduces the flexibility of your application I agree to some extent. However, I have built some apps where I have a data tier that hides the Active Record pattern and that works well, decoupling the business model from the persistence tier (which is a good practice anyway). > I always use >the example that if you decide that Reactor is too much of a drag on your >site's performance, you will have a hell of a time ripping it out or trying >to recreate aspects of it. Not if you've designed your application properly. I just switched most of my persistence layer from Reactor to Transfer with very few code changes. My business tier dealt with beans (which Active Records are) and my data tier dealt with persistence so the changes were fairly localized. I even have a prototype TransferAdapter for MG:U so I actually have basic scaffolding and all the GDM machinery working with Transfer (with the exception of the gatewayMethod extension to MG:U that was added recently). >I also am not fond of scaffolds, as I think in >most cases they aren't very useful - however they are totally optional I >suppose so I am not going to make a big fuss about them. I've found them useful for quick'n'dirty prototypes and then I typically fold the Scaffolds.xml file into the main ModelGlue.xml file and copy the generated views into my main view directory and work from there. It saves me writing some otherwise tedious event handling logic and basic display / list / edit form stuff. >Lastly, I just >don't think Reactor is there yet. Since it's only at a beta candidate, I think that's only to be expected. Transfer is a 0.5 version release. MG:U itself is only a beta product. ColdSpring is the only 1.0 portion of it. If using pre-release software is an issue, then definitely MG 1.1 and ColdSpring 1.0 is a great, solid combination. However, since Reactor is totally optional for MG:U, I don't think this should be a reason to abandon Model-Glue. >It is a great concept that Doug has put a >lot of work into, but it seems to me that enormous scope and complexity has >caused it to be error plagued. I am on the list and I often feel inundated >with Reactor issues. ORMs *are* complex. Look at Hibernate. I think the volume of traffic on the Reactor list is a testament to just how many people are using it for real projects. And, for the most part, they are actually *succeeding* with Reactor. >Personally, I have chosen to move to Mach ii. I believe it is a solid >framework and isn't all that different from straight MG (i.e. like the >1.1days) - mostly some verb changes. I think there are some really problematic constructs in Mach II that make it harder for people to learn than MG 1.1 but I will also agree that it is a very solid framework. I introduced it to macromedia.com and it now powers about a quarter of the applications on the site (now adobe.com). I switched to MG 1.x to take advantage of ChiliBeans initially because ColdSpring did not seem approachable. Then I went to MG 1.x + ColdSpring. Whilst I could have then moved to Mach II + ColdSpring via the plugin, I found that I didn't like the complexities of the Mach II architecture (listeners *and* filters *and* plugins) compared to the simplicity and consistency of the Model-Glue architecture. I also no longer like the way that Mach II allows you to intermix calls to the model with view rendering and invocations of filters etc... I think it leads to messy event handlers. I also no longer like the way that listener methods are tied directly into the event handlers - Model-Glue's implicit invocation is much cleaner with multiple listeners registered for a given message broadcast. >Anyway, as this post is full of MG:U fans, I am not ripping on MG:U or >trying to start some framework flame war. I just think that you need to get >past the hype a bit when choosing a framework. This may mean that you still >choose MG:U, but it is worth considering the alternatives (Mach ii, Fusebox >and ColdBox). Again, agreed. I don't know much about ColdBox (reading the initial blurb about it just confused me so I put it down - if I find time, I'll definitely go back and look at it again). Fusebox is a good framework for established CFers who aren't yet familiar with frameworks but may be a bit alien for someone coming to CF from VB.NET (which I seem to recall the original poster was?). Fusebox lets you write procedural code if you want, with or without the MVC pattern. Or you can do full OO development with it if you want. If you're comfortable with OO and used to any sort of event-based programming, jumping into either Mach II or Model-Glue should be pretty straightforward. Mach II's documentation is a bit more Java-centric (Mach II was originally designed and built by a long-time Java developer for whom Mach II was close to his first CF project; Model-Glue was designed and built by a long-time CF developer). Only Fusebox has books available - it's the oldest (and most downloaded?) framework for CF and has a lot of deployed production sites. However, the shift from Fusebox 3 to Fusebox 4 was a big change in some ways (the basic concepts didn't change but the application flow changed from CFML to XML - making FB4 more like the other two frameworks here than its predecessor). Fusebox 5 is backward compatible with Fusebox 4 but adds more support for CFCs and expands the expressive power of the XML grammar (Fusebox's equivalent to the event handler specifications in MG and M2). As a final data point, my new group at Adobe is building ColdFusion applications using ColdSpring primarily (we're building mostly back end systems to support Flex applications) but also Model-Glue: Unity (for administrative consoles) and a mix of Reactor and Transfer (for persistence). And of course we're relying very heavily on cfcUnit for all our unit testing! Sean Corfield (these days a very occasional contributor to cf-talk due to workload!)

Sean, I actually think you and I are in agreement on many points here. > I think it's a bit short-sighted to drop MG just because it has added some optional components you don't like... I didn't exactly drop MG because of these optional components. I did drop Reactor because of some of the things I mentioned below...and yes, I know its still beta, but it is packaged with MG:U which itself is still in beta and which was being recommended in the prior posts...so while I am not criticizing the errors per se, I do think is fair to warn someone considering adopting MG:U with Reactor. The decision to include Reactor caused me to consider the direction MG was headed and to consider other frameworks (which isn't bad anyway). In the end I chose Mach-ii because I was more comfortable with the way it worked and not because of anything else. This is not to say it is better or worse than any other framework...as you know, I advocate people choosing a framework, any framework...as you say, if you do it right, you can generally change without too much difficulty. That being said, maintaining the level of abstraction that you have set up to remove the dependency on the active record pattern that Reactor uses isn't an easy task for a framework and OO noob is it? I want to emphasize, I am not asking anyone to abandon MG:U because of Reactor. However, the praise heaped on it has a lot to do with the Reactor integration and scaffolds and such. MG 1.1 is not for building blog applications in 9 minutes. I would agree that Model-Glue is easier to learn that Mach ii, which is probably why I chose to go the MG route first. However, before I was able ot properly do MG even, I had to take a step back and learn how to code OO - by hand. I actually tried the MG/Reactor/CodlSpring route before it was all integrated and before I understood OO. Big mistake. It led me into a lot of problems that were not the fault of any of the frameworks but more the fault of my own misunderstanding and ignorance about the problems they are intended to solve. > ORMs *are* complex. Look at Hibernate. I think the volume of traffic on the Reactor list is a testament to just how many people are > using it for real projects. And, for the most part, they are actually *succeeding* with Reactor. I am also not saying that Reactor is not succeeding. I have just chosen, for the moment, not to use it. I also think the general hype over Reactor glosses over the complexity of an ORM that you yourself mention. Its being sold like a Ginsu knife that can cut through tin cans. People are buying it without asking why they need a knife that can cut through tin cans or whether having one will make life any easier. I think the level of activity on the list shows this too - that you use this knife when it is appropriate or risk cutting yourself (to expand on my useless analogy). By this I mean, you can get yourself totally in bed with Reactor before you realize it isn't always that easy to use and has a steep learning curve. In many ways it resembles CF as a whole. CF is deceptively easy to do simple things which tends to hide the complexity of the language as a whole. -- - Brian Rinaldi blog - http://www.remotesynthesis.com/blog CF Open Source List - http://www.remotesynthesis.com/cfopensourcelist Boston CFUG - http://www.bostoncfug.org

>I actually think you and I are in agreement on many points here. Very likely :) >I didn't exactly drop MG because of these optional components. I did drop >Reactor because of some of the things I mentioned below... OK, thanx for the clarification. >The decision to include Reactor caused me to consider the direction MG was Yeah, I actually think including a Reactor distro in the MG:U beta was a mistake and gave the wrong signals - especially since the MG:U distro did *not* include ColdSpring! Nowadays, folks are pulling both Reactor and MG:U separately from the SVN repos - one of the pros or cons of pre-release software with a public SVN repo (pro or con, depending on your point of view). What I do with my team is to pull updated releases, re-test everything and then merge the latest builds into our own repo (under Perforce) because we have some fixes there which haven't made it to the trunks under SVN yet. It's a complex process and not recommended for anyone who isn't familiar with source code control and working with open source projects! To be honest, if someone is relatively new to all this stuff then they need to stick to official downloads and that means: - Fusebox 5 (or Fusebox 4.1 or 4.0 or 3 - all are available as official downloads) - Mach II 1.1.0 (1.1.1 is not official yet - FYI, adobe.com is running 1.0.10 as far as I know but have 1.1.0 in the lab for testing) - Model-Glue 1.1 - ColdSpring 1.0 As for stable ORMs, objectBreeze is the only one to reach a 1.0 milestone so far (and I have some pretty strong reservations about its APIs). I don't know if Nic Tunney is on the list and wants to comment on how widely downloaded objectBreeze is? My sense is that Reactor is far and away the most popular ORM, followed by Transfer and then objectBreeze. >That being said, maintaining the level of >abstraction that you have set up to remove the dependency on the active >record pattern that Reactor uses isn't an easy task for a framework and OO >noob is it? Oh, I completely agree! Learning OO is pretty hard because it's really a way of thinking rather than just some fixed set of steps to follow. Getting really good at OO takes years and it's only when it becomes second-nature that you can expect to blithely switch frameworks and components with relatively little impact. The payback is worth the effort but don't be discouraged by how hard it seems and how often you fail or paint yourself into a corner while you're learning! >However, the praise heaped on it has a lot to do with the Reactor >integration and scaffolds and such. It's definitely a double-edged sword... >MG 1.1 is not for building blog >applications in 9 minutes. Just to clarify for those who don't get the reference: Ruby on Rails became famous (notorious?) for having an "application in 11 minutes" demo video - MG:U did the same thing with a "blog in 9 minutes" demo video. And, yes, it relied very heavily on scaffolding and the underlying ActiveRecord-based ORM power of Reactor. Right now, MG:U is the only framework that can support this workflow. As Brian points out, that should not be your single yardstick for measuring the applicability of a framework. I only use scaffolding for prototyping, not for production, for example. >I would agree that Model-Glue is easier to learn >that Mach ii, which is probably why I chose to go the MG route first. Agreed. >However, before I was able ot properly do MG even, I had to take a step back >and learn how to code OO - by hand. Yup, without any OO comfort level, even MG can be a pretty scary beast. >I actually tried the >MG/Reactor/CodlSpring route before it was all integrated and before I >understood OO. Big mistake. It led me into a lot of problems that were not >the fault of any of the frameworks but more the fault of my own >misunderstanding and ignorance about the problems they are intended to >solve. Ouch! Yes, but a good learning experience nonetheless, eh Brian? ;) >sold like a Ginsu knife that can cut through tin cans. People are buying it >without asking why they need a knife that can cut through tin cans or Reminds me of the comment about C and C++: with C it's easy to shoot yourself in the foot but it also lets you get the job done quickly; with C++ you can get the job done more quickly but it's also easy to blow your entire leg off. A powerful knife can be a great tool but it's all too easy to cut yourself - badly - if you don't know how to handle it properly... >CF is deceptively easy to do simple things which >tends to hide the complexity of the language as a whole. Yup. It's terribly easy to build something terrible :) Sean

I'll ask Nic about that, Sean. ~Simon Simon Horwith CIO, AboutWeb - http://www.aboutweb.com Editor-in-Chief, ColdFusion Developers Journal Adobe Community Expert Adobe Certified Master Instructor Blog - http://www.horwith.com Sean Corfield wrote: ----- Excess quoted text cut - see Original Post for more -----

> As for stable ORMs, objectBreeze is the only one to reach a 1.0 > milestone so far (and I have some pretty strong reservations about its > APIs). I don't know if Nic Tunney is on the list and wants to comment > on how widely downloaded objectBreeze is? My sense is that Reactor is > far and away the most popular ORM, followed by Transfer and then > objectBreeze. After having a look at all three of the "big" ORMs I think ObjectBreeze is the easiest to dive right in with.  Like any of the ORMs there are things to like and dislike about it.  If someone is new to all of this (what's an ORM?!?) then I think ObjectBreeze is a great place to start.

> As for stable ORMs, objectBreeze is the only one to reach a 1.0 milestone Although, saying that, the v1 API is basically frozen now, and it's easily finished enough to use in production (and has been for a while). -- Tom Chiverton Helping to proactively harness scalable communities **************************************************** This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at St James's Court Brown Street Manchester M2 2JF.  A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by the Law Society. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged.  If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents.   If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 8008. For more information about Halliwells LLP visit www.halliwells.com.

To add my 2c, Denny, Reactor isn't really a framework. It is a way to automate the persistence of objects. In OO programming, you often create DAOs and Gateways (data access objects and table data gateways) to abstract your database access code for single records and recordsets. Firstly, I have some issues with the idea of Gateays returning queries, but that is neither here nor there. Reactor just auto creates those. You probably want to create a set of service objects (one per object - singletons created using a factory or ColdSpring if you want to be fancy!) for doing all of the business logic and the business objects themselves will often have logic (Product.getPrice() may calculate price based on your discounts or whatever). Then you need a controller which you can write yourself or use Model Glue (classic - not Unity!)  or Mach -II for. If you are only getting started with OO, I'd thorough recommend checkout out all of the great blog postings on OO programming and would start there. I think it's quite a leap from procedural CF straight to MG Unity, and if yu had to jump straight to a framework, I'd consider mach-ii or Model Glue without Reactor and ColdSpring. ColdSpring solves a real probvlem, but have the problem first and then enjoy the relief i provides. Reactor also speeds development, but I don't think you'll fully understand the trade offs until you've written a few DAOs and agonized over where to put the code for joined objects (how you you get all of the Users in a Company - CompanyService.getUsers()? and if so, what DAO does it call - CompanyDAO or UserDAO). Once you've played with that for a while, you'll be able to choose between Reactor, Transfer (which is looking very interesting - Mark keep up the great work and the shameless plugs!), cfhibernate, or rolling your own ORM. Best Wishes, Peter

To sound off here, All of the points above are very valid.  I've used Mach-II pretty heavily now for a while and MG:U to varying degrees and I really see where the frameworks add value. All three Front Controller frameworks ( Model Glue, MachII and Fusebox) are quite solid and are worth learning. I am decidedly framework agnostic. I choose to use a framework now even if I am the only developer on a small app. While frameworks sort of 'force' certain solutions to problems, this is actually a feature, not a bug and is quite nice when making enhancements or bug-fixes to your application later on. As mentioned above, some of the frameworks offer different features, but all of them will help organize your code in an easy to understand manner. To Peters point, some of the problems solved by the frameworks ( M2, MG, CS, Reactor,  Transfer, Etc) are indeed not completely obvious before you have taken the plunge into OO ColdFusion. Dependency resolution ( by ColdSpring) doesn't seem to be a major pain until your app has some complexity around it. When you do run into dependency problems, ColdSpring is a godsend. Same with the ORMs ( a la Reactor / Transfer ) . Pulling and Persisting information in a database is a vital application task. It is a problem that has been solved in various degrees by the ORM tools and helps get on with the meat of the application, the rules and other important logic. Give Transfer and Reactor a shot. Each has a nice blog sample application to toy with. You can immediately see the benefits of using an ORM in your application. Being a coder who had your very same questions at one point, let me offer a few suggestions (gained from my blood sweat and tears ): 1) Get familiar with http://www.fullasagoog.com/index.cfm?blogcat=ColdFusionMX There is a wealth of very important information catalogued there. 2) Get familiar with www.google.com. If you run into a sticky problem whilst learning, you can be assured someone else ran into it also and there is probably a blog post or two about it somewhere. 3) Download sample apps and customize the mess out of them. You will break and fix plenty of things and this really accelerates the learning process.  I definately learn more from looking at others' code than I do my own. 4) Yes, it does seem like you are writing a ton more code. This will prove its value soon enough. I've added and removed whole new features / functions to applications with a single line of XML. OO CF, especially with a framework, seems like an indirect solution to the problem at hand compared with straight-line .cfm page coding. 5) There is no *right* answer usually. There are, however, some guiding principles and a whole lot of tradeoffs. If you aren't sure which way to go, try it one way and then another. 6) All the major frameworks have very active mailing lists. There is a wealth of information in the archives and batallions of helpful coders out there ready to lend a hand. 7) Yes, you will want to bang your head at times. And Yes, it gets easier..... Dan Wilson

To sound off here, All of the points above are very valid.  I've used Mach-II pretty heavily now for a while and MG:U to varying degrees and I really see where the frameworks add value. All three Front Controller frameworks ( Model Glue, MachII and Fusebox) are quite solid and are worth learning. I am decidedly framework agnostic. I choose to use a framework now even if I am the only developer on a small app. While frameworks sort of 'force' certain solutions to problems, this is actually a feature, not a bug and is quite nice when making enhancements or bug-fixes to your application later on. As mentioned above, some of the frameworks offer different features, but all of them will help organize your code in an easy to understand manner. To Peters point, some of the problems solved by the frameworks ( M2, MG, CS, Reactor,  Transfer, Etc) are indeed not completely obvious before you have taken the plunge into OO ColdFusion. Dependency resolution ( by ColdSpring) doesn't seem to be a major pain until your app has some complexity around it. When you do run into dependency problems, ColdSpring is a godsend. Same with the ORMs ( a la Reactor / Transfer ) . Pulling and Persisting information in a database is a vital application task. It is a problem that has been solved in various degrees by the ORM tools and helps get on with the meat of the application, the rules and other important logic. Give Transfer and Reactor a shot. Each has a nice blog sample application to toy with. You can immediately see the benefits of using an ORM in your application. Being a coder who had your very same questions at one point, let me offer a few suggestions (gained from my blood sweat and tears ): 1) Get familiar with http://www.fullasagoog.com/index.cfm?blogcat=ColdFusionMX There is a wealth of very important information catalogued there. 2) Get familiar with www.google.com. If you run into a sticky problem whilst learning, you can be assured someone else ran into it also and there is probably a blog post or two about it somewhere. 3) Download sample apps and customize the mess out of them. You will break and fix plenty of things and this really accelerates the learning process.  I definately learn more from looking at others' code than I do my own. 4) Yes, it does seem like you are writing a ton more code. This will prove its value soon enough. I've added and removed whole new features / functions to applications with a single line of XML. OO CF, especially with a framework, seems like an indirect solution to the problem at hand compared with straight-line .cfm page coding. 5) There is no *right* answer usually. There are, however, some guiding principles and a whole lot of tradeoffs. If you aren't sure which way to go, try it one way and then another. 6) All the major frameworks have very active mailing lists. There is a wealth of information in the archives and batallions of helpful coders out there ready to lend a hand. 7) Yes, you will want to bang your head at times. And Yes, it gets easier..... Dan Wilson