The more I read about frameworks, the more people seem to complain that they're not worth the time to learn.
Is there a specific use-case that I should be aware of that makes frameworks valuable? Or am I just wasting precious time learning something that I will later on abandon?
EDIT: changed title for clarity. Oops, sorry.
What good are frameworks?
If you choose the right one, it's solid code that you don't have to write. It's better than the stuff you'd do on your own. It's written by developers who are more talented than you are, tested by a wider audience than your code is, has a longer history of fixed bugs than your application has, and has a longer, better track record than anything you've written.
Your application is better off if you can find a framework that meets all those criteria.
Frameworks aren't equal. It's important to choose wisely and well. If you pick a good one, you won't abandon it later on.
That's why I've been using Spring for the last five years.
I would recommend learning the framework before you use it on a live project. You're likely to do a poor job with a framework that you don't know - which will be a convenient excuse to blame the framework. Get some training and do a dry run on something significant before you turn it loose on your first live project. Get a mentor or leader to guide you through your first effort.
On second reading, I'd say it sounds like you've made up your mind. No one is forcing you to use a framework. By all means, do roll your own. Develop enough experience to decide for yourself.
But if there are teammates, employers, or clients affected by the decision make sure that they have a full understanding of the opportunity cost of rolling your own.
We make extensive use of Enterprise Library in our projects. People who complain too much about frameworks are the types that want to build everything from scratch. Having a solid framework that handles the aspects of what you are doing (exception handling, logging, caching, data access, policy injection, unit testing, dependency injection, monitoring and instrumentation, encryption, etc.) are extremely valuable.
A good framework will let you concentrate on your business issues rather than the aspects of your application that are orthogonal to what you are actually trying to accomplish. Also, it is an absolute waste of time to write those things yourself, when outstanding frameworks with thousands of man-hours in development and QA and possibly hundreds of thousands of production hours are out there. I can justify 100% the business case for using EntLib.
In the beginning it may seem quicker to start without a framework.
I compare it to loading a dishwasher. You'll have to do the work the work sooner, or later. Either you load the dishes in an organized way beforehand, or take the time to sort it out when taking it out.
As you build, deploy, extend your project, you will increasingly wish for / start building in ways to increase code re-use, structure, and framework.
See if there's a framework that you can start quickly building with. I think it's worthwhile.
I find that when doing a large project, even if you decide to not use a framework to begin with, halfway through the project you will end up writing a mini framework anyway as you reuse functions written for one part of the project for another.
The problem with this though is the mini ad-hoc framework you end up writing will be
Using a framework when beginning your project on the other hand will:
I think for any medium sized or larger project, using a framework (if a good one is available) is a huge time saver, as long as you are given a enough time to actually learn how to use it. I often think a lot of the criticisms of frameworks come from people who were never given the time to learn how to use it properly. Trying to use a framework then is quite painful, as you will end up constantly using hacks to get around non-existant problems, problems you wouldn't even have if you knew the framework properly.