Support the ongoing development of Laravel.io →
Packages Architecture

This is one of the biggest conundrums that I face whenever I am extending my company's internal micro PHP framework on top of Laravel.

An example scenario would be, for example, a feature is being added which automates cascade delete through the Eloquent ORM.

Now many of the ORM features can be tweaked through use of properties on the model. Few of those configurations have an explicit interface or trait or combination of both required.

I had a hard time justifying the overhead for the devs to actually attach an interface to get the relations to be deleted and include a bootable trait to handle the deletion event logic.

Alternately the devs suggested that I just put the logic in the extended base model class and define a property to store the relations to be deleted. So as to conform with the already established scheme for the ORM.

Though I am of the view that interfaces in this case serve as a more visible and accountable way to add the needed functions for a feature to work. They also reduce bug chances in some cases. While the traits serve to separate the feature logic from the class.

Can someone advise through their experience? Or the currently accepted Laravel way?

Last updated 3 years ago.
0

Sign in to participate in this thread!

PHPverse

Your banner here too?

brazenvoid brazenvoid Joined 16 Sep 2014

Moderators

We'd like to thank these amazing companies for supporting us

Your logo here?

Laravel.io

The Laravel portal for problem solving, knowledge sharing and community building.

© 2025 Laravel.io - All rights reserved.