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.
However, there are probably also a plenty of people like myself, who understand Object Oriented Programming (OOP), Aspect Oriented Programming (AOP), Model-view-controller (MVC) architecture, etc, and have spent time evaluating various frameworks, but still decided not to use them some reason or another. I personally have always employed a MVC architecture to any application that I build from scratch. I keep my code well organized, and anyone who understands MVC concepts would have very little trouble figuring out my code.
A couple years ago, I looked at Fusebox, and Model-Glue, and I decided that I liked certain aspects of them, but neither one was what I needed for the particular application I was developing. I decided instead to employ my own MVC architecture and it worked out great. The code runs super fast, it scales, is easily maintainable, and my client is happy.
Yesterday, in effort to be a "better" programmer, I re-evaluated Model-Glue. I installed ColdSpring and Mode-Glue on my test server, and I followed start up tutorials and developed the pig latin translator application.
I then decided to build the same Pig-Latin translator application using my normal MVC architecture.
In the attached zip file (click the download link below), you will find 2 folders. In the "translator" folder you will find the model-glue version of the application, in the "translator2" folder you will see how I programmed the same application using my normal architecture. Basically the way I do things is that all requests go to /index.cfm, then I use application.cfc onRequestStart and onRequest methods to run interference and determine the action/event that is occurring. It then calls the appropriate controller CFC. The controller interacts with the CFC's in the model folder as necessary, and determines which views need to be used to display the response to the user.
For this particular application everything is fairly simplistic but it can be built upon for more complicated applications. I have left several comments in my code to kind explain how I do things. In application.cfc, instead of just deleting all the unneeded functions, I commented them out with hints as to how I would use them in different situations.
Also, I updated the Pig-Latin translator CFC in the translator2 model folder so that it can actually translate phrases instead of just one word.
I think that frameworks definitely have a valid purpose, and are extremely useful when there are a lot of developers involved in a project. It is easier for everyone to work together when they all program the same way. I think that they can be helpful to people who may not have a good idea yet on how to organize their code on their own. It definitely makes the code easier for other developers to come along after your gone and maintain your code as long as they are familiar with the framework you employed.
However, I feel that my application architecture is just as organized and just as maintainable as it would be if I used a framework. I think that anyone who could maintain code written in any of the major frameworks, can just as easily maintain my code too. On the same token there is not a single framework out there that I could not figure out and start using within a few weeks. My application architecture follows the same basic principles as most of the popular frameworks use, but I don't have to have a bunch of processing that my application doesn't need.
So, I want to hear your thoughts... am I not as good as you because I choose not to use frameworks? If I choose to make my next three applications in Fusebox, Model-Glue, and Mach-II, despite the fact that it will probably take me a lot longer, will I be a better programmer in your opinion?
If I take my typical MVC application architecture, document it, create a website, start a steering committee, and write a book on how to do things my way, will I then be a better developer because I use a framework?
If you are looking for an experienced, professional, and reliable ColdFusion development company, contact PALADEM today.
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.
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.
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.
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.
@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.
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.
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!
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.
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?
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.
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
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.
Which framework do you feel is best suited to a high-traffic multi-server e-commerce application?
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.
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?
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?
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.
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 =)
One day someone will inherit your application and will go 'WTF?!?'
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.
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.
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.
- 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.
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.
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.
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.
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).
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.
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 :-)
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
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.
@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.