jeudi 5 mars 2015

Is "Command Bus" design pattern really usefull, and should we use its Laravel 5 implementation?

I'm digging into Lalavel 5 Command(bus). I was refactoring some code, and I'm at some point where I'm wondering if it's useful to use it (command bus).


In Laravel 4, I was using laracasts/validation package to clear my controllers.


I know this package and Laravel5's "command" don't do the same thing, but, inside the make() method (from laracasts/validation services's class) I wrote all the logic to fire event, create database records, etc. When Jeffrey presented his CommandBus package in the screencasts, I understood that in 1 command, we can tackle multiple handlers, and it looks like this was a mistake.


In Laravel 5, it looks like we are limited to 1 handler, so at this point, I'm wondering (and that's my questions) this :




  1. What's the benefit to use "Command" in L5, instead of a App/Services class , and fire 1 event into this service, which can handle multiple "event handlers" ?




  2. In that case (only if I'm right on 1st point), why this design pattern is so popular. It actually limit the developer to 1 handler.




  3. For "ShouldBeQueued" commands, what are they more than a \Queue::push alias (for its handler class) ?




  4. If I'm not on the wrong way with my 3rd point, it's not a good practice to tackle your queue jobs inside of your controller, so why it should be a good thing if we name it Command Bus ?




Aucun commentaire:

Enregistrer un commentaire