Should we use a framework?

Posted on by Matthias Noback

Since I've been writing a lot about decoupled application development it made sense that one of my readers asked the following question: "Why should we use a framework?" The quick answer is: because you need it. A summary of the reasons:

  • It would be too much work to replace all the work that the framework does for you with code written by yourself. Software development is too costly for this.
  • Framework maintainers have fixed many issues before you even encountered them. They have done everything to make the code secure, and when a new security issue pops up, they fix it so you can just pull the latest version of the framework.
  • By not using a framework you will be decoupled from Symfony, Laravel, etc. but you will be coupled to Your Own Framework, which is a bigger problem since you're the maintainer and it's likely that you won't actually maintain it (in my experience, this is what often happens to projects that use their own home-grown framework).

So, yes, you/we need a framework. At the same time you may want to write framework-decoupled code whenever possible.

Dynamically changing the log level in Symfony apps

Posted on by Matthias Noback

This is just a quick post sharing something I was able to figure out after doing some research.

The situation: our application throws exceptions by means of "talking back to the user". As developer we don't want to be notified about all these exceptions. They aren't as important as any other exception that should be considered "critical". Still, we do want to find these exceptions in the logs, because they can sometimes provide valuable feedback about the usability of the system.

A simple recipe for framework decoupling

Posted on by Matthias Noback

If you want to write applications that are maintainable in the long run, you have to decouple from your framework, ORM, HTTP client, etc. because your application will outlive all of them.

Three simple rules

To accomplish framework decoupling you only have to follow these simple rules:

  1. All services should get all their dependencies and configuration values injected as constructor arguments. When a dependency uses IO, you have to introduce an abstraction for it.
  2. Other types of objects shouldn't have service responsibilities.
  3. Contextual information should always be passed as method arguments.