[MVC] Pytań kilka... Opcje

[hawk]

Jak napisal scanner ze jeden z takich MCV jest dostepny na necie oczywiscie tam zagladolem. Ale niestety moja wiedza tajemna nie byla wstanie przegrysc samego manuala, wiec o testach na phiendzie nie bylo mowy.

Hmm, jako autor phienda potwierdzam że proste to-to nie jest. A moje anty-patriotyczne podejście do lokalizacji manula :oops: niektórym nie ułatwia sprawy. Ale podobno gdzieś tutaj na forum powstaje tłumaczenie.

Ja myślę że kojarzenie MVC z warstwami jest zbytnim uproszczeniem. Owszem, MVC wymusza podział aplikacja na warstwy (w ogóle wymusza sensowną organizację aplikacji). Ale warstw może być więcej niż 3, np:

1) baza danych (mySQL)
2) warstwa abstrakcji nad bazą danych (ADODB)
3) klasy Modelu (php)
4) Kontroler (php)
5) klasy Widoku (php)
6) szablony Widoku (Smarty)
7) wynik końcowy (HTML)

To daje 7 warstw . Dzielić można różnie, ale ważne jest to, że wg. MVC aplikacja powinna mieć 3 główne częśći:

1) Model: logika biznesowa, operacje na źródle danych (np. baza danych), nic nie wie o HTML

2) Widok: logika prezentacji, czyli nie tylko szablony (ale implementacja Widoku za pomocą szablonów jest dobrym pomysłem), wie jak wyciągnąć potrzebne dane z Modelu

3) Kontroler: zbiera to wszystko do kupy, wie że jest żądanie strony i decyduje co należy zrobić żeby wygenerować odpowiedź

MVC pozwala łatwo modyfikować aplikację, np. zmieniać bazę danych, strukturę URLi, wygląd strony, przejść z HTML na PDF, itd. Bo jest podział odpowiedzialności i hermetyzacja.

Tak na marginesie chciałem zapytać skąd czerpaliście informacje na temat MVC?

Niektórzy, nie chwaląc się, czerpali m.in. z dokumentacji phienda , ale poza tym polecam artykuły w php|architect z maja i czerwca 2003. Jakoś trafiłem na promocję i darmowy numer.

Poza tym, jak tylko ruszy portal php.pl, pokaże się na nim mój obszerny artykuł na ten temat. Na razie leży sobie gotowy w DocBooku i czeka, aż będzie gdzie go umieścić.

[bumelang]

Tak na marginesie chciałem zapytać skąd czerpaliście informacje na temat MVC?

Ja prywatnie znam to zagadnienie z Javy, gdzie jest kilka framework'ów MVC - np. Struts albo WebWorks i też kilka książek dotyczących wzorców projektowych. Nie mniej, jeśli nie znasz Javy, to niewiele Ci to pomoże - ale na lekturkę być może warto zawsze się szarpnąć, bo koncepcja jest wspólna.

Jak napisal scanner ze jeden z takich MCV[...]

Mylisz trochę pojęcia - MVC to nie jakiś program czy skrypt, tylko strategia pisania interface'u użytkownika. Taką strategię w bardziej rozwiniętych obiektowo językach nazywa się wzorcem projktowym. Ten wzorzec definiuje po prostu, że ma być ten model, view i controller i jak mają ze sobą współpracować. Wybór konktretnego ułatwiacza to nie wybór MVC.

A co do tego, co napisałeś potem, to chyba za bardzo namieszałem z tymi warstwami. MVC nie ma z tym nic wspólnego. Model, widok i kontroler to 3 klasy i tylko tyle. Teraz, jeśli masz aplikację pisaną w architekturze 3-warstowej, to tak wychodzi, że kontroler i widok są w warstwie klienta (prezentacji) a model w warstwie logiki biznesowej. Ale ogólnie mówiąc architektura 3-warstwowa jest niezależna od MVC jako pojęcie.

Działa to tak: użytkownik wysyła żądanie w sensie HTTP, np. wypełnia jakiś formularz i klika "Submit", gdzie akcja formularza jest ustawiona na skrypt, w którym znajduje się kontroler. Ten łączy się z modelem, wywołuje tam jakieś metody biznesowe i gdy te zwrócą mu już efekty swojej pracy, to w zależności od tego, jakie one są, przekazuje to wywołanie do odpowiedniego widoku, czyli odpowiedniej strony php (która może być napisana w Smarty). W php w najprostszym wariancie może być to po prostu
[php:1:a43ca395d1]<?php
/* Kontroler */
if($model->zaloguj($login, $haslo) == SUCCESS) //wywołanie modelu
include("strona_glowna.php"); // wywołanie widoku
else
include("blad.php"); // wywołanie innego widoku
?>[/php:1:a43ca395d1]

Różnica w architekturze pomiędzy MVC a jego brakiem jest taka, że bez MVC logika jest zaszyta w kontrolerze (można powiedzieć, że nie ma warstwy logiki). Nie można jednak traktować Smarty jako kolejnej warstwy, bo to nie o to chodzi.

Natomiast aplikacja może być 2-warstwowa w takim sensie, jak napisałem wtedy, jak nie ma bazy danych, tylko np. coś liczy. Wtedy warstwa danych nie istnieje, nie że łączy się z jakąś inną w jedność.

Mam nadzieję, że nie zaciemniłem za bardzo obrazu tymi warstwami

[DeyV]

jak już trwa taka zaciekła rozmowa na temat MVC, to zauważę, że warto ponownie zainteresować się ciekawym systemem WACT http://www.phppatterns.com/index.php/artic...cleview/85/1/9/
System ten, poza paroma ciekawymi innowacjami, pokazuje również (z tego co zdążyłem się zorientować po paru minutach przegladania) bardzo ciekawy sposób komunikacji pomiędzy modelem a widokiem, któy pozwala na przeniesienie zainicjowania procesu pobrania danych przez view, dopir0o w momencie, gdy te dane będą mu potrzebne.
Chyba nie trzeba nikogo przekonywać, jak często takie rozwiązanie może być bardzo przydatne.

[hawk]

Hmm, ciekawe...
Z tego co na razie widziałem, WACT ma bardzo fajny system szablonów. Wspominał o tym gdzieś Nalfein (ale o idei, nie o WACT): wyciągać dane z modelu tylko wtedy, kiedy widok naprawdę ich potrzebuje, a nie jak np. w Smarty najpierw wyciągać, a potem zobaczymy czy widok w ogóle z nich skorzysta. To jest wielki plus.

I sam język szablonów jest ładny, taki XML-owy . Czyli podobny do Struts w Javie. Albo nie do samego Struts, ale do JSP generalnie. Taka strona wygląda jak JSP i działa mniej więcej jak JSP.

Ale nie widziałem tam jeszcze samego kontrolera :? . Może dlatego że coś mi strona WACT kiepsko działała. Anyway, gdzie tam jest założenie, że mamy jeden główny skrypt (kontroler) i akcje? Gdzie rozdział między akcjami a modelem? W tutorialu widziałem SQL przemieszany z assignami do szablonu.

No ale niedokładnie szukałem, a sam WACT jest pre-alpha. Na razie wydaje mi się, że to jest świetne rozwiązanie widoku, ale nie całego MVC.

[scanner]

Hmm, jako autor phienda potwierdzam że proste to-to nie jest. A moje anty-patriotyczne podejście do lokalizacji manula :oops: niektórym nie ułatwia sprawy. Ale podobno gdzieś tutaj na forum powstaje tłumaczenie.

Jako szef Content Teamu Mogę powiedzieć, że tłumaczenia już jest gotowe, niestety tłumaczka nie miała do dyspozycji edytora XML, zatem ja żmudnie w wolnych chwilach przenosze wszystko z Worda. Dostępne na CVS'ie (dla developerów) jest już 4,5 rozdziału i byłbym wdzięczny hawk, gdybyś na to zerknął. Jutro powinieniem dodać końcówkę 4 i może cały 5 rozdział.
Hawk: w razie uwag, proszę na PW lub maila

Dokumentacja phienda po polsku w założeniach ma ukazać się na php.pl.

[cagrET]

Anyway, gdzie tam jest założenie, że mamy jeden główny skrypt (kontroler) i akcje? Gdzie rozdział między akcjami a modelem?

Jeżeli dobrze doczytałem to doszli do wniosku, że kontroler jest zbędny w php. Kod jest mniej elastyczny, trudniej jest go zintegrować z innymi aplikacjiami. Za kontroler uznano sam Apache, a akcjami są pliki .php

czyli struktura aplikacji jest w stylu:

/news/view.php
/news/list.php
/news/edit.php

/forum/viewTopic.php
/forum/viewForum.php

etc

[Nalfein][WR]

Jeżeli dobrze doczytałem to doszli do wniosku, że kontroler jest zbędny w php. Kod jest mniej elastyczny, trudniej jest go zintegrować z innymi aplikacjiami. Za kontroler uznano sam Apache, a akcjami są pliki .php

Wow! A już myślałem, że tylko ja jestem taki crazy, żeby zrywać ze wszystkimi standardami ;P Założenia bardzo fajne, popieram wszystkiema ręcami i nogami.

Ale to ma też minusy, bo nie można dać dwóch urli (np. pl-"electronics" i en-"elektronika") pod jedną akcję, chyba, że będziemy chamsko robili require() przy w drugim pliku. Dlatego robię u siebie akcje tylko wywoływane (wybierane) ze skryptów w "site dir", a implementecje są dalej w "code dir". W ten sposób zyskuję to co chcieli w WACT - eliminuję router (do pewnego etapu - pliki w "site dir" mogą być routerami, bo mogę napisać /forum/viewpost.php/110), ale zachowuję możliwość zmiany URLi bez zmiany nazwy pliku z akcją.

[hawk]

Minusów jest więcej:
- Co zrobić, jak tego pliku akurat nie ma? Kontroler sobie poradzi, Apache nie.

- Nie każda akcja musi kończyć się wyświetleniem HTMLa - patrz akcje logiki. A tak co? Robić require w tych plikach, i skończyć z taką siecią powiązań?

- Jak będziesz chciał zmienić np. lokalizację WACT, albo jakiekolwiek inne ustawienie globalne, to globalny regexp po wszystkich plikach albo z godzinka roboty...

Jest różnica pomiędzy wywaleniem w ogóle kontrolera, a eliminację routera. Chociaż pojęcie routera jest nasze autorskie i nie występuje w MVC. Hierarcha katalogów jako sposób wybierania akcji do wywołania OK, ale oni idą znacznie dalej.

BTW, trochę zabawne że oni mimo to piszą o MVC. Zrobiliśmy framework oparty o wzorzec Model-View-Controller, ale wywaliliśmy z wzorca cały kontroler . Co nie znaczy że wszystko co dobre musi być MVC. Ale jeżeli ktoś usilnie stara się przedstawić swój projekt jako MVC, to o czymś świadczy...

[Nalfein][WR]

Nie wywalili kontrolera, ale wywalili obiekt typu FrontController. Akcje logiki to też przecież warstwa kontrolera.

[hawk]

Ale warstwa kontrolera bez kontrolera?
To tak jak system bazodanywy bez bazy danych. Albo aplikacja obiektowa bez obiektów.

Zresztą, u nich nie ma akcji logiki.

[Nalfein][WR]

Chyba za dużo nad Phiendem przesiedziałeś To tak jak rozproszona baza danych (np. pliki XML) czy jak aplikacja obiektowa bez menedżera obiektów. Ja robię to tak np. w pliku /forum/view.php mam:

[php:1:17e5bd469d]
<?php
$app = CodeZone::instance();
$action = $app->create('ViewForumAction', 'actions/forum');
$app->run($action);

// albo $app->execute($request, $response, $action);
// aby realizować testy XP z obiektami FakeRequest oraz FakeResponse
?>
[/php:1:17e5bd469d]

Metoda ::run() klasy aplikacji przekazuje obiekt $action do kontrolera wraz z obiektami $request, $response, które tworzy. Kontroler obsługuje żądanie wypełniając $response, a aplikacja wyrzuca wynik na ekran. Nie wywołujemy tutaj jawnie kontrolera (FrontControllera), przez co możemy w ogóle z niego zrezygnować w prostych aplikacjach, a może za tym wszystkim siedzieć nawet Phiend2.

© Paladine Framework

[cagrET]

- Co zrobić, jak tego pliku akurat nie ma? Kontroler sobie poradzi, Apache nie.

Już raz to gdzieś pisałem

Kod

<IfModule mod_rewrite.c>

    RewriteEngine On

    RewriteCond %{REQUEST_FILENAME} !-f

    RewriteCond %{REQUEST_FILENAME} !-d

    RewriteRule ^(.*)$ error/404.php [L]

</IfModule>

- Nie każda akcja musi kończyć się wyświetleniem HTMLa - patrz akcje logiki. A tak co? Robić require w tych plikach, i skończyć z taką siecią powiązań?

Nie rozumiem co miałeś tutaj na myśli. Kto powiedział że każda akcja musi się kończyć wyświetleniem htmla ? Jaka sieć powiązań ? To właśnie użwając FronControllera jest dużo niepotrzebnych includów.

- Jak będziesz chciał zmienić np. lokalizację WACT, albo jakiekolwiek inne ustawienie globalne, to globalny regexp po wszystkich plikach albo z godzinka roboty...

Bardziej cenię sobie elastyczność. Ty już jesteś przyklejony na zawsze do tych ustawień globalnych. Ja mam wolną rękę. A gdy potrzebuję globalnych zmian REGEXP jest idealnym narzędziem

BTW, trochę zabawne że oni mimo to piszą o MVC. Zrobiliśmy framework oparty o wzorzec Model-View-Controller, ale wywaliliśmy z wzorca cały kontroler . Co nie znaczy że wszystko co dobre musi być MVC. Ale jeżeli ktoś usilnie stara się przedstawić swój projekt jako MVC, to o czymś świadczy...

Nie zapominaj że php jest językiem skryptowym. Nie widzę sensu kopiować wszystkiego krok w krok z innych języków, bo w php się to po prostu nie sprawdza. O kontrolerze już pisałem że jest, tylko inaczej pojmowanym.

[hawk]

To w takim razie każda aplikacja w php jest oparta o wzorzec MVC, bo w każdej występuje Apache jako kontroler. Dochodzimy do absurdu.

[Sh4dow]

Hmm, tak szczerze mowiac, to kazda strona napisana w php, z wykozystaniem, bazy danych, jest juz oparta na modelu MVC.
Jesli dobrze wszystko rozumiem, to kazda strona dziala na takim założeniu. Dziwne by to chyba wygladało jak by szlo to w odwrotnym kierunku.
zeby nie zrobic gafy opieram sie na zend.com. Chyba kazda strona pobiera najpierw dane, pozniej dane sa obrabiane w tak zwanej "business logic" a na koncu sa/"moga byc" wyswietlane.
mam nadzieje ze teraz rozumiem to, jakos prawidlowo. Patrzac na to co wy mowicie, to jedyne czym moga sie roznic "wasze" strony od "moich" (mowie tutaj o sposobie pisania) to jest taka ze wy tworzycie zaawansowane klasy, a ja siedze jeszcze po czesci w procedurach.

[Nalfein][WR]

To w takim razie każda aplikacja w php jest oparta o wzorzec MVC, bo w każdej występuje Apache jako kontroler. Dochodzimy do absurdu.

Jeśli uważasz, że wzorzec FrontController-a = całe MVC to może i tak Tylko, że Apachem możemy wskazać jeden obiekt MVC, zależnie co mamy pod urlami - akcję lub widok. Chyba, że w plikach .php wybieramy widok i akcję wypełniającą widok (ViewController jak się zresztą ją określa) - wtedy mamy taki rozproszony kontroler, a Apache robi za router.

[KaGe]

OK
MVC itd...
Ale jak to wygląda w praktyce? - w momencie, gdy mamy zabrać się za pisanie właściwego projektu - opisać klasy itd...

czy ktoś ma jakiś gotowy wykresik prezentujący np. podział klas na MVC - w miarę dokładny?

Bo z tego co tu się pojawia to ja to widzę jakoś tak:

+KONTROLER © - max nadrzędnie
|- MODEL_a (M) - ściąga dane z bazy i operuje na nich fizycznie
|- MODEL_b (M) - inna klasa operująca na danych - np. danych usera itd..
|- MODEL_c (M) - jeszcze co innego - np. odpowiedzialnego za newsy, artukuły itd...
|- WIDOK (V) - dostaje info z kontrolera - po przetworzeniu odpowiedniego modelu i wyświetla to lub tworzy plik z wynikiem - w każdym bądź razie jest wywoływany na końcu i zajmuje się tylko prezentacją

Czy dobrze rozumuję?

[marcin96]

http://phppatterns.com/index.php/imagecata...cleview/19/1/1/

...tyle tylko, że w większości frameworków MVC masz jeden obiekt kontrolera, który wywołuje odpowiednie akcje/widoki w odpowiedzi na dane wejściowe. Model łączy się z akcjami/widokami poprzez agregację (czyli tak jak na tamtym diagramie) lub kompozycję (a nie przez dziedziczenie... bo wtedy to już masz model zagnieżdżony w akcjach/widokach.. a tego chcemy uniknąć przeważnie - inaczej to nie jest MVC ) ). Czyli jedyne co robisz w widokach/akcjach, to wywołujesz odpowiednie metody odpowiednich modelów. Przynajmniej ja tak to wszystko rozumiem ]

[KaGe]

Diagram widziałem, napisałem sobie nawet własne MVC - dokładnie takie samo, ale dot. czego innego - żeby się nauczyć. - nauczyłem się tego.
Ale:
1) jakbym chciał zrobić usuwanie, doadawanie itd.. - to gdzie dodać odpowiedzialne za to funkcje? - chyba do modelu, ale tam model jest tak zrobiony, że nie odpowiada konkretnemu zbiorowi danych w tabeli a jedynie służy za narzędzie. Więc może do kontrolera? - ok, ale on musiałby przekazać to wszystko do modelu i patrze pkt. wyżej....
2) nigdzie tam nie ma ustalonego id dla OKREŚLONEGO odpowiednika w bazie danych!! - ja wiem, moze nie do konca rozumiem OOP itd.. ale czy to nie jest troche malo uniwersalne, jezeli tylko kontrolerowi podaje id do wyswietlenia i nie moge potem np. zrobic tak:
[php:1:a31b6f25fe]<?php
$a = new ArticleSingleController($dao,$_GET); // gdzie $_GET[id]=2
$a-> // i tu jakos podzialac zeby display wyswietlil np. 3 art.
echo $a->view->Display();

?>[/php:1:a31b6f25fe]
Da sie tak?

[marcin96]

ad 1) poczytaj dokumentacje phienda )

http://phiend.sourceforge.net/manual/actions.html <- zwlaszcza to pomoże...

W akcjach/widokach wywolujesz jedynie odpowiednie metody modelu. np
[php:1:121515932c]<?php
$ProductModel->DeleteItem($_GET['id']); // to będzie w akcji odpowiedzialnej za usuwanie
$ProductModel->UpdateItem($_GET['id'], $_POST['data']); // a to w akcji odpowiedzialnej za update..
?>[/php:1:121515932c]

Dopiero w modelu trzymamy SQL, czy cokolwiek innego odpowiedzialnego za usuwanie, modyfikacje.. czy zwracanie danych.

ad 2) w tym przykladzie jak zobaczysz na zrodlo ( http://phppatterns.com/index.php/article/a...cleview/19/1/1/ ...bo chyba podałem wczesniej link przypadkiem tylko do samego diagramu..), to kontroler tak naprawde zostal zrealizowany w index.php:
[php:1:121515932c]<?php
switch ( $_GET['view'] ) {
case "product":
$controller=& new ProductItemController($dao,$_GET);
break;
default:
$controller=& new ProductTableController($dao,$_GET);
break;
}
?>[/php:1:121515932c]

Tamten przykład podałem aby pokazać zależność między widokami/akcjami a modelem.. natomiast jak dla mnie realizacja kontrolera jest całkowicie bezsensowna... Naprawdę polecam lekturę Phiend'a. Na stronie projektu ( http://sourceforge.net/project/showfiles.p...?group_id=90219 ) też jest źródło aplikacji, którą masz tutaj:
http://phiend.sourceforge.net/application/

[KaGe]

1) Czy mam w takim razie do kontrolera, oproocz $model i $view dodać np. obiekt $action , który będzie działał na modelu? czy po prostu do samego modelu dodac odpowiednie metody?

2) A moze po prostu w modelu owszem, dopisac metody usuwania itd... a potem w kontrolerze - odpowiadające im, ale juz przekazujące identyfkatory i dane? - czy tak bedzie dobrze?

3) Jeszcze jedna sprawa: Tak mi sie wydaje, ze jak robie strone w MVC to:
powinien byc 1 kontroler - ktoory by wszystko tworzyl, ustawial, usuwal itd...
modele : odpowiedzialny za baze danych, odpwiednie do newsoow itd.. ,
widoki : prezentacje kazdego z modeli do newsoow itd...

Teraz tak:
czy nie powienien byc jeszcze jeden model i odpowiadajacy mu widok : np. o nazwie SiteModel i SiteView - ktoore odpowiadaly by za cala strone?
i np: SiteView to cos takiego:
[php:1:21abc83259]<?php
Class SiteView
{
var $views;
var $model;
var $output;

function SiteView($model)
{
$this->model = $model;
}

function AddView($view)
{
$this->views[] = $view;
}

function Header()
{
// naglowek <html> itd...
}

function Footer()
{
// /html itd...
}

function Site()
{
foreach($this->views as $n => $view)
{
$this->output .= $view->Display();
}
}

function Display()
{
$this->Header();
$this->Site();
$this->Footer();
return $this->output;
}
}
?>[/php:1:21abc83259]

Czy to jest dobre rozwiązanie?
jak np. chciałbym wyswietlic newsy to tylko bym dal w kontrolerze, ze

[php:1:21abc83259]<?php
$news= new NewsModel;
$newsview = new NewsView($news);

$siteview = new SiteView;
$siteview->AddView($newsview);

// a potem juz tylko:
echo $siteview->Display();

?>[/php:1:21abc83259]