I've been developing applications for a short time, from small to medium size codebases with many different features, requirements and environments. For all these applications I've always found the issue about the frameworks, sometimes this discussion takes days, or even weeks if the people involved is very passionate about Rails, Hibernate, JSF, CDI, and some others.

Mostly the discussions tend to be related to the benefits a framework can give us: speed, conventions, less coding, design improvements, being cool....

And for some projects the right frameworks have been a blessing, improving the developer experience and reducing development effort. But that's not always the case, because sometimes the frameworks can lead you to think that 'their' way to do it is the 'right' way.

'Their' way to do it can be 'right' for their intentions, but your application is not meant to be based on their intentions, but your customer ones. A framework should not define how your application is structured, how your business logic is wired, and not even how your tests are written.

I've always struggled with testing on a framework, because most of the times the requirements for its setup are so large, that makes you feel sick. And it's even worse if you are tied to certain technology because your customer has bought the 'sweetest' license in the market.

But well, here's my summary about frameworks:

Advantages

  • Speed, not always, but a lot of frameworks are performance-oriented.
  • Support, if it's open source, you will have a lot of it.
  • DRY, yeah, you don't reinvent the wheel.
  • Convention over configuration, very powerful, and saves lots of efforts.

Disadvantages

  • With bad design decisions, you can marry your code with a framework, and that marriage is an ugly one
  • Performance, as said, not all frameworks are performance-oriented.
  • Test difficulty, you mean that I have to setup the entire framework stack in order to test a single operation?

When to use them

  •  It's rare to find a reason not to use a framework, I would say that the question is not 'when to use a framework?', but 'how my application should be designed in order to be framework-agnostic?'.

When not to use them, or at least think twice before using them

  • When its usage doesn't give you any advantages
  • When you have a 'contractual' boundary with it
  • When your team dislikes it
  • When your tests take more than 10 seconds to setup its environment
  • When the framework itself is untestable
Based on: Architecture, the lost years - Robert C. Martin