Kolejność wykonywania kodu w Aplikacji, Od Request do Response - Szeregowo czy Równolegle (?) Opcje

[adbacz]

Zastanawiam się nad takim problemem. Zakładając, że chcemy napisać aplikację, nie używając żadnego z dostępnych Frameworków PHP, musimy mieć czysty kod, oraz jak najmniej w nim rzeczy niepotrzebnych. Na początku definiujemy co w nim potrzebujemy itd, aż w końcu przychodzi pytanie, jak to wszystko połączyć, by działało.

Zasnanawiają mnie dwa wyjścia (może jest więcej?). Zakładając że chwilowo mówimy o obiegu na podstawie 4 kluczowych miejsc: FrontController, Routing, Controller oraz View. Jak je ułożyć i powiązać, by nie były bardzo powiązane, by można było to rozbudowywać w miarę potrzeb, ale by działało ze sobą.

Pierwsze to "połączenie równoległe". Request przechodzi w Response po kolei od FrontController aż do View.
Drugie to "połączenie szeregowe". Request jest odbierany przez FrontController, ale to on wywołuje pozostałe 3 części do pracy (Routing, Controller, View (może oprócz tego, ale chodzi mi o ogólną zasadę)) i na końcu wypluwa Response.



Czy macie jakieś doświadczenie w tym temacie? Jakieś za lub przeciw wymienionych rozwiązaniom? A może macie jakieś inne pomysły jak to rozwiązać?

[Pyton_000]

MVC raczej opiera sie o 2 model. Szeregowe rozwiązanie nie jest optymalne bo w pewnym sensie nie masz powrotu.

Równoległe rozwiązanie jest elastyczne, jeżeli zaprojektujesz FC i dodasz moduły w postaci dynamicznych wtyczek to równie dobrze możesz odłączyć wszystko a powinno zadziałać.

[adbacz]

Zaciekawiłeś mnie... Możesz rozwinąć myśl "...moduły w postaci dynamicznych wtyczek..."?

EDIT:
Szeregowe rozwiązanie daje tylko jedną zaletę wg mnie... właśnie możliwość powrotu. Jeśli stanie się coś w części View, to mogę cofnąć sie do Routing i wykonać jeszcze raz, zmieniając Request. Ale to tak na marginesie

Ten post edytował adbacz 3.07.2014, 21:37:19

[Pyton_000]

Bardzo prosty przykład.

W FC wywołujesz sobie coś na zasadzie LoadDynamicLib które to "przeszukuje" określony folder/plik w poszukiwaniu klas które może dołączyć.
Wrzuca sobie te klasy do swojego kontenera.
I teraz ten odpala każdy z dołączonych lib i wykonuje coś tam przekazując w konstruktorze request a wypluwając response. i tak dalej.

W ciele każdej "wtyki" możesz robić cuda w zależności od tego co dostałeś jako Request.
Coś na zasadzie wzorca Dekorator.

Możesz się jeszcze zainteresować Aspektami (wzięte z .net ale na PHP też jest "Aspects")
np: http://code.tutsplus.com/tutorials/aspect-...h-go--net-31046

[binary101]

A niby jak kontroler może zadziałać równolegle z widokiem? Albo, skoro równolegle, to Ruting, potem widok, a potem kontroler. Równolegle - czyli asynchronicznie. Przecież to nie ma sensu.

klasyczne MVC to http://edu.pjwstk.edu.pl/wyklady/zap/scb/W7/images/MVC.gif

równoległe działanie jest możliwe właściwie tylko przy aplikacjach stanowych (czyli raczej jedynie desktop), równoległość działa wtedy w cyklach i zaczyna się od kontrolera, ale to inna bajka.

[by_ikar]

Temat poruszany dziesiątki razy na forum, na planecie.php.pl były wpisy z blogu Zyx'a ale widzę że on bloga się już pozbył, a świetny wpis miał tam na temat MVC w php i dlaczego w końcu niektórzy twórcy poszli po rozum i przestali opisywać swoje frameworki jako MVC.

W php MVC najczęściej jest spotykane jako MVP (mimo że opisują to inaczej), a drugi przypadek "równoległego" działania (tak jak @binary101 napisał, w językach skryptowych nie da się tego osiągnąć) to jest symfony2 przykładowo, oraz inne frameworki napisane metodologią event driven (a kilka ich jest, z czego jakaś część oparta o komponenty symfony np laravel etc).

[adbacz]

Chyba źle napisałem bo się nie zrozumieliśmy, niezbyt wiedziałem jak to nazwać.

Strzałki oznaczają jak przebiega przekazywanie odpowiedzialności za aktualne działanie aplikacji. W pierwszy przypadku Request wchodzi do FrontController, ten przekazuje pałeczkę w działaniu Routingowi, ten zaś sprawdza który kontroler ma uruchomić i go uruchamia, a ten dalej wykonuje albo View, albo zwykły Response i mamy koniec. W drugim przykładzie to FrontController jest odpowiedzialny za prawie wszystko, czyli Request przychodzi do niego, później odpytuje on Routing a ten zwraca mu dane, później na podstawie tych danych włącza kontroler (oczywiście za pomocą kogoś innego, FC jest tylko takim łącznikiem pomiędzy wszystkimi częściami aplikacji) i ten znowu zwraca mu dane, i na zasadzie tych danych albo zwraca tekst albo wywołuje View podany przez kontroler.

Wiem, że nie można mieć aplikacji asynchronicznych, czyli jak napisałem równoległych, miała to być raczej nazwa opisowa.

[by_ikar]

Tak czy inaczej opisałem ci kilka FW które powinny cię zainteresować bo jak się je bliżej pozna są całkiem przyjemne, a samych komponentów z takiego symfony możesz użyć w różnych miejscach i przypadkach, bo działa to dość modularnie.