We really need to rename entity controllers. "Controller" is "callable that the Kernel calls", basically formerly "page callback". Like "bundle" that's an inherited term from Symfony so we cannot really change it.

In code, the storage controller is just 'controller class'. In some comments that is also true, in others it is 'storage controller'.
That was fine when it was the only controller, but now that we have list and form, do we want to specify?
And if so, is that a follow-up, or just something we should do once so that anyone tracking HEAD doesn't have to rename it twice?

Notice the word "class" doesn't appear anywhere above, both for brevity, and so that if in the future we want to support the values being either class names or service ids, then we can do so (it's not hard for PHP to find out if a string is a class name or service id).

Because all of the renames are rather tedious, here's a patch that does just the changes to the annotation structure, without the actual change from handlers to controllers.
I'd like to see this get in first, and the renames can be handled in a separate patch.
This is a DX win on its own.

Retitling to aid committers. See #24 for what it will look like when the next part is done.

Not even sure whether we need to rename from controller to handler.

We currently have Drupal\system\CronController, which is a controller in the Symfony sense. But the Symfony controller for User module is named Drupal\user\UserRouteController to disambiguate from all the other nothing-to-do-with-routing entity controllers in the same namespace. I think renaming the entity ones to handlers still makes sense.

We currently have Drupal\system\CronController, which is a controller in the Symfony sense. But the Symfony controller for User module is named Drupal\user\UserRouteController to disambiguate from all the other nothing-to-do-with-routing entity controllers in the same namespace. I think renaming the entity ones to handlers still makes sense.

I think we're shooting ourselves in the foot with trying to disambiguate any terminology.

IMHO, the proper answer is namespaces:

If you provide a controller for entities, why don't you tell me so? Drupal\foo\Entity\FooController.

If you provide a controller for routing, why don't you tell me so? Drupal\foo\Routing\FooController.

The Symfony bundle convention is BundleName\Controllers\ThingieController.

It's just a code ambiguity question, though. It's also just normal conversation. "Do a thingie and add a Controller and modify the framistan". Which controller? Anyone who doesn't already know Entity API is going to think of the "thing formerly called page callbacks", and then when they see something else is also called a "controller" is going to go "WTF?"

I really love this patch quite a lot. However, since it's purely API clean-up, and also touches every single entity which provides a high likelihood of conflicting with feature patches, I'd rather wait until after Feb 18 to commit this, I think.

Of interest to the folks subscribed here :#1920498: Have rdf.module only act on renderable entities needs the EntityManager to be able to answer "does this entity type have a 'foo' controller ?" without a) actually instantiating the controller b) raising an exception as a means to say "the answer is no".

The exceptions that are thrown by the entity manager can now be quite confusion to people who've never seen them before, as a missing storage controller exception reads "The entity (...) did not specify a storage" (the word "controller" is no longer there).