Unit Of Work Pattern for Eloquent

[michael-rubel]

I don't know if this topic was discussed in the community previously, but I came across the idea of implementing the class that will handle my Eloquent IUD operations following Martin Fowler's Unit Of Work pattern and native Laravel database transactions.

For example:

function (UnitOfWorkInterface $unitOfWork) {
    $user = new User([
        'name' => 'Test',
        'email' => '[email protected]',
        'password' => bcrypt('password'),
    ]);

    $user2 = new User([
        'name' => 'Test2',
        'email' => '[email protected]',
    ]);

    $unitOfWork->registerAsInsert($user);
    $unitOfWork->registerAsInsert($user2);

    $unitOfWork->commit();
}

The same can be registered for updates and deletes. It's essentially how Doctrine works in the Symfony world:
Every database operation gets queued (and no SQL queries get executed immediately), then if any of the interactions fail during the commit process, everything rolls back, and the data stays consistent no matter "at which stage" it failed.

I've written a basic implementation of the Unit Of Work as a separate class, so it's not affecting Eloquent internally and is fully optional to use. Do you think this topic is worth digging deeper and potentially contributing to the framework? Personally, I see this as a huge benefit. Symfony guys love Doctrine exactly because of this behavior by default. I always wanted to have this in Laravel at least optionally, but supported natively.

[ghost]

Hi. What brings this new to the table vs Eloquent's db transactions and nested transactions? I am just curious, this is not a rhetorical question.

[michael-rubel]

@marius-mcp There's no standardized way of handling such a scenario. Everyone writes a custom transaction logic every time in Laravel while in Doctrine it's just out-of-the-box behavior.

[ghost]

And you want to bring that behavior to Eloquent or you want to bring Doctrine to Laravel? (via a pakage)

[michael-rubel]

I don't want Doctrine, I want to be able to schedule Eloquent models (or Query Builder objects) for insert, update, or deletion at a later stage of the application execution, safely in transaction.

For that, the easiest way is to introduce a separate "EntityManager" class implementation I've called "UnitOfWork" for clarity and alignment with the Martin Fowler's idea.

[ghost]

I understand. No one stops you from doing a package for that. If it is optional, I see no harm.