在我的symfony应用程序上，现在是添加邮件程序功能的时候了。我总是意识到一些新的功能有理由进入它自己的捆绑。现在我想添加一些邮件程序功能，以便用户可以检查一些选项，然后将项目发送给朋友。
提前考虑，我也可以在同一个应用程序中使用该功能，这是该网站的另一部分。所以我想，我可能想把一个电子邮件控制器放在自己的包中，但我知道swiftmailer包已经在做这个了，我将使用它。
所以最后我认为它可能只需要几行代码，而且可能最好放在网站特定部分的控制器上，我需要电子邮件功能。
现在出现的主要原因是我想让它成为自己的捆绑包，电子邮件正文的twig模板。我是否希望这些模板在我的其他捆绑中徘徊？我想这会有意义。
有什么建议吗？
答案 0 :(得分：1)
为几行代码创建一个包看起来有点过分。
对于你的twig模板，你可以将共享模板部分放在app / Resources / views中，这是所有应用程序共享的。并将特定于域的模板放在特定于域的捆绑包中。 http://symfony.com/doc/current/book/templating.html#template-naming-locations
无论您的电子邮件逻辑代码应该包含在快速邮件服务器中，如果您需要切换邮件策略，例如使用HTTP API发送邮件，您只需要更改此服务，而不是所有控制器。< / p>
如果你有一些代码可以在你的软件包之间共享，你可能应该有一个包含所有“单一”服务的{App | Main | Core | ...} Bundle，如果需要，可以稍后在他们自己的软件包中移动
无论如何，他们对你的全球问题有很多方法：
您可以使用包含所有业务逻辑的单个捆绑包，并将您的技术/通用内容外部化/解耦为可在您的应用之间共享的捆绑包
你可能有一个相反的方法，一个捆绑技术的东西和许多捆绑的业务逻辑，可能更难保持低耦合
或两者兼而有之
在我看来，第一种方法适用于简单的应用程序，而第二种和第三种方法可以更适合更大的应用程序。最重要的可能是一致的。