Многофункциональное ядро Symfony2?

У меня есть приложение, в котором есть основной веб-сайт, api и область администрирования. Я хотел знать, что это плохая идея иметь все в одном приложении, или мне нужно создать другой проект Symfony2, или я должен разделить их на разные ядра?

Я не уверен, что добавление большого количества пакетов на одном ядре сильно повлияет на производительность или немного, что не имеет значения?

Ниже приведены параметры:

сохранить все на одном ядре, это не имеет большого значения.
имеют несколько ядро для разных частей приложения (api, admin и основной сайт).
создать другой проект Symfony2 для области администрирования и api.
или ваши мудрые слова:)

Ответ 1

Вы можете определить более "среды".

Например:

В 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

В основном это зависит от качества пакетов. И это связано с тем, насколько они связаны.

Я бы отклонил точку 3 при запуске (create different Symfony2 project for admin area and api.) - возможно, вы не создаете два отдельных приложения.

Множество ядро для разных частей приложения (api, admin и основной сайт)

Общая проблема создается Listeners и сервисами в контейнере. Особенно, когда ваш слушатель должен работать только в одном из контекстов приложения (api/frontend/backend). Даже если вы не забыли проверить его в самом начале метода слушателя (и делать магию только в желаемом контексте), то все же слушатель может зависеть от инъецируемых услуг, которые нужно сконструировать и вставить в любом случае. Хорошим примером здесь является FOS/RestBundle: даже если вы настроите zones, то все еще на интерфейсе (когда view_listener активируется для api) view_handler инициализируется и вводится в прослушиватель - https://github.com/FriendsOfSymfony/FOSRestBundle/blob/master/Resources/config/view_response_listener.xml#L11 Я не уверен на 100% здесь, но также отключил переводы и веточку (и т.д.) для API (большая часть api не нужна) ускорит его.

Создание отдельного контекста Kernel для API позволит решить эту проблему (в нашем проекте мы используем одно ядро, и нам пришлось отключить этот слушатель), поскольку профили blackfire.io говорили нам, что он сохраняет ~ 15 мс при каждом запрошенном запросе).

Создание нового ядра для API гарантирует, что ни один из служб/слушателей, основанных только на API, не будет вмешиваться в визуализацию frontend/backend (он работает в обоих направлениях). Но это создаст для вас дополнительную работу по созданию общего components, используемого во многих пакетах внутри проекта (из разных ядер), - но в мире с композитором это уже не огромная задача.

Но это дело только для людей, которые измеряют каждую миллисекунду времени отклика. И зависит от качества ваших /3dparty. Если все нормально, тогда вам не нужно возиться с ядрами.

Ответ 3

Это личный выбор, но у меня есть аналогичный проект, и у меня есть publicBundle, adminBundle и apiBundle в рамках одного и того же проекта.

Чрезмерное повышение производительности не имеет значения, но организация ключевая... поэтому мы используем пакет MVC (Symfony), в первую очередь, не так ли?:)

NB: Ваша терминология немного запутанна, я думаю, что Kernel вы имеете в виду Bundle.

Ответ 4

Невозможно помочь нескольким ядрам.

Разделите приложение в связках и сохраните все преимущества совместного использования ваших объектов (и т.д.) через разные части приложения.

Вы можете определить отдельные маршрутизаторы/контроллеры/конфигурацию, которые загружаются в зависимости от хоста/URL-адреса.

Примечание:

Если вы собираетесь отделить свое приложение в двух больших пакетах (например, Admin и Api), и что у них есть одни и те же сущности, вам обязательно придется сделать выбор.

Этот выбор может включать в себя то, что один из ваших пакетов содержит слишком много (и не связанную) логику и позже должен быть реорганизован в несколько пакетов.

Создайте пакет в разделе вашего приложения, который соответствует набору связанных ресурсов, и сделайте разницу между двумя частями в разных контекстах из конфигурации.

Кроме того, разумно назовите ваши классы/пространства имен.