Почему мне не хочется использовать Yii?

[Gas]

Немного в другую сторону поверну, я не специалист по ruby и питону, но там вроде не сильно парятся по поводу DiC'ов, локаторов и прочего ООП головного мозга
как посмотришь примеры на рельсах - кода минимум, всё ясно и он делает своё дело, посмотришь на симфони и зенд2, всё как-то иначе.
yii и прочие laravel'и по-моему как раз и пытаются идти по пути руби - быстро наколбасил и в продакшн, а не думал неделями какой бы патерн сюда ещё навернуть, хотя опять-же, не знаю как обстоят дела с тем же RoR'ом на проектах от нескольких человеко-лет, но github же работает.

 

[Sam Dark]

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

 

[Redjik]

Фиг его знает, кто стал использовать, но запутало это народ неслабо...

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

Это помогло бы делать DICComponent (который implements IApplicationComponent).
И можно было бы сходу делать такие штуки Yii::app()->mailDIC->transport->getType() - например

Вот так - https://github.com/Redjik/giny/blob/ArCommand/framework/base/GDICComponent.php

 

[Sam Dark]

Базовай функционал DIC модуля — это что именно? YiiBase::createComponent недостаточно? Почему в данном конкретном случае вся эта прослойка лучше Yii::app()->param('mail.transport')?

 

[Redjik]

Ну сейчас весь функционал DIC, или если удобнее назвать Service Locator находится в Module, мне кажется стоит разделить их.
Тогда можно удобно применить Компоновщик (Composite) и делать DIC внутри DIC.

Возможно с почтой не самый удачный пример, но сейчас у нас на оформлении заказа очень много различных сущностей. И orderHelper (extends GDICComponent) очень удобно управляет зависимостями.
А так получается Module слишком много на себя берет.

 

[Ragazzo]

Да кстати, мне тоже в Yii1 хотелось, чтобы CComponent умел делать set/getComponent, чтобы компоновщик была, ага.

 

[Sam Dark]

Так чтоли?

class CoolComponent extends CComponent
{
	private $_components = array();

	public function setComponent($name, $config)
	{
		$this->_components[$name] = $config;
	}

	public function getComponent($name)
	{
		if(!isset($this->_components[$name])) {
			return null;
		}

		if(!$this->_components[$name] instanceof CComponent) {
			$this->_components[$name] = YiiBase::createComponent($this->_components[$name]);
		}

		return $this->_components[$name];
	}
}

 

[Redjik]

Примерно так, да. А Module уже в свою очеред от CoolComponent

 

[Ragazzo]

Sam Dark
и еще setComponents добавить, чтобы можно было конфиги в _components мерджить.

 

[Sam Dark]

Тут надо понимать, что сокращая немного код для каждого нового конкретного компонента мы сильно теряем строгость интерфейса. В любой компонент становится можно насовать чего угодно, ну и в случае очепятки программист отхватит по полной...

Если такое делать, то я бы сделал метод protected и для каждой зависимости создавал бы по геттеру и сеттеру, где бы использовал уже этот protected.

 

[Redjik]

Ragazzo
продублирую - https://github.com/Redjik/giny/blob/ArCommand/framework/base/GDICComponent.php =)
еще registerCoreComponents() как у меня - и будет вообще шоколадно - тогда Стратегию очень удобно делать через конфиг.

Sam Dark
Мы не сокращаем для конкретного компонента, мы просто добавляем еще одну сущность.

Сейчас:
CApplication->CModule->CComponent;
CApplicationComponent->CComponent;

А хочется
CApplication->CModule->DIC->CComponent;
DICApplicationComponent->DIC->CComponent;

Иначе приходится брать половину Module, чтобы написать DICApplicationComponent.

 

[Sam Dark]

Не понял, о какой половине речь и почему Module. Можно же обойтись одним статическим методом из YiiBase, как я показал выше, не?

 

[Ragazzo]

Redjik
дак вариант Sam Dark почти то же самое :S
>тогда Стратегию очень удобно делать через конфиг.
итак можно,вон посмотри всякие db-schem'ы, через public поле.

 

[hell0w0rd]

Чем-то похоже на silex только там нет статики))

 

[Absinthe]

Вместо них Yii::app()->myComponent.

А если я не хочу использовать явно внутри кода Yii::app()->? Вот без него как объект получить необходимые объекты?

 

[Sam Dark]

А если я не хочу использовать явно внутри кода Yii::app()->? Вот без него как объект получить необходимые объекты?

Через геттер или конструктор?

 

[Absinthe]

Sam Dark сеттер и конструктор? Можно пример конфигурации класса, при котором у созданного объекта автоматически вызовутся методы с нужными параметрами? (ну чтобы ему лично DI не дергать, завязываясь кодом на контейнер)

 

[Gas]

Absinthe

Через cеттер или конструктор

Но всё-таки Yii::app()-> нельзя назвать полноценным DiC'ом, так как для классов, описаных в конфиге, вызывается init(), а если я хочу там прописать сторонний класс у которого нет init, то наследовать только или при инициализации в конструктор передать что-то, сейчас кажется можно проинициализировать только публичные свойства класса.

Хотя может я не так код yii понял.

p.s. в целом я yii доволен и жду вторую версию, хотя для первой свою обёртку для использования неймспейсов уже написал.

 

[hell0w0rd]

Absinthe

abstract class PsuedoDI
{
    abstract function setParams();
    public static function get()
    {
        static $obj;
        if($obj === null){
            $obj = new self();
        }

        return $obj;
    }
}

?)

 

[Absinthe]

Absinthe
Но всё-таки Yii::app()-> нельзя назвать полноценным DiC'ом, так как для классов, описаных в конфиге, вызывается init(), а если я хочу там прописать сторонний класс у которого нет init, то наследовать только или при инициализации в конструктор передать что-то, сейчас кажется можно проинициализировать только публичные свойства класса.

В том то и дело, что DI должен без всяких наследований это уметь делать с абсолютно рандомным классом. Не умеет - не DI.