Vlákno názorů ke článku PHP Jet - Architektura - microservices, moduly a MVC od Jan Judas - Díky za další díl článku, a opět textový,...

Díky za další díl článku, a opět textový, paráda :-)

Přijde mi, že v první polovině v podstatě jen neortodoxně popisujete Loose Coupling (neboli "mikroservicy v jednom procesu") a MVC (controller zprostředkovává rozhraní s HTTP/CLI/okolním světem a model je ta, jak vy říkáte "business logika").

Mít jednotlivé části stránky mountovatelné na libovolný prefix, aniž by to musel řešit sám controller, je super věc, která mi třeba v Symfony docela chybí. V mém neexistujícím frameworku, který už mezitím trochu existuje ( https://github.com/kostislav/unicorn-todolist/ ), je tohle taky jedna ze základních vlastností.

Ale to routování a controllery mi v Jetu pořád přijdou jako spousta zbytečné práce navíc. Controller, který zobrazuje článek dle URL, by v mém ideálním světě prostě měl vypadat nějak takhle:

class ArticleController {
    public function __construct(
        private readonly ArticleRepository $articleRepository
    ) {
    }

    @GET("/{id}")
    public function showArticle(string $id): Response {
        $article = $this->articleRepository->getArticleByUrl($id);
        if ($article === null) {
            throw new NotFoundException();
        } else {
            return Response::template('article', [
                'article' => $article
            ]);
        }
    }
}

Nemá smysl se tvářit, že akce controlleru jsou vyvolané něčím jiným než HTTP požadavkem, controller je přesně rozhraní mezi HTTP a zbytkem aplikace, kde jinde než tady by se mělo řešit HTTP?

(A všechen ten mutable global state, který Jet vyžaduje, mě trochu děsí - http://misko.hevery.com/code-reviewers-guide/flaw-brittle-global-state-singletons/ )

P.S. Jaký je vlastně důvod pro velice svérázné použití namespaců ve stylu Jet\MVC_Contro­ller_Router? Je to pouze z historických důvodů? Pokud byste někdy chtěl Jet distribuovat jako Composer balík, tak tohle možná bude trochu problém.

Oprava - @GET("/{id}") má samozřejmě být #[GET('/{id}')], nepřepnul jsem dostatečně z Javy :-) (a příspěvkek mi nejde editovat)

Jaký je vlastně důvod pro velice svérázné použití namespaců ve stylu Jet\MVC_Contro­ller_Router? ... Pokud byste někdy chtěl Jet distribuovat jako Composer balík, tak tohle možná bude trochu problém.
V tomto případě to žádný problém nebude. Dá se classmap.

No, dá "se".. on by ho musel někdo (autor) vyrobit a udržovat, což by pro autora asi byl další důvod, proč Composer balíček nevyrobit. Co koukám, tak PSR-0 autoloader to nakonec nejspíš zvládne, ale že by to pro uživatele bylo nějak moc intuitivní, nevim nevim.

Rozdrobenost projektu na desítky nebo stovky namespaces, kdy potom existuje 15 tříd s generickými nejednoznačnými názvy ala "Client", "Request", "Response", "Adapter", "Manager", "Repository", "Factory" apod. v různých namespacech je do značné míry specifická pro PHP a často otravná - zejména když se smíchá mnoho composer balíků třetích stran dohromady (aka najít ten správný "Client" v seznamu mnoha namespace). Zvolená konvence je podle mě pragmatická - třídy nekolidují s cizími knihovnami (účel namespace), schizofrenie generických názvů tříd fakticky neumožňuje a zároveň jednoznačně určuje členění kódu do složek.

Můžete se zkusit nechat inspirovat zde: https://phpfashion.com/best-practices-pro-jmenne-prostory-v-php
Autor zvažoval podobná kritéria.

Ne "dá se", ale že se prostě použije volba classmap. Jedinou věc, kterou jsem chtěl uvést na pravou míru je, že to není problém. Ani pro autora, ani pro uživatele.

To, zda je to takto dělané hezké je jiná otázka, a k té se nevyjadřuji.

class ArticleController vypada fakt pekne - citelne, prehledne, jasne.