Spin off from #1801356: Entity reference autocomplete using routes. That issue surfaced a debate on whether route controllers (the _controller and _content values of routes) should reference explicit classes, for example, this snippet from edit.module's routing file:
edit_field_form:
pattern: '/edit/form/{entity_type}/{entity}/{field_name}/{langcode}/{view_mode}'
defaults:
_controller: '\Drupal\edit\EditController::fieldForm'Or, whether they should reference services, as in this snippet from views_ui.module's routing file:
views_ui.list:
pattern: '/admin/structure/views'
defaults:
_controller: 'views_ui.controller:listing'Where views_ui.controller is a service registered in ViewsUiBundle::build().
In #1801356-62: Entity reference autocomplete using routes, Dries requested that in core, we pick one approach, instead of mixing them. Since both are supported by the Symfony routing system we're using, contrib can choose to use either, but this is about improving DX in core by standardizing.
The main benefit of registering controllers as services is that dependencies can be made explicit. For example, the ViewsUIController above has a constructor that receives an EntityManager, a ViewsDataCache, and a TempStoreFactory. Anyone reading that code gets immediate knowledge of that, and anyone writing code to use ViewsUIController (for example, a unit test) can quickly figure out what that class requires to be injected into it. Whereas, the EditController that isn't a service has no such constructor, so the only way to know its dependencies is to open up the code and scan for wherever $this->container->get() is called.
However, this benefit is of less value than with our other services. Because the entire point of controllers is to *only* be the glue code between a route and a response. Any reusable functionality needed in that process should be implemented by a different class, and one that is a service. So, there's little value in catering to someone who wants to work with a controller outside of its routing context. I would even suggest that controller unit tests are of minimal value and we shouldn't have any. We need to unit test the underlying services used by controllers, and we need to functional test routes. If we do both of those, unit testing controllers is pretty pointless.
The main concern of registering controllers as services is adding weight to the DIC. The DIC needs to be loaded on every page request, and Drupal sites might commonly have hundreds/thousands of routes/controllers. However, we don't yet have enough of Drupal converted to the new routing system to evaluate this empirically.
Discuss.