2015-05-05 3 views
1

Некоторая информация для начала. Я использую 2.7.0-BETA1, но следующие вопросы касаются лучшей практики с Symfony2. Я прочитал руководство по лучшей практике от Symfony. Для основ они хорошие, но некоторые вещи мне кажутся непонятными.Наилучшая практика для организации услуг/классов symfony2

Мы переносимся из приложения без рамки в symfony2. Основная часть, которую мы собираемся вставить в один комплект. (Я знаю, что есть разные мнения об этом.) Плагины будут находиться под тестом \plugin\FooblaPluginBundle

Каждый пользователь может установить некоторые параметры в своем профиле, которые сохраняются в таблице (conf) (Поля: id, категория, ключ, value, accountid) Я только начал писать услугу. (Только начал, потому что я не уверен в правильном направлении)

<?php 
namespace Test\CoreBundle\core; 
use Doctrine\ORM\EntityManager; 

class Configuration { 

    private $em; 

    public function __construct(EntityManager $em) 
    { 
     $this->em = $em; 
    } 

    public function loadAll($accountid = '1') { 
     $conf = $this->em->getRepository('TestCoreBundle:Conf')->findAllByAccount('1'); 
     dump($conf); 
    } 
} 

В конце концов контроллер будет что-то вроде

$conf = $this->get('test.conf'); 
$conf->setCategory('foobla'); 
$conf->get('keyname'); 

Просто, чтобы закончить код: (services.yml)

services: 
test.conf: 
    class: Test\CoreBundle\core\Configuration 
    arguments: [ @doctrine.orm.entity_manager ] 

Это правильный способ сделать это так?

Используемые ключи/настройки будут (снова) жестко закодированы в коде со значениями по умолчанию и возможными параметрами, которые пользователь может установить. При регистрации значения по умолчанию будут установлены для пользователя. Эта информация будет в некоторых других классов, которые я бы положить в Test\CoreBundle\Core\Configuration\{category}

Второй «базовый» вопрос: У нас есть некоторые классы, которые могут остаться в одиночестве. (Например, есть класс Date/Time, который выполняет некоторые вычисления на заданных временных отметках) Но я не знаю, куда его поместить. Если я положил их, например. в «Services» это было бы рано или поздно хаотично. Положить их в разные (в зависимости от их функций) в разных папках было бы лучше.

Пожалуйста, дайте мне знать любые мысли о идее и моих мыслях. Я хотел бы услышать от вас.

Обновление: последняя мысль: Было бы совершенно неправильно ставить классы непосредственно в пространстве имен «test»?

+0

Что касается службы конфигурации, я бы предложил заводскую службу, которая фактически создает конкретный объект конфигурации для данного пользователя. Например. '$ factory-> createFor ($ accountId): Конфигурация'. Вы можете даже инкапсулировать это в контейнер обслуживания. – Yoshi

+0

@Yoshi Большое спасибо. Я посмотрю, как использовать Factory для создания сервисов. – mipapo

ответ

1

Я думаю, что первым вопросом является вопрос о том, правильно ли настроена ваша служба Conf, и да. В какой-то момент вы должны научиться определять репозиторий как услугу и просто вводить репозиторий вместо полного менеджера сущностей. Но это просто утонченность.

Вторые вопросы, похоже, касаются автономных компонентов. Создайте каталог Test \ Component и поместите их под ним. В конце концов вы можете захотеть поместить их в свой собственный репозиторий и использовать композитор для их загрузки. Но это опять-таки утонченность.

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

+0

Это тот ответ, которого я ожидал. Спасибо за ваши советы. Я немного экспериментирую с моими идеями и вашими рекомендациями. – mipapo