Using traits for service layer: is it bad practice?

Question

I have noticed that it is common for laravel programmers to use traits to implement some kind of dependency injection in controllers and also laravel itself uses lots of traits to implement something that it seems to me, to be services.

I come from symfony where traits are not widely used from the framework itself and I find it a little bit odd as I find using trait for such a reason, not so clear design. Shouldn't services be defined in their own classes? Is it acceptable to use trait for services?

Answer 1

I noticed the previous answer was not yet accepted so I thought giving my own 2 cents.

Coming as well from a Symfony 2 environment, being involved with Laravel currently and preparing for a Symfony 3 environment I was reading up on the subject as well, as I used to read that traits are evil. The following link has an accepted answer that is in my opinion a not so badly subjective one, it makes some fair assumptions and it seems well constructed: https://codereview.stackexchange.com/questions/74077/trait-accessing-variables-of-classes-using-it

However, I would think the biggest difference for you might be that the default Laravel is using ActiveRecord, in contrast with having the Service/Repository layers that are used by Symfony. I personally prefer the latter, it's less heavy, keeps it easier to be SOLID, logic and data are more often already decoupled, making the layers more easily swappable. Anyway, this is a not-so-on-topic and very personal note.

After working in Laravel now for a couple of months (in comparison, I have worked for years in sf2 (and sf1)) I'm hardly an expert in how Laravel works. Personally I still dislike traits because they feel too magical to me, if you do not interface them at least. I often think it is better handled through other design patterns.

TL;DR: (gist of the link basically)

• A good use case for a trait is horizontal scaling, supporting actions that stand by itself, without the overhead of having to implement it each time the interface is added. (usually this is fairly simple logic)
• A bad one is a trait that uses information out of its own scope (for instance properties of the 'main' object, or simply global state), or enforces/breaks contracts.