I would like to begin with the statement that I am not against the use of frameworks, if they work for you, that's great. However, I do get the feeling that there are people out there that think less of programmers that don't use frameworks. Admittedly, there are probably a significant number of ColdFusion programmers out there that don't use frameworks because perhaps they don't grasp the architecture of the framework, or they get scared off by all the big words that framework enthusiasts are so fond of, or they are just never have time to do the research to find out what the frameworks have to offer.

[More]

Comments (Comment Moderation is enabled. Your comment will not appear until approved.)
todd sharp's Gravatar Here are the answers to your questions (in no particular order): Yes, No, Yes, Yes, Maybe, It depends, Yes, Yes.

But seriously... I don't think its a matter or "better", "smarter", "cooler" or any of the above. It's about writing code in an organized manner that follows a particular methodology so that it is easier to build and maintain (IMO). So if your framework does that for you, so be it. Model-Glue (my framework of choice) does that for me, and it allows any other MG developer to hop into my code and *immediately* figure out what is going on for a particular event. There's no guesswork at all. You want to know about event "foo.poo"? Go to MG.xml - find the event - see what it broadcasts - see what is happening in the controller - see what views are included -- all of those things are standardized. No more guessing where variables are set, etc.

Its a matter of following a pattern for maximum reusability. I can take anyones MG app and support it with 10 minutes of ramp up time - instead of 10 days. Are there performance implications? Maybe. But I'm inclined to live with that for the sanity of a well constructed application. I could be wrong, but I find it hard to believe that the pig latin demo took 1s for every request.

Do what you like, but to me the biggest benefit of a framework is consitency, reusability, etc.
# Posted By todd sharp | 5/23/08 6:12 PM
Scott Bennett's Gravatar @Todd,

I definitely appreciate that frameworks offer consistency, and I am not saying I would never use one. This is not a bash on frameworks. I simply don't think you should judge a developers ability based on whether or not he uses a framework. Now that I have spent a couple days reading about model-glue, I can officially say that I could go right in to any model-glue application and know my way around with ease. And as I said before, I would be happy to use a framework that performed a little slower if the application didn't need to be super fast.

I know you are pretty smart guy and it wouldn't take you 10 days to figure out my application structure. If you spend a few minutes looking at my code you will find it is quite similar in basic architecture to Model-Glue, it just that instead of using an xml schema to configure my controller, I use a case statement and the request scope within the controller itself. And my code is consistent, so if once it clicks what I am doing you can navigate through the rest of the code with relative ease.

And I just refreshed that page 40 times and it was 0ms 23 times and 15ms the other 17. Granted I have a kick butt development server, but I used the same server for the MG app too.

I am not trying to bash Model-Glue, if I had to use a framework on a project, I would most like choose that one.
# Posted By Scott Bennett | 5/23/08 6:37 PM
Mike Rankin's Gravatar @Todd,
I'm in the other camp to a degree. One of the reasons I don't care for many of the mainstream frameworks is that it really limits the people that can be dropped into a project quickly. So instead of being able to grab someone who has basic cf knowledge and is relatively sharp, I have to find someone with specific framework experience.

The other big issue I have with frameworks is that, without exception, every framework project of size that I've ever worked on has not followed the framework very well. There tends to be lots of rogue code that just doesn't follow the rules. Sometimes that's because the developers didn't understand how the framework operated and just needed to "get it done". Other times it's because lots of framework code exists from old versions and a new framework has been implemented on top of the old code. It can be pretty maddening.

Dont' get me wrong, you can have some real nasty problems with non-framework code, but it doesn't seem to get as scattered. A framework that you are not familiar with can make tracing things back to their origin very difficult, especially if the framework is not followed consistently. One of the old fusebox apps I worked on had gobs of logic buried in the controller. You could never be sure what was going to show up with a given page.

I think there is a huge difference between working on gigantic corporate information systems and isolated green-field apps. Green-field apps are probably better suited to frameworks if you can build it and finish it and put it on the shelf. For really big systems with code that might survive 10 years or more, you have to think that your framework you started out with may look pretty dated after that period of time. As long as you have the time to fully adopt updates to your framework, then you'll be in pretty good shape. Otherwise you end up with the frankenstein apps that I've run across.
# Posted By Mike Rankin | 5/23/08 6:38 PM
Oscar Arevalo's Gravatar Sometimes it seems that a lot of people out there confuse the terms "well architected application" with "using framework X".

Frameworks are like canned knowledge, which is good and dangerous at the same time. Is good because you can benefit from multiple good practices and ideas in one shot and is not so good because you can use all of them without necessarily having to understand them well yourself. Why is this bad? because understanding those ideas is what makes the basis of a good programmer. Like Scott said, a good programmer with enough experience should be able to know, understand, apply and recognize basic software development principles like MVC, OOP, patterns, layers, abstractions and what-not.

Not using a popular framework is not synonymous of bad coding; bad coding knows no limitations: it will show up in every language and in every framework. However, a good engineer can produce a sound application architecture that any other good engineer will be able to understand as long as we all speak the same "language". This common language should not be framework X or Y, but instead should be the basic ideas in which software development is based on. And if someone doesn't yet understand these principles, then a better use of their time would be studying things like OOP, UML, MVC, patterns and things like that instead of the different idiosyncrasies of using the framework of the month.
# Posted By Oscar Arevalo | 5/23/08 6:46 PM
charlie griefer's Gravatar oscar nailed it perfectly. it's not about just using a "framework" for the sake of saying, "hey i use a framework". it's about a well architected application. consistent, scalable, and easy to maintain. IMO, a framework gives you that out of the box. but can you have that without a framework? absolutely. i should also point out that using a framework doesn't automatically mean you're writing "good" code. i've seen very bad code written inside of frameworks. hell, i've personally written very bad code inside of frameworks. it's still a conscious effort to develop good code either way.

@scott bennett: "However, I feel that my application architecture is just as organized and just as maintainable as it would be if used a framework."

then aren't you essentially... using a framework? just because it doesn't have its own web site or mailing list or session at cfunited doesn't mean it's not a framework :)

@mike rankin: "One of the reasons I don't care for many of the mainstream frameworks is that it really limits the people that can be dropped into a project quickly. So instead of being able to grab someone who has basic cf knowledge and is relatively sharp, I have to find someone with specific framework experience."

i'll respectfully disagree with that. i think using a community supported framework makes it easier to *potentially* find someone to come in and hit the ground running, as opposed to having to pay someone for a week of "ramp up" time. let's say you're using ColdFuseModelBox-ii. you could potentially bring someone in who can be productive on day 1. if you can't find someone who knows that particular framework... yes, you have to teach them how it works. but if you're *not* using a framework, don't you still have to teach them how you have things set up? the way i see it, you either break even there... or you find someone who already understand the architecture that you're using. but i don't see a downside.
# Posted By charlie griefer | 5/23/08 7:21 PM
Scott Bennett's Gravatar @Oscar
That is exactly the point I am trying to get at, although you said it much more elequently than my ranting.

@Charlie,

Yes, I would consider what I do sort of an undocumented framework, hence the last line of my post =). But I have the freedom to adapt my "framework" to meet the needs of my application, rather than conforming my application to the rules of my framework.
# Posted By Scott Bennett | 5/23/08 7:36 PM
Russ Johnson's Gravatar I think Charlie is correct. One of the things that I have come across many times with clients is that developer x used his own framework. Thats great, no problems there, Im sure it made sense to him at the time. Problem is, like you said Scott, its "undocumented" so you run into the Beer Truck problem. If you get hit by a beer truck tomorrow, there is no documentation on your framework for developers to follow.

When using one of the mainstream frameworks, you get the benefit of it being documented and having tons of resources and help readily available to get ramped up.

This doesnt even take into account all of the often overlooked benefits to frameworks such as advanced caching, etc.

Can you build well architected applications without using one of the mainstream frameworks? Absolutely! But what are you leaving for other developers? I like to think that the developers that may come behind me someday, will have it much easier since there is plenty of documentation to get them up to speed wether they know ColdBox or not.

@Charlie - ColdFuseModelBox-ii ?? Really?? That is classic!
# Posted By Russ Johnson | 5/23/08 9:06 PM
Scott Stroz's Gravatar Using a framework does not guarentee that your code will be well organized or structured. I have worked on a project that used (supposedly) FuseBox, but it is the worst code I have ever seen. Not only poor coding practices, but poor application architecture. There were queries in just abot every 'view' page, and a few places where 'model' files just included 'view' files or vice versa.

Conversely, rolling your own methodology/framework does not mean you won't have code that is well organized. I have seen some fantasticly architectured applications that did not use a community supported framework.

I would also agree that you will have better odds of finding someone who can jump into a project and make a diference right away if it uses a community supported framework as opposed to a homegrown one. If we polled Scott's readership I'd hazard a guess that more people know Model-Glue than Scott's framework/methodology.

I think the reasons why someone chooses not to use a framework would be more more of an indicator of their level if suckage than simply the fact that they don't use one.
# Posted By Scott Stroz | 5/23/08 9:26 PM
Scott Bennett's Gravatar Russ/Scott Stroz,

Definitely have agree with you there, I have had many experiences working on code someone else wrote and having to spend a lot of time digging through their spaghetti code to find the line of code I need to change.

I *usually* do include a write up of the architecture I employ in any complicated applications I build from scratch. I also try to leave good comments in my code for other developers to follow. And if I am going to use it at my current full time job then entire architecture will have to be planned and documented thoroughly and approved by my boss and his boss before I can even start having my development team write the code.

At my current full time job, I work on an e-commerce application that has had many developers adding their own styles to the application over the last 10 years. I am in a position now where I can rebuild it, and was seriously considering model-glue as a framework, but if I can't figure out how to make it faster then I would have to buy 4-6 more servers to handle the sites traffic during the holiday season. My employer is much more concerned with the site being super fast then they are with how hard it is to maintain the application. They wouldn't mind new developers having to take a few days/weeks to figure out how the applications architecture, if it meant they could process more orders per hour.

It may be that I did something wrong in my Model-Glue code, which you can get from the download attached to his article, but I am pretty sure I followed the instruction exactly. I see a couple of you guys like Scott Stroz and Todd that are far more experienced in MG than I am. Are there tips on making it faster? Is it typical to have a seconds worth of overhead in a MG request?
# Posted By Scott Bennett | 5/23/08 9:46 PM
Joe Rinehart's Gravatar Hi Scott,

No, it's not typical at all. You were probably running Model-Glue in development mode, where it reloads the entire framework on each request. I'll download the code over the weekend and follow up with an in-depth exploration.
# Posted By Joe Rinehart | 5/23/08 10:00 PM
Dale Fraser's Gravatar You don't suck!

Frameworks don't suck!

There is a fine line between when you should and should NOT use a framework. Some people would use a framework for everything, and thats not right, frameworks are not for everything
and different frameworks are better suited to different applications
# Posted By Dale Fraser | 5/23/08 11:08 PM
Scott Bennett's Gravatar Joe,

That would be cool, as I mentioned in my rant above, I did set the "reload" and "debug" properties to "false" in the "modelGlueConfiguration" bean. Before I did that it was taking 8 seconds to load each MG page, so that made a difference. Is there possibly some other setting that I missed?

And to re-re-re-iterate to everyone what I said from the beginning, I am not bagging on frameworks. Nor am I bagging on Model-Glue, I actually like it the best of all the frameworks I have seen.

The main point of my rant was that I feel some people equate the use of frameworks with the level of a developers competence. I have gotten that feeling from several people over the years.

I can definitely understand that it's easier to maintain the code, and it's easier to go into someone else's application and know where everything is and all that. I definitely feel that frameworks have their place, particularly where you are in a development group where a lot of people are going to be involved in different parts of your applications development. That is why I want to use one at my current job.

But I don't feel like just because you know a particular framework, it makes you more valuable as a developer. I have worked with some people that "know how to use frameworks" that I wouldn't trust to build anything, whether they used their framework or not.
# Posted By Scott Bennett | 5/23/08 11:09 PM
Scott Bennett's Gravatar Dale,
Which framework do you feel is best suited to a high-traffic multi-server e-commerce application?
# Posted By Scott Bennett | 5/23/08 11:16 PM
Mike Britton's Gravatar You shouldn't use a framework unless you completely understand how it works and know why it's better than your home-spun codebase. If you study a framework and decide it isn't as understandable as your own codebase / methodology, you should go forward with your stuff. I'll say though, in general it's better to go with a community-supported framework with respect to bringing new programmers on board. If you can find someone that knows Model-Glue, you have a new employee who can perform right out of the box. That, and you gain benefits from framework upgrades, as well as information on undocumented features and fixes from others in the community.
# Posted By Mike Britton | 5/23/08 11:58 PM
Scott Bennett's Gravatar @Mike,

I have definitely not spent enough time or dug through the Model-Glue source code enough to know claim to know *completely* how it works, but I do understand the architecture and the principles behind it, and I have spent a good deal of time reading the documentation. I'm not going to implement anything until I am sure it will work for my application, but I have plenty of time to evaluate it so that's not really an issue. And If I need to hire another developer in the future, I would not be too concerned with whether they already knew my framework of choice or not. I would just pick the most talented candidate available to me at that time. If they already know it great, if not, it shouldn't take them too long to learn, or their not the right employee for me.
# Posted By Scott Bennett | 5/24/08 12:33 AM
Joe Rinehart's Gravatar Scott, what's the point of this post? Is it to question whether or not people think less of you because you don't use frameworks or to state that you think frameworks such as Model-Glue are slow? That's been disproven again and again.

When I came back to read this, I noticed you're judging framework performance based on ColdFusion debugging output. This is probably the worst measure possible. Anything that involves a deep CFC-based execution stack is going to take forever to run with that dog turned on.

To get to brass tacks, I slaved a box here to running a 20-thread JMeter test (performing 20 simultaneous HTTP POST requests perpetually) against your code vs. Model-Glue's: yours came out at about 65ms / request, and the MG version was at 100ms / request. Considering that you're using explicit invocation and don't have an event bus, while MG uses an event-based II system and maintains an event context CFC instance, I'd say that's a fair trade off.

As far as the "if I am building an e-commerce site that needs to be able to handle 16,000 orders an hour; there is no way I am going to accept that kind of overhead just because frameworks are cool" statement goes, I did an MG-based charity site after hurricane Katrina hit that pumped was pumping a lot denser load than that.

If ModelFuseMachBox couldn't handle load, would any of them have made it this far?
# Posted By Joe Rinehart | 5/24/08 12:37 AM
Joe Rinehart's Gravatar Scott,

Whoa - didn't mean the comment I just posted to come off as defensively as it did. I apologize.


For the first paragraph, I'd like to know what it is you're asking by the post - are we derailing (or am I missing your point) by focusing on MG performance?
# Posted By Joe Rinehart | 5/24/08 12:42 AM
Scott Bennett's Gravatar Joe,

Once again I am not attacking frameworks or Model-Glue, I am not claiming to be an expert on either. I even asked in my article if I am missing something. Turns out, I was not aware that the cf debugging would have that big of an effect on the performance of the model glue application. Obviously you are an expert at what you do and I respect that.

This post as I have explained over and over again is because I wanted to see if other people in my field feel like people that use frameworks are better than those who don't. I have had several people over the years imply to me personally that I am not as good as some other guy simply based on the fact that I don't use frameworks and they did. I have been turned down for jobs in the past because I never had an opportunity to actually use Fusebox in a live application even though I told them I had read the book and done some sample applications, and I was more than capable of doing the job.

So this post was about people and how they think, and how I disagree with that kind of thinking. If you want I'll edit this post and take all the references to model-glue out, that just happened to be the one that I am thinking about using because I finally got tired of people judging my abilities based on frameworks and decided to just buckle down and use a framework for something.
# Posted By Scott Bennett | 5/24/08 1:08 AM
Scott Bennett's Gravatar In the interest of keeping things on the topic, I have edited the article by removing some side thoughts about things that don't really relate to what I intended to talk about in this post, and were founded only on my inexperienced first impressions of the Model-Glue tutorial application.

I really do like Model-Glue, I am sure after I get more familiar with all of it's intricacies, I will be blogging more about it. Perhaps I will write a blog entry about how the ColdFusion debugger can make it appear slower than it really is =)
# Posted By Scott Bennett | 5/24/08 2:05 AM
Mark Ireland's Gravatar Once you have invested time in a framework, you will learn to love it. Of course, then all your posts will be about bugs you have found. You will be reluctant to stop using it even though you suspect it is not worth the trouble.

One day someone will inherit your application and will go 'WTF?!?'
# Posted By Mark Ireland | 5/24/08 4:43 AM
Scott Bennett's Gravatar @Mark,
LOL! That's pretty much what I say every time I inherit an application. And I doubt that will change even if I start using a framework and then start having to edit someone else's framework code.
# Posted By Scott Bennett | 5/24/08 5:33 AM
pan69's Gravatar But, ColdFusion is a framework. At least, to me as a Java programmer it is.
# Posted By pan69 | 5/25/08 1:02 AM
Mike Britton's Gravatar Now that is hilarious. lol
# Posted By Mike Britton | 5/25/08 1:04 AM
Scott Bennett's Gravatar LOL!! pan69 must work for TIOBE or something.... is that you Richard Bremner??
# Posted By Scott Bennett | 5/25/08 1:56 AM
Johan's Gravatar I agree with Oscar.
# Posted By Johan | 5/25/08 2:17 AM
Shlomy Gantz's Gravatar "Most CF frameworks solve a problem I don't have", I told that to Simon horwith in private and he of course decided to blog about it.

http://www.horwith.com/index.cfm?mode=entry&en...

For me, a good framework should solve a particular problem, either now or in the future. I like frameworks that "do the work" for me and not the other way around.
It is very common that I see developers struggling with a particular framework, especially one that is above and beyond the needs of the application.

I do however that frameworks often provide a good way of introducing good CS practices, especially when those so often seem to be lacking in the web development community.
# Posted By Shlomy Gantz | 5/25/08 7:35 AM
Doug Hughes's Gravatar I like knowing that people who work on my projects know the technologies I use inside and out. I've learned through experiance that I can tell someone in very explicit language where to find code or what I'm going to do when we both use the same framework.

Furthermore, I am always suspect of a developer who says they "know" OO. I teach classes on MG and CS and one of the first questions I always ask is who uses OO. Most people raise their hands. But, but the end of the first presentation on CFCs usually there are a of of surprised people in the class. By the end of the week these same people are saying they had no idea how deep some of this stuff goes.

In my opinion OO isn't so much something you know as much as a way of looking at software development. So, if someone is using a framework I respect and being productive in it I have a good feeling that they really know OO. If not, then I think twice.

All I'm really trying to say is that there's a subtle difference between writing CFCs and Object Oriented Development.
# Posted By Doug Hughes | 5/25/08 9:55 AM
Nick Kwiatkowski's Gravatar For me, Frameworks add a lot of baggage to code that may be unnecessary. Sure, there is the benefit of others going in and understanding the architecture of your code, but for me that doesn't being anything of value to the table.

- We don't hire outside contractors to work on portions of our code.
- We use a common architecture in all of our applications that we developer.
- When we hire a new person, they are overwhelmed by just about everything else.. How to use the phones, how to check email, how we store files, etc. Sure the argument could be "Well, they could be coding right away", but in all honesty, a new hire is a write-off for at least the first two weeks anyway.
- All the major frameworks that I've tried all add significant overhead, in both memory and processing. I don't have time (nor the energy) to do a code review of what that framework is doing. If it IS doing something screwy, I have to be able to defend it should it cause a bug.

For me, it is more important to code consistently, and with a good architecture (or pattern). Using a pre-canned architecture may work for many, but in our situation, it doesn't.
# Posted By Nick Kwiatkowski | 5/25/08 12:26 PM
Allen's Gravatar What's the difference exactly between what is a framework and what is architecture? The reason I ask is that it seems like quite a few folks are using their own "framework" but maybe that's not the right term?
# Posted By Allen | 5/25/08 5:26 PM
Kris Brixon's Gravatar @Allen
A framework would be part of the architecture of a system. The framework is how you organize and structure your programming. If you create an architecture then you have some kind of framework even if it is home grown.

That said, the question "Do I Suck Because I Don't Use Frameworks?" would be NO, but "Do I Suck Because I Don't Have An Architecture?" would be YES. Without an architecture, you are mindless coding along with the hope of creating something one day. With an architecture, you have order and structure to your coding and you will have some kind of framework even if you do not realize it or call it a framework.
# Posted By Kris Brixon | 5/25/08 7:09 PM
Mark Mandel's Gravatar For me, while frameworks are about maintenance, and having to write less documentation, really, its about having > 300 testers at hand on a given piece of code.

There is just no way you can write a piece of code, on your own or as a team, that is more thoroughly tested than a community project.
# Posted By Mark Mandel | 5/25/08 8:16 PM
rob's Gravatar If everyone used the established frameworks, no new frameworks would ever get invented. :)
# Posted By rob | 5/26/08 4:02 AM
Oscar Arevalo's Gravatar @Mark,
It is a common argument in favor of using community frameworks to say that if you use a popular framework you have the benefit of having 300+ testers. In my opinion this is a flawed argument. Why? because those 300+ testers are only testing a small fraction of your application; they are only testing things that are inherent to the framework and not to your application. You could have 3000 testers for your framework but your application can still fail miserably because the business logic is wrong or you have an incorrect link somewhere. The only assurance that those 300+ testers can give you is that all the extra features and overhead the framework provides works as intended; but the reality is that you may not be using all those extra features, so the benefit of those hundreds of testers doesn't really mean much at the end.

Now, I'm not against frameworks either, I just think that usually the arguments used in favor of using a community framework are not always correct.
# Posted By Oscar Arevalo | 5/26/08 1:57 PM
Allen's Gravatar How big of a deal is this overhead? Are there that many CF developers working on applications that have so much traffic that it actually makes a difference?
# Posted By Allen | 5/26/08 3:50 PM
Mark Mandel's Gravatar @Oscar,
I have to respectfully disagree with your disagreement.

I know from personal experience, the amount of testing that my users have done for Transfer has been invaluable, and quite frankly, took it far and beyond where I have ever used the framework.

While not all the developers test the 'outer edges' of the framework, many do, and in * varied * ways. (It's always interesting to see how people actually do use Transfer).
# Posted By Mark Mandel | 5/26/08 8:33 PM
Scott Bennett's Gravatar @Allen,

I would say that for *most* applications, 30-40 extra milliseconds of extra processing per request so you can have your framework is not going to make any noticeable difference. But I have worked on a couple of applications where it would mean that I would have to buy/maintain more servers to handle the traffic the site generates. When I developed those sites I programed them so that the servers would have to do as little processing as possible to serve up each request. If you are building a high traffic site, then it's a really judgment call to decide if some extra hardware is more expensive then it is to train the occasional new developer on how to use your sites architecture because you didn't use a community supported framework, OR to decide that you don't mind having to buy/maintain a few extra servers because you're going to be changing developers on the site fairly often, or there are going to be so many developers working on the site that you need a community based framework so that everyone is on the same page and the application doesn't turn into spaghetti code (which of course might just happen anyways if you aren't careful about making sure your developers follow the specified framework). It's a judgment call, and different situations will dictate a different answer. The key is really in knowing what is best for your particular application and executing it well.
# Posted By Scott Bennett | 5/27/08 2:18 AM
Peter Bell's Gravatar Everyone uses a framework. Only question is whether it's community or in-house. Benefits of community framework are that it will be easier to get others up to speed (more documentation), more people know it already, and there is less likelihood of you coming across bugs in the framework as it is well tested.

The downside of a community framework is that they are designed to solve a wide class of use cases, so they are less likely to be an optimal solution for any given use cases - especially those that are substantially outside the norm.

As others have mentioned, the quality of an app is pretty much orthogonal to whether it uses a community framework. However, because of the pressures on open source (nobody wants to release lousy code, and if they do, nobody uses it), the average quality of successful community frameworks is much higher than the average quality of in-house frameworks. It's the old problem of everyone believing that they are above average in their skills. unfortunately only half of them are right :-)
# Posted By Peter Bell | 5/27/08 10:56 AM
John Allen's Gravatar Hey ColdFusion guy, your code is pretty sharp. I could work with that, no problem.

but...

What happens when your application has 800+ events? cfswitch statement?That aint scaling. The MG application will process from start to finnish in the same 100 Joe talked about.

Hey what happens when you need to integrate another kinda big application into your application? If you used MG for your front controller it would be no problem. Again your code is tight, but how am I gonna integrate? Extend? Add another case? Add LOTS more cases? Introduce routing logic someplace else? Again, that switch can start to be the file you dont like (early FB anybody).

Also I mean scaling in both directions, application enhancement flexibility for the future and pure throughput as an application.

An semi-standard-ok application with MG on the front will be scaleable in every direction you can think of.

Also, how will your team work on the BIG application with a fluid work flow? SVN is the truth, but breaking up an application into logical pieces is, IMHO, easer to work with. MG solves that problem.

Another question. This aint about MG.

How do you manage your objects? Do you develop your own factories? How do you manage 10, 100, 150 different objects? How do you create them? How do you manage their dependencies? Do you diagram this all out to keep track? In a small application, no problem. Might be kinda fun. Give it a couple of years and some several feature enhancements... ICK! Sounds like hell. (Although maybe Im not the sharpest tool in the shead, but object creation and dependencies are a rough beast when there are lots of little objs to take care of.)

This is where I would say that if your application is much larger than the companies Contact Manager and your not using ColdSpring... ICK! SCARRY!. BUT you sure might have built ColdSpring, if so cool, I am down.

Please, this is not a diss...

What is the big deal with using a framework? I dont get it.

When has MG/CS ever painted one into a corner? It just aint gonna happen when most of the time we are building MVC applications.

MG/CS CAN NOT AND WILL NOT EVER GET IN THE WAY.

If they are:
1. print out the docs on paper
2. go get a coffee
3. chill and read the docs
4. start fresh the next day
# Posted By John Allen | 5/30/08 2:35 AM
Scott Bennett's Gravatar @John,

You make some good points, and what I would typically do in a larger application, is look for ways to handle events in a more generic fashion so my code didn't have to have 800+ case statements. If that means it would be best if I used with Mode-Glue/Mach-II or build my own lighter weight event controller that reads an XML configuration file when the application initializes and uses implicit invocation or whatever, then I would do whatever my application needed. And as I noted before, on a large application like that, I think a community supported framework would be a good way to go, because there are bound to be a lot of developers involved in such an application over time.

While I think *I* could maintain my code very easily no matter how I organized the it, a large application demands that I (as the original architect of the application) need make decisions that ensure everyone else that *ever* works on the application will be able to maintain it as well. The decision is then to re-invent the wheel and create a well documented framework, or use one of the community based frameworks that have already done that for you.

But seriously, how many applications do most developers work on that are so huge that these issues would come up? What I am saying is that you have to pick what is best for you application. If I am building an e-commerce site, it doesn't have that many events. There is a very finite amount of functionality that will ever be needed on that application and I can easily maintain it using my architecture. I will create a few controller CFCs to handle events in different sections of my application to keep my case statement small, and that works out nicely in most situations, and the code is still organized and clean. If I am making an application that is just going to be what it is and it will never be built upon to grow into a giant application that runs every aspect of a giant company, then there is not point in having any extra overhead to prepare for that possibility.

My personal opinion is that, in most normal sized applications, it would be just as easy to maintain a few controllers with case statements as it would be to maintain the XML files that are in many of the community frameworks. And if done right, the case statement will perform a tad faster (in case performance is something that is more important to your application than being able to find a new developer who can be familiar with its architecture in 10 minutes or less).

BUT... all that aside, my main point of this blog entry is more about the fact that even though I personally have never had the opportunity to employ a community based framework in a production application, that doesn't mean I am any more or less valuable then someone who has used them. As many people have noted already you can write crappy code with or without a community supported framework. My example is just to demonstrate that some of us "non community framework" developers also know how to organize code in a maintainable fashion. And while we may not have experience in your favorite framework, we can bring a lot of other more valuable expertise to the table that may makeup for the fact that it might take us a little more time to get used to your sites architecture. Some of us might even be fast enough that we could learn the community framework, and still build the application faster the some developers that already are familiar with the framework, but may be a little slower at programming in general.
# Posted By Scott Bennett | 5/30/08 4:05 PM
Anjorin Ebenezer's Gravatar This is a very nice discussion.

@Nick Kwiatkowski - "new hire is a write-off for at least the first two weeks anyway." I will respectively disagree with this statement, a new hire is not necessarily a 'new bie' or a rookie.
This is not really productive.

I think we all should get scott's point.

The emphasis should not be on which framework you know (although it might be important in a situation where deadline is crucial), but it should be how smart a programmer is. Any smart
programmer with some experience and basic knowledge of Software development tech's like OOP etc should find it easy to get along with a framework in a matter of weeks.

In companies where frameworks are used, new developers with no knowledge or knowledge of another framework might just be as useful or even beta than those you supposedly think
are used to the framework.

Now, in my opinion. I am not really experienced, as a matter of fact i have only used cfc for flash remoting applications and for for serious web projects. I think using community framework
is reasonable considering the benefits it gives, if we all speak thesame language it will definately be easier to work together. So that is a valid arguement.

Lastly, to all framework experts, especially those of model-glue. Please wot is the best way to get started. I would like to learn how to use framworks.. especially the model-glue.
# Posted By Anjorin Ebenezer | 6/2/08 3:38 PM
Chris Estes's Gravatar Frameworks are just another buzzword, like "Internet," or "Electricity," and "Horseless Carriage."
# Posted By Chris Estes | 6/8/09 1:01 PM
Allen's Gravatar Frameworks are not just another buzzword. Not only have they been around for a long, long time but they serve a legitimate, useful purpose. In fact, I suspect that many CF developers who don't use one of the many public frameworks are in fact using either a homegrown framework or are coding in a way that what they're doing is essentially a de facto framework.
# Posted By Allen | 6/8/09 1:49 PM
 
Home | Blog | Portfolio | Contact | © 2001 - 2007 The ColdFusion Guy - Scott Bennett. All rights reserved.
BlogCFC was created by Raymond Camden. This blog is running version 5.9.