标签：#eloquent

Sometimes you need tags on a model. The usual answer is a tags table, a pivot, a slug and a belongsToMany , and you write it again in the next project with slightly different columns. Laraterms replaces that with a config entry and a trait, and it comes with the parts you normally bolt on later: hierarchy, per-tenant isolation and translations. This is the simple path first, then the two features you reach for next. How to install One package, its config and two migrations. composer require edulazaro/laraterms php artisan vendor:publish --tag = laraterms-config php artisan vendor:publish --tag = laraterms-migrations php artisan migrate Step 1: define a taxonomy A taxonomy is a kind of label, declared in config/laraterms.php . Start with a flat tags taxonomy; the file already ships one you can keep. 'taxonomies' => [ 'tags' => [ 'hierarchical' => false , 'max_terms_per_model' => null , 'scope' => 'tenant' , ], ], Step 2: tag a model Add the HasTerms trait and the model can hold terms. Attaching is find-or-create: pass a label, and the term is created the first time and reused afterwards. use EduLazaro\Laraterms\Concerns\HasTerms ; class Post extends Model { use HasTerms ; } $post -> attachTerm ( 'Laravel' , 'tags' ); $post -> attachTerms ([ 'Laravel' , 'PHP' ], 'tags' ); $post -> syncTerms ([ 'Laravel' , 'Vue' ], 'tags' ); // replace the tag set $post -> termsIn ( 'tags' ); // read them back Filtering by tag is a query scope, so it composes with the rest of your query. Post :: whereHasTerm ( 'laravel' , 'tags' ) -> get (); Post :: whereHasAllTerms ([ 'laravel' , 'tutorial' ], 'tags' ) -> get (); Hierarchical categories Set hierarchical => true on a taxonomy and its terms form a tree. Read the whole tree in one query, and walk a term's ancestry. 'categories' => [ 'hierarchical' => true , 'max_terms_per_model' => 1 , 'scope' => 'tenant' , ], use EduLazaro\Laraterms\Support\TermTree ; $tree = TermTree :: for ( 'categories' ); // roots with children, one query $term -> b

Most Laravel teams do not need to "fix" Eloquent. They need to stop letting raw model state leak too far into code that makes real business decisions. That is the practical version of this debate. Typed objects around Eloquent can be a big improvement, but only when they are used as boundaries . If you push the pattern too far, you end up with a second object model shadowing the first one. At that point you are not improving Laravel. You are building a parallel ORM that adds mapping code, cognitive load, and friction on every change. So the right question is not, "Should we replace Eloquent with typed objects?" The right question is, where does untyped Eloquent stop being cheap? Once you frame it that way, the migration path becomes much clearer. Keep Eloquent where it is good at persistence, hydration, scopes, relationships, and query composition. Introduce typed objects where the shape is messy, the values carry business meaning, or invalid combinations are too easy to represent. That is the version that pays off. The Core Recommendation If you only remember one thing from this article, make it this: add typed boundaries around unstable or meaningful data, not around every model . That usually means one of four cases: a JSON column that multiple parts of the app interpret differently domain values like money, status, addresses, or billing configuration data crossing from Eloquent into services, jobs, or integrations code paths where stringly typed state has already caused confusion or bugs Everything else should be guilty until proven useful. This is where a lot of teams go wrong. They see a good example of typed objects and immediately generalize it into an architecture rule. Then every model gets a FooData , FooView , FooState , FooRecord , and FooMapper . The app becomes more "designed" and less understandable. A Laravel codebase does not get better because it has more classes. It gets better because responsibility becomes clearer . Why Raw Eloquent Starts Hurt