Best practice: komponenty a struktura projektu

Ahojte.

Verim tomu ze tato tema sa zvrtne na rozsiehalejsiu diskusiu a nam to vyriesi dlhodobu otazku pri rieseni co najlepsich postupov v budovani projektu väcsieho rozsahu.

Co by som sa chcel poradit minimalne na tieto hlavne otazky:

1. Ako strukturovat komponenty
2. Ako komponentam spravne predavat zavislosti
3. Ako komponenty dostat do presentra a inych komponent

Skusim jednoducho opisat nasu aktualnu situaciu:

Mame adresar „components“ v ktorom je zatial cca. 25 komponent. Budeme ich neskor triedit o nieco lepsie.
Kazda komponenta sa sklada minimalne z vlastneho Control, ControlFactory a .latte sablony.
Cize napr. AddToNewsletterControl.php, AddToNewsletterControlFactory.php a AddToNewsletterControl.latte

Factory zaregistrujeme do configu pod services.
Cize napr.:

• App\Components\AddToNewsletterControlFactory

Nasledne mame vytvoreny trait v adresari „components“ ktoru sme „laicky“ pomenovali LoadFactories.php
Tento subor obsahuje funkcie pre vytvaranie vsetkych komponent (je to vykonovo idealne? spravne riesenie?):

// ADD TO NEWSLETTER
	private $addToNewsletterControlFactory;

	public function injectAddToNewsletterControlFactory(\App\Components\AddToNewsletterControlFactory $factory){
		$this->addToNewsletterControlFactory = $factory;
	}
	protected function createComponentAddToNewsletter(){
		$componentsSettings = $this->componentsSettings['addToNewsletter'];
		return $this->addToNewsletterControlFactory->create($componentsSettings);
	}

Tento trait mame pouzity v BasePresenter-i pomocou use. Vhodne riesenie nacitania?

K prvej otazke:
je to spravna struktura a nacitavanie komponent pre presenter?
mohli by sme vytvorit nejaku BaseComponent-u od ktorej by dedili vsetky komponenty a nacitaval by sa do nej ten isty trait ako v presentri?
Ako inak dostat vzdy vsetky komponenty navzajom do akejkolvek dalsej komponenty?

K druhej otazke:
Takmer kazdej komponente predavame z presentra premennu $componentsSettings. Nieje to nic ine, ako pole s nastaveniami komponent vytiahnute z databazy. Je trochu strukturovane podla nazvu komponenty a jej pozicie.
Myslim si ze to je škarede riesenie ako predavat kazdej komponente toto $componentsSettings. Neislo by to nejakou triedou ktoru si injectnem do kazdej komponenty, aj do presentrov? Tak aby sa ten dotaz do databazy vykonal len raz.
Nasledne vsetky repositare a ine zavislosti predavame pomocou Factory a jeho constructora v danej komponente. Napr.:

class AddToNewsletterControlFactory {

	private $userRepository,
			$mailingNewsletterEmailRepository;

	public function __construct(
		Model\User\UserRepository $userRepository,
		Model\Mailing\MailingNewsletterEmailRepository $mailingNewsletterEmailRepository
	){
		$this->userRepository = $userRepository;
		$this->mailingNewsletterEmailRepository = $mailingNewsletterEmailRepository;
	}

	/** @return AddToNewsletterControl */
	public function create($componentSettings){
		return new AddToNewsletterControl(
			$componentSettings,
			$this->userRepository,
			$this->mailingNewsletterEmailRepository
		);
	}
}

Ako vidite, zase je tam ta hnusna premenna $componentSettings. Chcel by som sa jej nejako zbavit a riesit ju az priamo v komponente z nejakeho objektu ktory sa vytvori len raz a pouziva sa pre vsetky komponenty, presenter, atd…

A k tretej otazke:
To som uz zacal vyssie. Mame vsetky komponenty definovane v trait LoadFactories ktory pomocou use dostavame do BasePresentra, cize vieme vsetky komponenty pouzivat vo vsetkych presentroch.
Avsak teraz potrebujeme dostavat este aj komponenty do komponent a preto sa pytam, ci je vhodne riesenie znova tento trait hodit do nejakej BaseComponent od ktorej by dedili vsetky komponenty, alebo je na to nejake krajsie a „programatorskejsie“ riesenie.

Trochu som sa rozpisal, ale dufam ze tymto vyriesime niekolko, aj zaciatocnickych otazok, definitivne.

Dakujem za akekolvek tipy, zdroje, navody, postrehy. Dufam ze to pomoze viacerym k budovaniu peknych a uspesnych projektov v ktorych sa po rokoch nebudu stracat ;-)