KISS MVC

Wstęp

Trochę w ostatnim czasie jeszcze poprawiałem stronę główną PureDeva przygotowując panel administracyjny do zarządzania treścią na stronie. Miałem wobec tego kilka możliwości by poznać lepiej KISS MVC. Poniżej pokrótce opiszę moje odczucia co do tego frameworka i jak wypada on w porównaniu z innymi tego typu rozwiązaniami. Jeśli chodzi o przygodę z MVC to podzieliłbym ją na 2 części – część View-Controller, który może służyć jedynie do budowania automatycznych route’ów (kontroler) oraz do ładnego systemu template’ów i layoutów oraz na pełny MVC.

W pierwszym zastosowaniu KISS MVC nie ma sobie równych – jest niewielki i bardzo prosty w obsłudze oraz nie narzuca nic programiście. Z drugiej strony pełen model MVC już nie jest taki fajny – częściowo z powodu właśnie Modeli. Do prostych zastosowań, gdzie jedyne zapytanie jakie byśmy chcieli napisać dotyczyłyby tylko jednej tabeli, to KISS-owy model nadaje się doskonale – bez żadnych zapytań jesteśmy w stanie zrobić wszystko co chcemy.

Poza tym taki bazowy model jest dość mocno zintegrowany z PDO, więc nie trzeba zmieniać starych przyzwyczajeń. Jednak zrobienie zapytania dla 2 tabel wydaje się mocno utrudnione poprzez taki model; możemy oczywiście dostać się z kontrolera do samego PDO, który jest zawarty w modelu i napisać po prostu zapytanie – co z powodzeniem zadziała. Nie jest to jednak coś co metodycznie jest poprawne (przynajmniej dla mnie; miejsce zapytań jest w Modelu danych, a nie w logice biznesowej).

Porównanie

Ok, wstępnie opisałem wady i zalety, teraz poniżej przedstawię kilka podstawowych rzeczy wraz z odpowiednikami w Kohanie. ### Kontroler

Url w przypadku Kohany w naszej aplikacji webowej wygląda mniej więcej tak: http://localhost/kohana/index.php/{kontroler}/{metoda}/{parametr} Przy czym [index.php] jest opcjonalny, tzn. przez modyfikację .htaccess można się go pozbyć. W KISS MVC url wygląda bardzo podobnie (też bez index.php w linku), jednak jest kilka istotnych różnic w działaniu: kontroler nie dotyczy pliku, a folderu w katalogu controllers, metoda oznacza konkretny plik php we wskazanym folderze. Wewnątrz tego pliku musi być metoda o nazwie takiej samej jak plik z poprzedzającym ją znakiem podkreślenia (_).

Oznacza to, że nie można wywołać dowolnej metody kontrolera tylko przez wpisanie odpowiedniego urla do strony, co wydaje mi się całkiem niezłym pomysłem (zarówno praktycznym, jak i poprawiającym nieznacznie bezpieczeństwo). Kontrolery w KISS w przeciwieństwie do Kohanowych nie są obiektowe.

View

Najlepsza rzecz z całego frameworka. Prawie identycznie wygląda zastosowanie / wykorzystanie tego ogniwa zarówno w KISS jak i w Kohanie. Różni się co najwyżej notacja, więc wyjaśnienie będzie na konkretnym przykładzie: KISS:

function _index()  
{ 
    $view = new View(APP_PATH.'views/index.php'); 
    $view->set('tytulStrony', 'Ładna strona'); 
    $data['content'][]=$view->fetch(); 
    $data['nazwaZmiennej']=15;
    View::do_dump(VIEW_PATH.'layout.php',$data); 
}

Kohana:

class Sample_Controller extends Template_Controller  
{ 
    public function index() 
    { 
        $test = new View('test_content'); 
        $test->nazwaZmiennej = 'lalala '; 
        $test->render(TRUE); 
    } 
}

Model

Cóż, model już wstępnie opisałem, więc jedyne co zrobię to pokażę przykład modelu w KISS:

 //w kontrolerze: 
 $user = new User($_SESSION['authuid']); 
 $userNick = $user->get('nick'); 
 //w modelu: 
 class User extends Model { 
     function __construct($id='') 
    { 
        parent::__construct('identyfikator','nazwaTabeli');
        $this->rs['identyfikator'] = ''; 
        //czyszczenie pól 
        if ($id) 
            $this->retrieve($id); 
    } 
}

Widać, że nic konkretnego w tym modelu się nie znajduje, a jednak prosta funkcjonalność CRUD dla jednej tabeli jest jak najbardziej dostępna i to bez pisania kodu. Generalnie rzecz ujmując KISS jest tak zrobiony, że wykorzystanie jakiegoś bardziej zaawansowanego ORM-a nie byłoby raczej problemem; wobec czego to w ramach ciekawostki prezentuję. ### Wydajność i objętość

Ogólnie w kwestii wydajności KISS oczywiście prowadzi ze względu na niewielkie rozmiary oraz brak niepotrzebnego a parsowanego kodu, choć Kohana z tego powodu też nie staje się bezużyteczna. No, ale coś za coś. W ramach ciekawostki porównanie ile zajmuje gotowy projekt w KISS i w Kohanie: KISS: 35 plików samego kodu (kontrolery, model, views, config), Waga “luzem”: 65KB. Kohana: 220 plików samego kodu , przy czym programista wpływa na jakieś 20-30 plików. Waga “luzem”: 1000 KB. Jest różnica ;]

Podsumowanie

KISS MVC wydaje się być całkiem porządnym frameworkiem obsługującym wzorzec projektowy Model-View-Controller, jednak nie jest to coś w czym pragnąłbym pisać zaawansowane witryny. Taka jest niestety prawda. Jeśli chcesz napisać sobie stronkę, która serwuje względnie statyczne dane, rzadko korzysta z bazy i nie ma wielu formularzy, to KISS jest super.

Jednak, gdy pisze się coś nieco bardziej zaawansowanego to zaczyna doskwierać brak niektórych udogodnień, z których słynie np. Kohana – pagination, wbudowany DAL, dynamiczne tabelki, walidator, autoryzacje i inne tego typu. Choć mi osobiście podoba się dodatkowo pomysł wykorzystanie omawianego frameworka w generatorze backendowego kodu stron internetowych.

KISS Principle, na bazie którego powstał KISS MVC daje z jednej strony uproszczoną oraz systematyczną formę tworzonego kodu, a z drugiej strony brak tu jakichś niuansów, które komplikowałyby sprawę. W wyniku działania takiego generatora kodu dostalibyśmy bardzo wydajny kod o dużym dopasowaniu, przy jednoczesnej korzystnej na potrzeby edycji i wprowadzania poprawek wizualnych architekturze aplikacji internetowej. Idea może i pokrywa się z pomysłem oferowanym przez Symfony, jednak na tyle na ile zdążyłem się zorientować Symfony marnie stoi z wydajnością.

Bibliografia i linki