将特征用于服务层：这是不好的做法吗？

Question

我注意到，laravel程序员通常使用特质来在控制器中实现某种类型的依赖注入，而且laravel本身也会使用很多特质来实现对我来说似乎是服务的东西。

我来自symfony，那里的框架本身并没有广泛使用特征，由于这种原因（不是很清晰的设计），我发现使用trait有点奇怪。服务不应该在自己的类中定义吗？将特征用于服务是否可以接受？

Answer 1

我注意到以前的答案尚未被接受，所以我想给自己2美分。

也来自Symfony 2环境，目前正在参与Laravel并为Symfony 3环境做准备，我也正在阅读这个主题，因为我曾经读过特质是邪恶的。以下链接具有一个可接受的答案，在我看来这不是一个很主观的答案，它做出了一些合理的假设，并且似乎构筑得很好：https : //codereview.stackexchange.com/questions/74077/trait-accessing-variables-使用它的类

但是，我认为与您最大的不同可能是默认的Laravel使用ActiveRecord，而不是使用Symfony使用的Service / Repository层。我个人更喜欢后者，因为它不那么笨重，可以更轻松地实现SOLID，逻辑和数据通常已经解耦，从而使各层更易于交换。无论如何，这不是一个话题，而且非常个人化。

在Laravel工作了几个月（相比之下，我在sf2（和sf1）工作了多年），我对Laravel的工作方式几乎不是专家。就我个人而言，我仍然不喜欢特质，因为如果您至少不使用它们，它们对我来说太神奇了。我经常认为通过其他设计模式可以更好地处理它。

TL; DR ：（基本上是链接的要点）

• 特征的一个很好的用例是水平缩放，它支持独立的操作，而不必在每次添加接口时都要实现它的开销。（通常这是相当简单的逻辑）
• 不良是一种特性，它使用超出其自身范围的信息（例如，“主”对象的属性或简单的全局状态），或强制执行/破坏合同。