我正在寻求澄清是否将代码放入控制器，实体或提供服务。
我有'cardset'和'card'对象（其中许多后者嵌入在前者MongoDB中），由普通的PHP类/对象表示。它们包含例如属性'id'，'postal_address'。
我有一种生成卡片PDF的方法。目前我在'Card'对象中有这个，所以从我可以调用的控制器：
$card->makePDF()
这对我来说似乎很干净，但我怀疑我错了。
如果我把控制器中的所有逻辑放得很长而且不实用，而且我不确定控制器是否可以作用于我的对象的方法。那是什么服务？
尝试总结：如果一个对象知道它可以对自己做的所有常规事情并将它们作为成员函数包含在其中，或者其他地方的方法应该通过该对象来进行操作。如果是这样，那些方法应该保留在哪里？
我很确定它不是'存储库'，因为这似乎有助于检索/存储实体。
谢谢！
答案 0 :(得分：7)
PDF生成应该是服务，而不是对象的方法。
通常，特别是在Symfony2中，模型应该只用于存储数据。控制器用于操纵模型之间的关系，而视图用于以人类或计算机可读的形式表达数据。服务适用于不适合上述任何内容的事情 - 与您的Web应用程序状态无关的事情。
一个很好的例子就是发送电子邮件。电子邮件包含数据（模型）。用户已发送电子邮件（控制器）。电子邮件看起来有某种方式（查看）。但是，实际发送电子邮件的行为与Web应用程序的状态无关（所有服务都知道是否要求将此电子邮件发送给这些人）。因此，有一个独立的服务只处理发送电子邮件是有道理的。
同样，生成PDF文件的行为与Web应用程序的状态无关。 PDF生成器不需要知道您的应用程序中发生了什么，它只是知道它被要求制作PDF。
答案 1 :(得分：6)
Symfony2不是MVC结构（正如Fabien本人所说），正是因为它给出了所有V（树枝）和C（控制器），但没有给出M部分。 M部分是“免费”的，可以随意构建。
有一个主要的困惑，人们“认为”主义是模范。但事实并非如此。我们所做的是Bundle中的两个目录，一个叫做Doctrine-ODM类的“Document”，另一个名为“Model”，其中包含“业务逻辑”。
我个人认为$ card-＆gt; makePDF（）是有道理的......
但$ card应该是一张“模型卡”，它继承或拥有一个基础对象“数据卡”，这是一个学说类。
您可以使用继承，或使用接口，创建者或任何您想要将“模型卡”与“数据卡”相关联，但关键是“学说不是商业模式”，它只是一个持久层并且您的模型是“普通类”，您可以构建它们以将数据包装在内部并使控制器使用模型而不是数据。
答案 2 :(得分：2)