如何访问“模板”服务不在控制器中
好的，所以问题是：
我有一些“订单”实体，并且它具有“状态”属性。在更改状态时，我希望向其他一些对象通报此事件，因此我决定使用观察者模式。一名观察员通过电子邮件通知客户。现在我想从一些树枝模板中渲染电子邮件文本。正如我从书中得到的那样，控制器中的渲染模板是通过“模板”服务完成的。
所以问题如下：我如何访问观察者类中的“模板”服务？
规格： 有人建议我将我的观察者实现为服务，但我对此不确定。我已尝试解决此问题，这是我的选择：
使用注册表。像铁轨一样笔直且坚硬的解决方案。我想它忽略了 DI 和服务容器的全部意义。该解决方案的巨大优点是我可以从应用程序的任何点访问所有常见服务。
通过构造函数或设置器从上下文传递所需的服务。这更像是SF2的精神。还有另一个问题列表，与此问题字段无关。
将观察者用作服务。我不太确定这个选项，因为在书中写道，该服务是一个常见功能，而且我不认为观察具有多个离散属性的实体是一个常见任务。
我正在寻找一个 Sf2 精神解决方案，它将分布在整个项目中，因此所有带有解释的答案都值得赞赏。
Ok, so the problem is:
I've got some 'order' entity, and it has 'status' property. On changing status, i wanted some other objects to be informed of this event, so i've decided to use Observer pattern. One of the observers notifies clients via email. Now i want to render Email text's from some of the twig templates. As i get from the Book, rendering templates in controllers are done with 'templating' service.
So the question as it follows: How can i access 'templating' service in my Observer class?
Specification:
I was advised, to implement my Observer as a service, but i'm not sure 'bout that. I've tried to solve this problem, and here is my options:
Use Registry. Solution that is straight and hard as rail. I guess it misses the whole point of DI and Service Container. Huge plus of this solution, is that i can access all common services from any point of my application.
To pass needed services from the context via constructor, or via setters. This is more like in Sf2 spirit. There comes another list of problems, which are not related to this question field.
Use observers as a service. I'm not really sure 'bout this option 'cos, in the book it is written, that service is a common functionality, and i don't think that observing entity with number of discrete properties is a common task.
I'm looking for a Sf2 spirit solution, which will be spread over whole project, so all answers with an explanation are appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
与 Symfony2 项目中的任何其他服务一样，您可以通过依赖项注入器容器从其他类中访问它。基本上，您要做的是将观察者类注册为服务，然后将模板服务注入到观察者服务中。请参阅注入服务的文档。
如果您不熟悉 Symfony 如何处理依赖注入，我建议您阅读文档的整个章节 - 这非常有帮助。另外，如果您想查找为应用程序注册的所有服务，可以使用控制台命令
container:debug。您还可以在其后附加服务名称以查看有关该服务的详细信息。编辑
我阅读了您对问题的更改，但仍然建议采用 DI 路线。这就是 Symfony2 的精神:) 你担心你的观察者不够通用，无法用作服务，但没有硬性规则说“你必须在 X 位置使用这段代码”以便让它变得‘普遍’”。
使用 DIC 还有另一个巨大的好处 - 它可以为您处理其他依赖项。假设模板服务自身注入了 3 个服务。使用 DIC 时，您无需担心模板服务的依赖关系 - 它们会为您处理。您所关心的只是告诉它“将模板服务注入到其他服务中”，Symfony 会处理所有繁重的工作。
如果您确实反对将观察者定义为服务，那么只要您处于容器感知上下文中，就可以使用构造函数或设置器注入。
As with any other service in a Symfony2 project, you can access it from within other classes through the dependency injector container. Basically what you would do is register your observer class as a service, and then inject the templating service into your observer service. See the docs for injecting services.
If you're not familiar with how Symfony handles dependency injection, I'd suggest reading that entire chapter of the documentation - it's very helpful. Also, if you want to find all the services that are registered for application, you can use the console command
container:debug. You can also append a service name after that to see detailed info about the service.Edit
I read your changes to the question, but still recommend going down the DI route. That is the Symfony2 spirit :) You're worried that your observer isn't common enough to be used as a service, but there's no hard rule saying "You must use this piece of code in X locations in order for it to be 'common'".
Using the DIC comes with another huge benefit - it handles other dependencies for you. Let's say the templating service has 3 services injected into itself. When using the DIC, you don't need to worry about the templating service's dependencies - they are handled for you. All you care about is telling it "inject the templating service into this other service" and Symfony takes care of all the heavy lifting.
If you're really opposed to defining your observer as a service, you can use constructor or setter injection as long as you're within a container-aware context.