Using Contracts in Laravel Lucid context - php

Question

Using the great Lucid structure thing have a question:
what about the storage abstraction and using something like contract with several implementations?
For example, Shopping Cart functionality.
When user logged in, shopping cart data should be stored in a database.
When user logged out, the data storing in the session.
So, there is an option:
create set of jobs named, for example, Eloquent:
App\Domains\Cart\Jobs\Eloquent\AddToCartJob,
App\Domains\Cart\Jobs\Eloquent\FlushCartJob
...
similarly create other set of jobs, Session:
App\Domains\Cart\Jobs\Session\AddToCartJob,
App\Domains\Cart\Jobs\Session\FlushCartJob
...
But how to switch between each of jobs set depends of the condition: user logged in or no?
It looks like should be some kind of the repository, inside each of methods should be used some job(s) from first or second set.
Some kind of:
//...
use App\Domains\Cart\Jobs\Eloquent\AddToCartJob;
class EloquentCart implements CartContract
{
//...
public function addToCart(array $data)
{
//...
return $this->run(new AddToCartJob($data));
}
}
and:
//...
use App\Domains\Cart\Jobs\Session\AddToCartJob;
class SessionCart implements CartContract
{
//...
public function addToCart(array $data)
{
//...
return $this->run(new AddToCartJob($data));
}
}
in the AddToCartFeature:
//...
class AddToCartFeature extends Feature
{
//...
public function handle(Request $request, CartContract $service)
{
//...
return $service->addToCart($request->all());
}
}
and, finally, using of contextual binding with condition is user logged in?.
Is it normal solution or contract-implementation should be developed by another way in Lucid context? Is it normal practice to create one more layer between Feature and Job, or exists another way to switch between implementations?

Answer 1

When it comes to abstraction and design patterns it is recommended that they exist within the code rather than in Lucid's components (Feature, Operation, Job); keeping the architecture in the periphery rather than the foreground of your code.
Your multi-repository approach is a great starting point. Assuming you have:
App\Data\Repositories\CookieRepository
App\Data\Repositories\DatabaseRepository
Now we can have two separate jobs, each accessing the corresponding repository:
Cookie
App\Domains\Cart\Jobs\AddToCookieCartJob
App\Domains\Cart\Jobs\FlushCookieCartJob
Eloquent
App\Domains\Cart\Jobs\AddToDatabaseCartJob
App\Domains\Cart\Jobs\FlushDatabaseCatJob
This ensures that jobs remain atomic and are named explicitly for what they do. This helps when skimming through a Feature or an Operation to know what we're doing without having to check namespaces and get confused with similar job names, or having to deal with namespace aliases (see more on Jobs in the docs).
Now that we've established the groundwork, we'll need to call these jobs depending on the logged in? condition. Given that features shouldn't deal with the intricacies of the units of work, this would be a greate place for an Operation.
App\Operations\AddToCartOperation
if logged in → AddToDatabaseCartJob
else → AddToCookieCartJob
Same goes for App\Operations\FlushCartOperation
Now our Feature won't have to know these details, just run the operation:
class AddToCartFeature extends Feature
{
//...
public function handle(Request $request, CartContract $service)
{
//...
$status = $this->run(AddToCartOperation::class, [...]);
//...
return $this->run(SomeOtherJob::class, compact('status'));
}
}
As for the rest of the code, you may use any design patterns that fit your case.
The names above are only for the example, please rename according to your conventions.
I hope that I've understood your question correctly and that this answer helps!