Почему мне не хочется использовать 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

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

Sam Dark

Новичок
Так чтоли?

PHP:
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

TDD interested
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

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

Absinthe

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

Gas

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

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

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

hell0w0rd

Продвинутый новичок
Absinthe
PHP:
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.
 
Сверху