我有应用程序,它有核心网站,api和管理区域。我想知道在一个应用程序中包含所有内容或者我应该创建不同的Symfony2项目还是应该将它们拆分为不同的内核?
我不确定在同一个内核上添加大量的捆绑包是否会影响性能或者只是一点点,这无关紧要?
以下是选项:
答案 0 :(得分:2)
它主要取决于捆绑质量。这与他们有多少联系。
我会在开始时拒绝第3点(create different Symfony2 project for admin area and api.
) - 因为你可能不会构建两个单独的应用程序。
为应用程序的不同部分(api,admin和核心网站)提供多个内核
常见问题是由容器中的监听器和服务创建的。特别是当你的监听器只能在app上下文之一(api / frontend / backend)工作时。即使你记得在监听器方法的最开始检查它(并且仅在想要的上下文中做魔术),那么仍然监听器可以依赖于需要构造和注入的注入服务。这里的好例子是FOS / RestBundle:即使你配置zones
然后仍然在前端(为api激活view_listener
时)view_handler
被初始化并注入监听器 - https://github.com/FriendsOfSymfony/FOSRestBundle/blob/master/Resources/config/view_response_listener.xml#L11我不确定100%在这里,但也禁用API的翻译和枝条(等)(大多数api不需要它)将加快它。
为API上下文创建单独的内核将解决该问题(在我们的项目中,我们使用一个内核,我们必须禁用该侦听器 - 因为blackfire.io配置文件告诉我们它在每个前端请求上节省了大约15ms)。
为API创建新内核将确保所有API服务/侦听器都不会干扰前端/后端呈现(它可以双向工作)。但是它会为你创建额外的工作来创建在项目内部的许多包中使用的共享components
(来自不同内核的包) - 但在使用作曲家的世界中,它不再是一项艰巨的任务。
但仅适用于测量每毫秒响应时间的人。并取决于您的/ 3dparty捆绑质量。如果一切都完全没问题那么你就不需要搞乱内核了。
答案 1 :(得分:2)
您可以定义更多“环境”。
例如:
在 AppKernel.php
中public function registerBundles()
{
$bundles = array(
new Symfony\Bundle\FrameworkBundle\FrameworkBundle(),
new Symfony\Bundle\SecurityBundle\SecurityBundle(),
new Symfony\Bundle\TwigBundle\TwigBundle(),
new Symfony\Bundle\MonologBundle\MonologBundle(),
new Symfony\Bundle\SwiftmailerBundle\SwiftmailerBundle(),
new Doctrine\Bundle\DoctrineBundle\DoctrineBundle(),
new Sensio\Bundle\FrameworkExtraBundle\SensioFrameworkExtraBundle(),
//new AppBundle\AppBundle()
);
if (in_array($this->getEnvironment(), array('api'), true)) {
$bundles[] = new ApiBundle\ApiBundle();
//-- Other bundle
}
//-- Other environments
return $bundles;
}
}
答案 2 :(得分:0)
这是个人选择,但我有一个类似的项目,我在同一个项目中有一个publicBundle,adminBundle和apiBundle。
额外的性能影响是可以忽略的,但组织是关键......这就是我们首先使用MVC软件包(Symfony)的原因,不是吗? :)
注意:您的术语有点令人困惑,我认为Kernel
您的意思是Bundle
。
答案 3 :(得分:0)
有几个内核无法提供帮助。
将您的应用程序拆分为捆绑包,并通过应用程序的不同部分保留共享实体(等等)的所有优势。
您可以定义根据主机/网址加载的分离路由/控制器/配置。
注意:
如果您打算将您的应用分成两大包(即Admin& Api), 并且两者共享相同的实体,你肯定要做出选择。
这个选择可能涉及你的一个包包含太多(和非相关)逻辑,并且需要稍后在几个包中重构。
在应用程序的每个部分创建一个与一组相关资源相对应的包,并通过配置的不同上下文在两个部分之间进行区分。
另外,明智地命名您的类/命名空间。