Best Practice: Service Classes, Model methods or Filament Resources?
In the effort to keep my Models as slim as possible, I've been building up a stable of Service classes and dumping my business logic / factory methods in them. The problem is, I feel like I'm writing some smelly code, because I'm strongly binding my Services to instances of their associated Models, and so much of it feels like I'm just adding extra code for no real value - if a method only makes sense in the context of an instanced Model, then should I just bite the bullet and make it a method of the Model class?
But in the midst of all this, I've also been thinking about Resources - in a sense, they're built in Service classes, and while they're not bound to a specific instance of a Model, maybe that's ok - if there's going to be a dumping ground of static methods that all accept Model instances as parameters, why not use the Resources we already have, instead of inventing a whole new layer of Service classes?
I'm just wondering how other people tackle this overall concept. When you look at stock Laravel suggestions, it's always "use Services and Repositories!", but so far my attempts to follow suit in Filament don't really feel like they're solving any problems, just adding more code with no benefit. Any advice?
1 Reply
For the record here, I've started experimenting with using DTOs (https://spatie.be/docs/laravel-data/) to pass around rather than concrete objects, and it's feeling a lot cleaner - it lets me shunt around a single object instance, knowing that if it doesn't have what it needs when it gets to the furthest reaches of the code train, that there's only one place that additional values need to be added. Far fewer DB queries overall, and code that needs to know a lot less about my Models.
Introduction | laravel-data
laravel-data