Which Framework Should I Choose?
Posted By : todd sharp Posted At : January 31, 2007 12:12 PM Posted In: ColdFusion
14
I apologize if you came to this post hoping that I would be answering that question. It's actually quite the opposite. You see, I'm in a bit of a funk lately. Work has been nuts (I'm taking my lunch right now at 1:15 today for example) and personal things have kept my mind a little foggy lately. I have several projects that I really want to get started on, but I'm at a crossroads and I need your help. Yes YOU. All the warm and fuzzy talk about the ColdFusion community lately makes me confident that all you people can help me out.
You see the thing is, I want to grow as a developer. I want to learn a framework. So many people preach the benefits of them and I want to be 'one of the cool kids' too. To that end, I've done a lot of research lately. I've pulled quick start guides, documentation, configuration guides, etc and read through them. I've followed the blog posts preaching the gospel of many of these frameworks over the last few years. I've talked to some really really smart people with real life experience with some of these frameworks via GTalk lately. All of this research though has left me with the question in my mind "Which one(s) do I choose"? Should I go with Mach-ii or model-glue (or something else)? Should I use an ORM or code generator too? What about template wrapping in your views - can/should you use a custom tag type layout wrapper?
You see, in my 'day job' I don't use any of these. There, I said it...I feel better now. I never have. Shame on me. I do consider my CFC knowledge getting closer to the advanced level - and the last application that I built did a very goo d job of being OO-ish. But I'm hearing the voices in my head get louder and louder every time I read a blog. Rapid deployment. Structured code. Separation of business logic and presentation. I just need a nudge and I figured that one of these applications that I want to build would be a perfect starting point/learning experience.
The timing of this post may be poor given that the Frameworks conference is under way and most likely the brightest minds on the topic will not even see this post since they're probably traveling right now but I thought I'd put it out there.
Oh by the way. I know the first comment that I get will be "Well it depends on your application"... So picture my application as being a simple user generated content site. Think EBay (but don't think too hard because it's really nothing like EBay). Required: Registration/Login. Simple user content upload/editing. Nothing too AJAX-y (maybe a sprinkling). Is that enough of a description?
You should use Mach-II of course, duh.
Great post.
I have landed on Model-Glue with Reactor as a starting point. I'm deploying a FarCry install on a project at the same time.
We'll see what happens. =)
Josen
Todd, you know I would put a vote in for Mach-II, but only because it is what I use and have had such great success with. Honestly any of our applications could have likely been just as well served up with MG, Fusebox or ... well, those. The reason is that we try to treat our frameworks as nothing more than a mechanical structure that directs traffic (which I believe that Mach-II does quite well!). Our listeners don't really know anything about data, as this is a job for a service layer. Due to this architecture, we could fairly easily pick up our applications and drop them into other MVC frameworks without enormous loads of work.
Another thing to consider IMO is what it is exactly that you expect from your framework. MGU has some really cool features and includes built-in functionality for Reactor and ColdSpring, and does scaffolding. Mach-II/FB/etc can easily support the same frameworks (not the scaffolding), but it entails plugging those pieces in by hand, which I feel quite comfortable doing (maybe a control-freak thing). As for the scaffolding, it is not a feature that I have any particular interest in, but I am sure it is valuable to a lot of people.
What about taking a pet store approach and just building a little app in all of the big 3 and see what you think? If it is a learning project anyway, that might be a good time to experiment.
~d
i've been using CF since version 1.5...and this past sept took a job with a company that uses fusebox (4.1 at the moment). first time in 10+ years that i'm using a framework (not that i was ever averse to it...just never really had (or made) the opportunity).
i couldn't be happier with it. i think it was the perfect first framework for me to use because it's arguably the "easiest" (in that it doesn't enforce a lot of rules or restrictions). yes, that's also a drawback to it...it's easier to write "bad" code in fusebox than other frameworks...but as a starting point...to get comfortable with the concept of a framework...of working within the structure of a framework...i think fusebox goes a LONG way towards levelling off that learning curve.
my $0.02
HMMMMMMMMMMMMM.....now that sounds like a good idea. Would surely make for some good blogging too. Can I take a week off of work now please? :)
Please tell that to my Mach-II code!!!!! :)
second answer: for me, it's fusebox (and fusebox all the way) for a couple of specific reasons that have served me and many of my clients very well: it's mostly proceedural process makes it very (very, very) easy to bring new team members on and off the project, especially if you have members of very mixed skill levels, including several junior members. having "brought in" fusebox into a federal government branch (where there tech staff turnover is emmense, and they needed something very accessible and powerful), a local municipality (with turnover, outside contractors, and a hodgepodge of competing business interestes), and a 80MM/year company to rewrite their entire software foundation on, fusebox means that we can utilize developers of all skill levels without worry. OO can be a scary term, and it also (to me) implies a need for more skilled or experienced developers to manage or build successfully. With a proceedural approach, we can simply plug developers in at any stage, using the predictability of the framework to allow people to speed in moments.
Use what you enjoy most. fusebox has been very kind to me. :-)
Any questions feel free to drop me an IM or email
What pipped it was MG:Unity (Reactor and Coldspring), plus a general consensus from people that have used both that MG has a better development approach when in big teams working on different aspects of a large application.
*shrug* Their view not mine. However MG Unity really is surprisingly powerful.
Adam
If your team is all pretty comfortable with OO, pick Model-Glue: Unity (with Transfer as your ORM).
If your team is mixed ability, pick Fusebox 5.1 (with ColdSpring and Transfer).