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.