Soon I’ll have a talk on a local (Budapest, Hungary) meetup with the title Re-thinking the MVC pattern with PHP frameworks (in Hungarian: Gondoljuk újra az MVC-t (PHP frameworkökkel)! ).
I’ll walk through some framework’s MVC impementations and show some MVC spin-off implementations (like Model-View-Presenter etc.). The curve of the talk will lead to a realization that it is common to think of controllers like an endpoint with only one action because of the dependency handling and due to some SOLID principles taken (?too?) serious.
And another approach will be that a lot of MVC framework supports middlewares piped before and/or after the controller’s action so this is something that will be mentioned also.
My question is that is my presumption correct when I say this could straightforwardly lead to the expressive’s middleware pipeline pattern?
As I see, one way or the other we’ll have a class containing(or representing) one and only one action which behaves almost the same and the separation between models’, views’ and some controlling mechanism’s responsibilities will remain also.
I’d really appreciate the Expressive contributors’ and of course everyone’s opinion on this.
Seems about right.
I generally write single-action controllers myself too by implementing an
alternate dispatch listener.
If you look at ZF’s Dispatchable interface (minimal requirement for
controllers), you will see that we were on that path, conceptually, since
2011.
Actually I’m not a fan of ORM’s.
Model is pretty much the thing that the framework should not touch IMHO. It’s about the business, the problem, not about the database, the http stack or whatever hence no exact definition exists for it.
As I see It’s a working solution to define your business logic through repositories but that is just one way to model your business problem.
But honestly, I don’t see how that post is adding anything to this topic so please, explain it a little more.
I’d like to draw a parallel between the middleware pipeline controlling structure and lot’s of other controlling structures (like classic MVC and MVC spin-offs) as a user with as few implementation details as that’s crucial to make myself clear.
It was at least a reminder to make that clear to my audience I won’t talk much about the Model component 
Good point, may be I’ll use it as an illustration of the evolution happening right before our eyes
Allow me to extend the idea rather than explaining it.
When a new user joins your application through a /user POST call (because why in the world would anyone create a user facing PHP application which is not an API?) that user should be sent a welcome email.
Does that mean I need to modify my User resource? No! Add a event subscriber for postCreate and call a repository function with the User entity created in the postCreate as a parameter and use that User entity to enqueue an SendWelcomeEmailJob for the queue. This way no matter how a user is created in the system the business logic is based on ORM events, not relying on the programmer to remember what business logic is needed when a new user is created.
After a sleep I’ve re-read the blog post.
If I’m understanding it correctly it is about having an already implemented (eg. doctrine event manager) observer pattern which gives you a loosely coupled event driven control flow.
Event happens to entity -> Handlers listen and execute business related logic with (but not necessary on) entity model.
It sounds great in theory, only my event imho should not be “postCreated”, but “userRegistered” or “userAdded” or “userInvited”(or all of them with even different behaviour). And now I’m again taking a step further from ORM based business implementation because – as I see – knowing that an entity’s changed state is persisted (and what if I’m using event sourcing?) is not as important as knowing the user’s intention is now claimed to be him being registered in our system. So why would I left the responsibility of controlling the business on the persistence layer? While I’m agreeing with you on having this loosely coupled design with an event based control flow is a good way to go I don’t think that the cornerstones of the controlling mechanism should be the ORM events.
1 Like
Thanks for taking the time for understanding.
In my work the past 5 years I’ve built Doctrine in Apigility and in this the entities are a core component of the overall architecture with HTTP verbs mapped directly to Resource actions which are mapped 1:1 with Doctrine entities.
I feel you’re right that you can’t build a whole system based purely on ORM events but you can build most of a system that way. In an Apigility application you’ll need RPC calls for some of the work; for instance turning off POST & PATCH on the User resource and handling user lifecycle calls through RPC. But for much of the rest of the application you can rely on ACL and, for Doctrine in Apigility, Query Providers.