Glossary

Framework

A framework controls the main application flow and calls application code at defined points. It is not a programming language, a finished product, or an automatic guarantee of good architecture.

Short definition

Conventions and an application lifecycle on a shared foundation.

A framework provides structure for recurring problems: routing, creating a controller or presenter, dependency injection, configuration, validation, forms, security integration, or returning an HTTP response. The team therefore does not start every application by building the same infrastructure layer from scratch.

The crucial difference from a library is inversion of control. An application usually calls a library directly; a framework manages the lifecycle and calls application code at the appropriate time. The boundary need not be absolute—for example, Symfony provides both a complete framework and independently usable components.

The problem it solves

It gives a team a repeatable way to build an application

A framework is useful when an application handles HTTP, data, security, and continued feature development over the long term.

routing a URL to a controller or presenter
creating and configuring services through dependency injection
validating input, forms, and error responses
security components, console commands, and database integrations
conventions for tests, packages, configuration, and application extensions

Practical example

The framework coordinates input; a service enforces the order rule

In an administration interface, the route for cancelling an order leads to a controller or presenter. It reads the request, verifies the user context, and passes the intent to an application service. The service decides whether the order can be cancelled and returns a result that the framework converts into an HTML or JSON response.

A business rule should not automatically be written in a controller, ORM model, or job merely because the framework makes it convenient. The framework coordinates execution; domain and application boundaries are separate design decisions.

HTTP request
  → routing
  → controller / presenter
  → aplikační služba
  → HTTP response

How it works

From a request to application code and back

This simplified flow applies to a typical HTTP application; specific names vary between frameworks.

Entering the framework The web server passes the request to the application, and the framework establishes the necessary context.
Routing The framework evaluates the URL and method and selects a controller, presenter, or other handler.
Services and middleware The container provides dependencies; middleware or listeners can handle shared technical steps.
Application rule Application code works with data and rules; the controller should coordinate input and output, not absorb the entire process.
Response The framework builds HTML, JSON, a redirect, or another result and returns it to the web server.

Important parts

A framework simplifies recurring technical patterns.

However, it does not enforce sound business-logic boundaries by itself.

Routing and lifecycle

Routes an HTTP request into the application and determines when custom code runs.

Dependency injection

The container creates services and their dependencies. This does not mean every class needs an interface or abstraction.

Configuration and extensibility

Conventions speed up the introduction of common features. Plugins and packages, however, add dependencies that must be maintained.

Security and data integrations

A framework may offer tools for validation, CSRF, sessions, or databases, but correct use remains the application’s responsibility.

Components

Some parts of a framework can be used independently. That does not mean every application needs the entire framework.

Benefits and limitations

Conventions save work but create a commitment to the ecosystem.

Benefits

a unified way of working with HTTP, services, and configuration
using maintained components instead of rebuilding infrastructure
faster onboarding and a clearer structure for the team
integration of tests, console tasks, and security practices

Common mistakes

treating a framework as a substitute for knowledge of PHP, HTTP, and databases
putting all logic in controllers, models, or jobs
depending on framework classes even in the core of domain rules
deploying a robust framework for an isolated script without a long-term reason

When it makes sense

For long-lived applications with recurring infrastructure.

Symfony, Laravel, and Nette suit different teams and existing projects. They cannot be ranked universally from best to worst; the product, team experience, required integrations, maintenance, and chosen working style determine the decision.

A small script or narrowly scoped task may need only a few libraries. Once an application handles HTTP, data, permissions, configuration, and several features, the shared structure of a framework usually pays off.

What to consider

A framework should support simple code, not hide complexity.

Choosing a framework begins ongoing maintenance; it is not a one-off decision.

keep a controller or presenter focused on coordinating input and output
separate stable business rules from unnecessary coupling to the framework
update the framework and its dependencies in a controlled way with tests
use security components while verifying their specific configuration
choose the degree of abstraction according to application complexity

Common questions

Frameworks without misleading shortcuts

What is the difference between a framework and a library?

An application usually calls a library. A framework controls the main application flow and calls application code at defined points.

Is Symfony a framework or a component library?

Both: Symfony offers a complete framework as well as independently usable Components. It depends on which part of the ecosystem the project uses.

Is Laravel or Nette the better framework?

There is no universal ranking. The project’s needs, team, existing system, ecosystem, and long-term maintenance determine the choice.

Does a framework guarantee clean architecture?

No. It helps with technical structure, but the team must design responsibilities, dependencies, and business rules.

How I work with PHP in practice

I use a framework as a foundation for a maintainable backend.

In current PHP projects, I build on Symfony and its ecosystem while always considering an architecture appropriate to the particular application.

How I use PHP in practice Discuss your project without obligation