Symfony 包组成，使用多个包时如何构建我的代码
我正在寻找有关如何构建 Symfony 2.0 应用程序的最佳实践的指导。如果我有几个捆绑包（购物车捆绑包、产品捆绑包、CMS 捆绑包），并且我希望在编写页面时使用所有这些捆绑包的各个方面，我应该如何最好地做到这一点？
我可以想象两种方法来做到这一点，但我正在寻找哪种方法（如果有的话）是正确的指导。
1）通过服务公开我的捆绑包的所有功能，并让这些服务可直接从 twig 内使用。这样我就可以将路由请求传递到最合适的包（因此 http://myclient.org/User/Account< /a>) 被传递给 ClientUser 包来处理，但是导航中具有迷你购物车的基本模板能够直接从 twig 内访问它需要的信息（我不需要传递它）
2 ) 创建一个可以访问所有其他包的包为了构建页面（如 VendorFrontend 或 VendorBackend）。这意味着所有路由请求都将传递到该捆绑包，并且该捆绑包将在传递到模板之前访问页面每个部分所需的信息。
第一个选项感觉不对，因为我不确定是否可以允许 Twig 直接使用服务（通过服务容器）？
第二个选项感觉不对，因为它就像使用第二个路由器，路由将被传递到一个捆绑包中，该捆绑包仅存在以组成其他捆绑包（这里给出的是该捆绑包与它使用的捆绑包紧密耦合）。当然，这违背了代码可重用的“捆绑”概念。
在此示例中，我尝试构建一个非常简单的电子商务网站，仅用于演示目的。我有一个基本模板，其中有主导航、迷你购物车、“正文”和页脚。我将其存储在 /app/Resources 目录中。我计划让所有其他模板继承这个模板并覆盖“正文”区域。
不想被灌输，只是朝着正确的方向轻推。谢谢。
I'm looking for some guidance on best practice around how to structure my Symfony 2.0 application. If I have a few bundles (Cart Bundle, Product Bundle, CMS Bundle) and I wish to use aspects of all of these bundles when composing my page how should I best do this?
I can imagine two ways to do this, but am looking for guidance on which (if either) is correct.
1) Expose all of the functionality of my bundles through services, and have these services available to use directly from within twig. This way I can pass my routing request to the most appropriate bundle (so http://myclient.org/User/Account) is passed to the ClientUser bundle to handle, but the base template which has a mini shopping cart in the navigation is able to access the information it needs directly from within twig (I don't need to pass this in)
2) Create a bundle that accesses all the other bundles in order to build up the page (like VendorFrontend or VendorBackend). This would mean that ALL routing requests would be passed to this bundle and this bundle would access the required information for every part of the page before passing off to the template.
The first option feels wrong because I'm not sure if it's even possible to allow Twig to consume services directly (though the service container)?
Second option feels wrong because It's like using a second router, the routes would be being passed into a bundle, which only exists to compose the other bundles (it's a given here that this bundle is tightly coupled to the bundles that it uses). Surely this goes against the concept of a 'bundle' that the code is reuseable.
In this example I'm trying to build a very simple e-com site for demonstration purposes only. I have a base template which will have a primary navigation, mini shopping cart, 'body' and footer. I'm storing this in the /app/Resources directory. I was planning on having all other templates inherit this one and overriding the 'body' area.
Not looking to be spoonfed, just a nudge in the right direction. Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为重要的是要摆脱这样的想法：为了生成“页面”，必须将模板所涉及的渲染可能需要的所有变量集中在一起，然后将它们传递到模板中。控制器应该只为它所服务的请求做特定的事情，而不是更多。因此，如果 URL 中引用了特定产品，请获取该产品并将其传递到模板中。如果引用了特定产品，但它不存在或不应显示，您可以使用 404/410/任何适当的内容进行响应。如果有特定的集合，则获取该集合并将其传入。路由/控制器应该对请求（URL 本身、HTTP 方法等）进行解码，并将其转换为特定的内容。任何一般性的、非特定于特定请求的内容都不属于那里。
我想说，尽可能地从 Twig 模板中抽象出您使用的捆绑包也很重要。我更提倡模板将其所需的内容“拉”到其中，而不是推入，但这是通过捆绑包中 Twig 函数的定义来实现的，这些函数本身可以通过 DI 容器，挂钩到可能或可能不会的数据因此，您创建一个 Twig 函数，可以将任何可能更改的内容作为参数 - 如果它与产品类别有关，则让它将产品类别对象作为参数。
本质上答案是 1) 多于 2)，但是您不应该直接通过 Twig 访问服务 - 您应该通过模板中具有语义意义的函数进行代理，这些函数本身被定义为在运行时将服务注入其中，您可以自由地在您包含或编写的任何新捆绑包中以不同方式定义的服务。
I think that it's important to get away from the idea that, in order to generate a "page", one has to corral together all the variables that the templating involved might need in order to render, and then pass these into a template. A controller should be doing only the specific thing for the request it's serving, and no more. So if there's a specific product referenced in a URL, fetch the product and pass it into the template. If there's a specific product referenced but it doesn't exist, or shouldn't be shown, you respond with a 404/ 410/ whatever is appropriate. If there's a specific collection, fetch the collection and pass it in. The routing/ controller should be decoding the request - the URL itself, the HTTP method, etc - and translating that into something specific. Anything general and not specific to a particular request doesn't belong there.
It's also important, I would say, to abstract as best you can the bundles you use from Twig templates. I am advocating more that templates "pull" what it needs into them, rather than being pushed in, but this is achieved by the definition of Twig functions within bundles that can themselves, via the DI container, hook into data that may or may not be in the current request, etc. So you make a Twig function that can take as a parameter anything that might change - if it has to do with product categories, let it take a product category object as a parameter.
Essentially the answer is more 1) than 2), but you shouldn't be accessing services directly through Twig - you should be proxying via functions that make semantic sense within the template, that themselves are defined to have services injected into them at runtime, services that you are at liberty to define differently in any new bundles you include or write.