Form request vs Service

1. Do Actions have a different purpose compared to Services and Jobs, because especially if a Job is synchronous then all the above seem like the same thing to me.

2. What is your opinion about the logic within the addParticipants and addMessage methods. Is it ok to have the logic for creating and firing an event in those methods or it would be better to call an Action again ?

public function addParticipants(array $usernames, $admin = false)
{
    (new (AddParticipantToConversationAction($this, $usernames, $admin))->handle();
}

public function addMessage($message, $user = null)
    {
        (new(AddMessageToConversationAction($this, $message, $user))->handle();
    }

One downside with this approach though is that i might end up with too many Action classes

@orest I have a love–hate relationship with commands/sync jobs/actions because, as you’ve rightly pointed out, they’re all the same thing in practice. Laravel introduced commands and handlers in Laravel 5.0, and by 5.1 they were renamed to “self-handling” jobs.

It’s up to you have far you abstract your actions logic. If you need to add participants and messages independently of creating a conversation, then it may make sense to have AddParticipantToConversation and AddMessageToConversation actions. You can then just type-hint them in the CreateConversation action class to re-use them:

class CreateConversation
{
    protected $addParticipants;
    protected $addMessage;

    public function __construct(
        AddParticipantsToConversation $addParticipants,
        AddMessageToConversation $addMessage
    ) {
        $this->addParticipants = $addParticipants;
        $this->addMessage = $addMessage;
    }

    public function handle(array $data)
    {
        $conversation = Conversation::create(Arr::except($data, [
            'participants',
            'admin',
            'message',
        ]));

        $this->addParticipants->handle(
            $conversation,
            $data['participants'],
            $data['admin']
        );

        $this->addMessage->handle($conversation, $data['message']);

        NewConversationWasCreated::dispatch($conversation);

        return $conversation;
    }
}

Again, the container will resolve the dependencies in the action’s constructor, if the container is resolving the action itself (i.e. by type-hinting it in a controller method).

@orest Yeah, exactly :)

I’d have the action create the required models based off of validated data. You can then optionally dispatch an event that can do any supplemental work such as notifying participants that don’t need to be done as part of the request itself.

@michaloravec

Thanks for the suggestion.

I have watched this series, that's where i got the method name persist

Form requests are an option of course but i think ( i am not sure ) that then it will have too many responsibilities.

1. Authorize
2. prepare for validation and Validate
3. create conversation , add message, add participants
4. fire event that conversation was created

Is it me ? or all the steps above are too many for a form request object ?

Yeah, the form request should validate the data, but then the controller should actually process the request once you’ve deemed it valid.

@martinbean You don't agree in in general with the following approach ?

class ConversationController extends Controller
{
      public function store(CreateConversationRequest $request)
      {
                 $request->persist();
       }
}

To me it looks the same with using a an action class with the difference that you don't pass the validated data as a parameter.

class ConversationController extends Controller
{
      public function store(Request $request, CreateConversationAction $action)
       {
                 $action->handle($request->validated());
       }

}

My concern about the form request was more about the fact that it will have to create not only the conversation, but also add a message and a participant.

Not really, because the logic’s not usable outside of that request class now.

It’s also intrinsically linked to a HTTP request, which makes testing the logic of creating a conversation more difficult.

Ok..i get your point, except for the testing part

How does it make it more difficult ?

In a feature test for example, you just want to test that when you hit that endpoint, there will be a conversation record in the database.

You handle a form data, so conversation, add message and add participants can stay together in form object. Only event I would move to the controller.

@orest Because testing the logic of creating a conversation shouldn’t come with the overhead of creating a valid HTTP request first.

It also doesn’t change the fact that you can’t use that logic outside the request either, i.e. an Artisan command or queued job.