新的symfony捆綁，何時

Question

在我的symfony應用程序上，現在是添加郵件程序功能的時候了。 我總是意識到一些新的功能有理由進入它自己的捆綁。 現在我想添加一些郵件程序功能，以便用戶可以檢查一些選項，然后將項目發送給朋友。

提前思考，我也可以在同一個應用程序中使用該功能，這是該網站的另一部分。

所以我想，我可能想把一個電子郵件控制器放在自己的捆綁包中，但我知道swiftmailer捆綁已經在做這個，我將使用它。

所以最后我認為它可能只需要幾行代碼，而且可能最好放在網站特定部分的控制器上，我需要電子郵件功能。

現在出現了我想要使它成為自己的捆綁的主要原因，電子郵件正文的twig模板。 我是否希望這些模板在我的其他捆綁中徘徊？ 我想這會有意義。

有什么建議么？

Answer 1

僅為幾行代碼創建一個包看起來有點過分。

對於您的twig模板，您可以將共享模板部分放在app / Resources / views中，這是為您的所有應用程序共享的。 並將特定於域的模板放在特定於域的捆綁包中。 http://symfony.com/doc/current/book/templating.html#template-naming-locations

無論您的電子郵件邏輯代碼應該包含在快速郵件服務器中，如果您需要切換郵件策略，例如使用HTTP API發送郵件，您只需要更改此服務，而不是所有控制器。

如果你有一些代碼可以在你的軟件包之間共享，你可能應該有一個包含所有“單一”服務的{App | Main | Core | ...} Bundle，如果需要，可以稍后在自己的軟件包中移動。

無論如何，他們對你的全球問題有很多方法：

• 您可以使用包含所有業務邏輯的單個捆綁包，並將您的技術/通用內容外部化/解耦到捆綁包中，這些內容可以在您的應用之間共享

• 你可能有一個相反的方法，一個捆綁技術的東西和許多捆綁為您的業務邏輯，可能會更難保持低耦合

• 或兩者兼而有之

在我看來，第一種方法適用於簡單的應用程序，而第二種和第三種方法可以更適合更大的應用程序。 最重要的可能是一致的。