(V)iew, przygłupi kolega każdego MC

15
kwi/10
28

Gdzieś tam w świecie przed firewallem, w wybranej aplikacji stworzonej przez wybranego programistę istnieje znany wszystkim kontroler. Ten sam kontroler, który właśnie przed chwilą otrzymał od dyspozytora pałeczkę przy przetwarzaniu żądania. Pobudzony i gotowy do działania ma na wyciągnięcie ręki półkę z modelami. Jest pewnego rodzaju pośrednikiem, tytułowany często strażnikiem cnoty widoku. Z modelów wyciąga tylko to co dla widoku najodpowiedniejsze. Gdy kontroler jest na służbie, wspomniany współpracownik niezdolny do samodzielnego myślenia może czuć się naprawdę bezpiecznie. Kontroler mógłby być więc niezwykle dumnym i bardzo szczęśliwym komponentem, chodzić z podniesioną głową wśród wzorca MVC. Niestety jest jeden mały szkopuł. W kontrolerze widać już oznaki wypalenia zawodowego. Nie ma co wieszać psów na biednym komponencie, że leniwy, że niedostosowany do wymagań wolnego rynku. To szefostwo zrzuca na niego coraz więcej obowiązków i zatrudnia oprócz niego jako widok, głąba. W swojej pracy codziennej nasz kontroler jest zasypywany przez programistę stosem zmieniających się kilka razy dziennie zamówień na coraz różniejsze porcje danych dla niegrzeszącego bystrością widoku. Tutaj z 5 newsów zrobiło się 7, tam trzeba pobrać dodatkowo pole z tabeli, a jeszcze gdzieś indziej użytkownik będzie chciał poznać aktualną datę. To tylko szczyt góry lodowej. A mogłem zostać marynarzem, powiedziałby kontroler.

Odkryłem dziś, że ASP.NET MVC jest żywą skamieliną, dzisiaj zobaczyłem go w akcji na wielkim ekranie. Nie zacząłem jednak pisać by używać sobie na tej technologii, nie w tym rzecz. Po prostu przypomniała mi o tym jak znienawidziłem przełączanie się pomiędzy widokiem, a kontrolerem podczas budowania większych szablonów. Bo w jakim wszechświecie żyje by tworząc jakiś widok dla końcowego użytkownika, być zmuszanym prosić inny komponent o wybranie dla mnie danych? Przecież ja wiem jakie dane i ile tych danych jest mi potrzebnych. To ja przecież tworzę widok, wiem czy chcę wyświetlić 10 czy 12 postów, wiem też po jakim kluczu je posortować, kto ma to wiedzieć lepiej ode mnie? Każą mi cały czas przeskakiwać do kontrolera by nanieść jakąś poprawkę, która wprowadza zmiany w de facto istniejącym gdzie indziej widoku. Dajmy trochę temu biednemu kontrolerowi odpocząć. Nawet nie chcę myśleć o sytuacji współpracy z jakimś profesjonalnym grafikiem tworzącym widok w jakimś języku szablonów. Już sobie wyobrażam cały dzień w którym zawraca mi przysłowiową gitarę co 5 minut, bo chce z danych coś nowego w swoim szablonie. Osobiście nie zbyt dobrze czuję się w multi-taskingu, szczególnie tym z wywłaszczaniem partyzanckim.

Do początku 2009 roku miałem okazję pracować prawie 2 lata przy projekcie wdrażanym z wykorzystaniem Zend Framework. Dokładnie pamiętam, jak wyglądały proste kontrolery:

public function indexAction() {
  $offers = new Offers();
  $offersCategories = new OffersCategories();
  $this->view->topOffers = $offers->fetchTop(5);
  $this->view->categories = $offersCategories->fetchAll();
}

Według mnie budowanie akcji w ten sposób to strata czasu. Już nie wspominając o fakcie, że przenieśliśmy część warstwy prezentacji tam gdzie nikt się nią interesować nie powinien. Dlaczego nie możemy odseparować widoku od widzimisię programisty kontrolera? Odwołać się do pobierania danych z modelu bezpośrednio?

<div id="categories"><ul>
<?php 
  $model = $this->models->offersCategories;
  foreach( $model->fetchAll() as $cat ): ?>
  <li><?php echo $cat->name; ?></li>
<?php endforeach; ?>
</li></div>

Pojawia się problem bezpieczeństwa: możliwość wywołania metod odpowiedzialnych za cały CRUD. W Pythonie oczywiście nie istnieje widoczność atrybutów i nikt nie robi z tego żadnych problemów, my jednak chcielibyśmy zapiąć w kwestiach odpowiedniego dostępu do danych przysłowiowy ostatni guzik. Rozwiązanie problemu nie powinno być trudne, wystarczy przekierowywać zapytania do konkretnego modelu przez klasę pośredniczącą i tam sprawdzać uprawnienia dostępu do poszczególnych metod. Model powinien implementować prostą metodę, którą można byłoby odpytać czy dana metoda jest metodą tylko odczytującą dane. O tym czy tak jest czy nie decydował by programista implementujący model:

interface IModel {
  public function isReadOnlyMethod( $name );
}

abstract class StandardModel implements IModel {
  protected $_readOnly = array(); // lista metod tylko do odczytu

  public function isReadOnlyMethod( $name ) {
    return in_array($name,$this->_readOnly,true);
  }
}

Klasa pośrednicząca także była by bardzo prosta:

class ViewModelProxy {
  protected $_model;

  public function __construct( IModel $model ) {
    $this->_model = $model;
  }

  public function __call( $name, $args ) {
    if( !$this->_model->isReadOnlyMethod($name) ) {
      $msg = sprintf('Method "%s" is not read only',$name);
      throw new Exception($msg);
    }
    return call_user_func_array(array($this->_model,$name),$args);
  }
}

Po przekazaniu jej konkretnego modelu w konstruktorze przekierowałaby wszystkie wywoływania funkcji, sprawdzając uprzednio czy metoda jest bezpieczna do wykorzystania w widoku. Ostatni element to wykorzystanie naszej funkcjonalności i wklejenie do jakiegoś helpera widoku. Bez kontenera zależności zaczęlibyśmy programować to w ten sposób:

class ViewModelsAggregator extends ArrayObject {
  public function __construct() {
    parent::__construct(array(), ArrayObject::ARRAY_AS_PROPS);
  }

  public function offsetGet( $name ) {
    $model = new $name();
    $proxy = new ViewModelProxy($model);
    return $proxy;
  }
}

Z wykorzystaniem helpera mamy w sumie 2 warstwy abstrakcji nad operacją pobierania wymaganych do wyświetlenia widoku elementów. Dzięki temu, w momencie, gdy chcielibyśmy w kontrolerze mieć wpływ z jakich modeli korzysta widok pozostaje nam dopisane kilku metod i wykorzystane ich w kontrolerze:

public function indexAction() {
  $model = new MySomethingElse();
  $this->view->models->set('offersCategories', $model);
}

To już wychodzi poza puste dywagacje na temat wyższości stosowania jednych praktyk MVC od innych. Mamy jak na dłoni sposób korzystania z modeli w widoku, który wciąż jest nie tylko bezpieczny, ale wydaje mi się także bardziej elastyczny i przyjemniejszy w codziennym stosowaniu.

Otagowane jako: ,
Komentarze (28) Odniesienia (0)
  1. batman
    08:35 on Kwiecień 15th, 2010

    Tak to już jest z MVC, że występuje w nim C. I nic na to nie poradzisz. Możesz oczywiście dowolnie modyfikować sposób wyświetlania danych w widoku, jednak podczas każdej aktualizacji frameworka (np. ZF), ryzykujesz, że zmiany w nim wprowadzone spowodują błędy aplikacji.

    Jeśli MVC Ci się nie podoba poczytaj o MVVM.

  2. Damian Tylczyński
    09:14 on Kwiecień 15th, 2010

    Osobiście nie obawiałbym się zbytnio problemu aktualizacji frameworka. Sam pomysł jest przecież niezależny od implementacji niemal każdego z dzisiejszych frameworków, typu: ZF, symfony czy też CakePHP.
    Miałem przyjemność przeszperać internet w poszukiwaniu materiałów na temat MVVM. Kawałek kodu, który zaprezentowałem dzieli z MVVM ideę separacji odwołań pomiędzy widokiem, a modelem. Jego architektura pomęczy mnie na pewno przez długi czas, dzięki za podpowiedź.

  3. batman
    11:24 on Kwiecień 15th, 2010

    Bardzo fajnie zostało to opisane na tym blogu http://nirajrules.wordpress.com/2009/07/18/mvc-vs-mvp-vs-mvvm/

    Należy jednak pamiętać, że nie wszystko da się w PHP zrobić. Nie wszystko się opłaca robić.

  4. Zyx
    12:08 on Kwiecień 15th, 2010

    No brawo, a jak ja o tym samym pisałem pół roku temu i przy okazji Yii, to zostałem zjechany przez jakichś „inteligentów”, że „nie rozumiem idei wzorców projektowych” (lol). Drogi Damianie, sprawa jest prosta – we frameworkach pod nazwą MVC nie ma żadnego MVC i tyle. Jeśli już, to MVP tam się implementuje.

    1. Widoki powinny właśnie pobierać dane bezpośrednio z modeli. Nie wiem, co masz na myśli pisząc o „bezpieczeństwie”. Przecież jedno i drugie i tak pisze ta sama ekipa programistów i tego kodu nie daje się klientowi czy komuś kompletnie z zewnątrz do rąk. Tak samo można rozważać, że niebezpieczne jest udostępnianie tych samych metod w kontrolerze; przecież tam też ktoś mógłby je źle wywołać. Od takich rzeczy jest dobrze zdefiniowany podział odpowiedzialności, testy i audyty.

    2. Trzeba zauważyć, że warstwa widoku też ma swoją logikę. Mamy szablon, który mówi, gdzie co wyświetlić, a mamy też i takie rzeczy, jak stronicowanie, sortowanie po tytułach kolumn… to są rzeczy charakterystyczne dla widoku, a nie dla kontrolera (przecież w MVC chodzi o to, by kontroler się nie musiał zajmować sprawami widoku). Rozwiązanie jest proste: widok to oddzielna klasa i w niej dopiero ewentualnie odpalany jest jakiś szablon. Klasa zajmuje się logiką widoku, szablon – prezentacją. W dodatku taka architektura umożliwia bardzo proste oddzielenie typu prezentacji (np. PDF zamiast HTML).

    3. Twierdzę również, że każdy kontroler powinien mieć swój własny widok to też nieporozumienie, które prowadzi do niepotrzebnego duplikowania kodu. Weźmy taki CRUD. Wszystkie frameworki się chwalą, jakie to są one cudowne, bo w 5 minut można panel administracyjny zrobić*. Tak, ale robi się to poprzez generatory kodu, gdzie jak chcemy dodać np. jakiś filtr danych nad wszystkie tabelki, musimy przez godzinę poprawiać po kolei wszystkie wygenerowane kontrolery i widoki do nich. A przecież wystarczyłoby zrobić uniwersalny widok CRUD, który sobie na podstawie dostarczonego modelu rozpozna interfejsy w stylu Sortable, Paginable, Filtrable i na podstawie tego dynamicznie wyświetli wspierane przez konkretny model elementy. Od czegoś w końcu jest ta obiektówka.

    * – szkoda, że nie pokażą, że aby zrobić CMS z dynamiczną konfiguracją układu strony, trzeba pół frameworka przepisać, albo narobić dziesiątki atrap.

  5. Tomasz Kowalczyk
    12:30 on Kwiecień 15th, 2010

    Zapomniałeś o jednej ważnej rzeczy – separacji widoku od kontrolera. Jeśli wsadzisz kod pobierania danych do szablonu, to zakładając, że programujesz aplikację posiadającą kilka różnych szablonów musisz w każdym z nich pisać ten sam kod. Jeśli te szablony faktycznie różnią się od siebie, pewnie przeniesienie kodu kontrolera nie będzie złym pomysłem, w każdym innym wypadku jednak pozostawiłbym go tam gdzie jest. Ogólnie to jest tak, że kontroler to taki handlowiec, który potrzebuje przygotować prezentację, a nie zna się na tematyce ani nie potrafi obsługiwać żadnego programu do ich tworzenia. Idzie więc do mądrego modelu, który daje mu odpowiednie materiały, z którymi kolei melduje się u grafika – widoku i mówi, weź te liczby i napisy i jakoś mi to narysuj. Idea polega na tym, że tych grafików może sobie nająć ilu chce, a w momencie, kiedy grafik sam idzie do mądrego modelu, to przestajemy mieć nad tym kontrolę, kiedy chcemy cokolwiek zmienić.

  6. Damian Tylczyński
    12:55 on Kwiecień 15th, 2010

    @batman po zapoznaniu się bliżej z MVVM okazuje się, że ten wzorzec jest bardzo specyficzny dla platformy .NET i WPF. Odpowiada na problem separacji kodu przy użyciu dwukierunkowych wiązań. Tam stworzenie warstwy pośredniczącej między modelem, a widokiem okazuje się bardzo praktyczne.

    @Zyx, dziękuję za brawa :)

    @Tomasz, problem starałem się opisać bardzo jasno. Widok wie jakie dane potrzebuje, nikt nie musi go w żaden sposób konfigurować, a co gorsza wstrzykiwać do niego danych – jest on osobną warstwą. Moim zdaniem popełniasz błąd przyjmując, że grafik, który ma kontrolę nad tym jakie dane chce wyświetlić to utrata kontroli. Wprost przeciwnie. Zrzucanie na programistów obowiązku niewolniczego usługiwania grafikom, gdy Ci muszą otrzymać dodatkowe dane jest mieszaniem odpowiedzialności. Grafik wie co chce wyświetlić i musimy mu umożliwić pobranie potrzebnych danych. Grafik nie odwoływał by się bezpośrednio do modeli, więc nie występuje problem braku kontroli. Mamy kontrolę nad warstwą pośredniczącą, mamy więc kontrolę w jaki sposób nasz grafik otrzyma te dane, z jakiego źródła, z jakimi metodami cache i tym podobne. Warstwa pośrednicząca jest kluczowa, to ona oddając odpowiedzialność za grafikę samym grafikom umożliwia programistą pełną kontrolę nad przepływem danych.

  7. Tomasz Kowalczyk
    13:22 on Kwiecień 15th, 2010

    @Damian: Wczytałem się jeszcze raz w Twój wpis i widzę, że to jest raczej kwestia podejścia, bo faktycznie, byłem w stanie wymyślić kilka przypadków gdzie zaproponowany schemat pasowałby lepiej niż mój własny. Szkoda, że nie widziałem komentarza Zyxa podczas pisania swojego, może wtedy podszedłbym do spawy inaczej. Mi kiedyś chodziła po głowie myśl na temat stworzenia jeszcze jednej warstwy abstrakcji w Modelu, tj. Modelu logiki [crudy i inne atomowe operacje] i Modelu biznesowego [zapożyczylem takie pojęcie z Inżynierii Oprogramowania ;] – chodziło o gotowe metody służące do pobierania konkretnych zestawów danych, ta warstwa byłaby „nad” modelem logiki]. Jak do tej pory nic z tego nie wyszło i dalej piszę, tak jak pisałem, ale pomyślę nad tym, może coś się wyklaruje. ;]

  8. Konradzik
    14:39 on Kwiecień 15th, 2010

    Ok, przykład z – pobrać 5 czy 10 postów? – ma faktycznie sens, fajnie by było uniknąć w takim wypadku zwracania się do programisty a pozostawienie tego w swerze kodera. Jednak problem wraca gdy tylko przyjdzie nowy projekt od grafika i koder stwierdzi że potrzebuje avatar autora / datę edycji ostatnią czy cokolwiek (co ‚mamy’, czego nie trzeba ‚dopisywać’). Do takich decyzji też chcecie robić dostęp z poziomu widoku? Mnie w tym momencie zaczęłoby już coś nie pasować. Jakoś też trudno mi uwierzyć, że koderzy ucieszyliby się gdybym im dał książeczkę 1000 funkcji które mogą wywołać jak będą czegoś potrzebowali – oni mają swój świat validatorów, marginesów itd.

    Może ja żyję w idealnym świecie, ale mam kodera z którym rozmawiam, grafika który rozmawia ze mną i z koderem, PM który rozmawia z nami i z szefostwem. I tak powstają projekty. ‚Klepnięty’ projekt wyglądu i funkcjonalności jest jednoznaczny i nikogo nie stać żeby go co chwilę diametralnie zmieniać. Jeżeli coś się w przyszłości zmieni i nastąpi ‚partyzanckie wywłaszczanie’ to nie jest to uporczywe.

    To o czym piszesz brzmi dla mnie jak DOBRA rada dla desperatów pracujących w ciężkich warunkach – mam nadzieję ich nie doświadczyć.

  9. Tomasz Kowalczyk
    15:22 on Kwiecień 15th, 2010

    Dokładnie o to mi chodziło w pierwszym komentarzu, dzięki za poparcie. ;] Wszystko jest ok dopóki pracujemy na pierwszej wersji, problemy pojawiają się wtedy kiedy przychodzi coś „istotnie” zmienić. Wtedy „wysławiasz pod niebiosa” każdą abstrakcję na jaką złorzeczyłeś za pierwszym razem. ;]

  10. Zyx
    10:38 on Kwiecień 17th, 2010

    Konradzik -> idealny świat sporo ułatwia, ale to rzadkość :). Niemniej trochę chyba przesadziłeś z tym 1000 funkcji :). Wszystko to kwestia dobrego zdefiniowania interfejsów i pomysłu, a problem polega jedynie na tym, że takie podejście jest rzadko stosowane i wielu programistów nie bardzo miałoby pojęcie za pierwszym razem, jak się do tego zabrać. Ja sam sporo koncepcji wymyśliłem dopiero w trakcie pierwszego projektu, jaki eksperymentalnie realizowałem taką techniką. I muszę stwierdzić, że jak się już wie, co robi, jest to o niebo wygodniejsze i szybsze, niż to, co prezentują „klasyczne frameworki”, nawet przy takich projektach hurtowych typu „przemyśl, napisz, sprzedaj, bierz kolejne zlecenie”. A przy długoterminowych projektach lub produktach jest to prawdziwe błogosławieństwo. Im mniej kontroler, widok i model wiedzą o sobie nawzajem i im lepiej zdefiniowane są interfejsy komunikacyjne między nimi, tym łatwiejsze jest utrzymanie. Mam jeden taki projekt zrobiony w ZF, który działa fajnie, ale na obecnym kodzie o jakiejś większej rozbudowie nie ma mowy, gdyż np. poważniejsze ruszenie struktury bazy mogłoby spowodować konieczność poprawiania np. 30 kontrolerów i połowy szablonów.

  11. egz
    09:57 on Kwiecień 19th, 2010

    „Widoki powinny właśnie pobierać dane bezpośrednio z modeli.”

    @Zyx – Nie, nie powinny. I co zrobisz? Odsyłam do samej definicji wzorców projektowych. Pamiętam Twoją notkę i podtrzymuję komentarz. Tak jak i tam wciskasz na siłę (inteligentom) swoją wersję implementacji, tak starasz się to zrobić tutaj.

    @Damian – bardzo ciekawe podejście. Tak właśnie powinno wyglądać „reimplementowanie” znanych rozwiązań.

  12. matipl
    12:34 on Kwiecień 21st, 2010

    Kilka spraw poruszyliście. Najpierw może sam wpis:
    bzdurne rozwiązanie, które tylko komplikuje życie. Pracowałeś na ZF? Trzeba było użyć helperów widoków, które właśnie do tego służą.

    @Zyx: zapomniałeś chyba dodać, że frameworki aplikacji webowych mają się nijak do MVC, a nie ogółem.

    @Zyx: rozwiązanie tutaj zaproponowane w warunkach korporacyjnych byłoby poważnie trudne do zaakceptowania, @Konradzik ma rację.
    Ale pamiętajmy, że są od tego helpery….

  13. Damian Tylczyński
    13:20 on Kwiecień 21st, 2010

    @matipl, proszę czytaj uważnie zanim napiszesz komentarz:
    „Ostatni element to wykorzystanie naszej funkcjonalności i wklejenie do jakiegoś helpera widoku.”

  14. matipl
    14:29 on Kwiecień 21st, 2010

    @Damian: proponowanemu rozwiązaniu dość daleko od prostoty prawdziwego pomocnika…
    Stąd moja informacja.

  15. Damian Tylczyński
    14:35 on Kwiecień 21st, 2010

    @matipl, nie wiem co jest prostsze od dynamicznego mapowania poprzez dodatkową warstwę abstrakcji. Osobiście wolę automatyzację i sposobność jej kontroli niż pisanie dla każdego zadania osobnego kodu. Pomocnik prawdziwy o którym mówisz to powinien sam sobie całą aplikację napisać na klawiaturze ;) A tak poważnie, korzystając z Twojego doświadczenia, czym jest dla Ciebie ten prawdziwy pomocnik? :) To zbyt skomplikowane by pomocnik zrobił coś ponad to, że dekoruje HTML?

  16. matipl
    08:31 on Kwiecień 22nd, 2010

    Helperów widoku staram się nie wykorzystywać do dekoracji.
    Kilka przykładowych: auth, ad, lastPost, messanger, translate.

  17. Damian Tylczyński
    19:35 on Kwiecień 22nd, 2010

    @matipl, ponawiając pytanie, co cechuje tego prawdziwego pomocnika? Dodatkowo, dlaczego nie nadaje się do wprowadzenia w „enterprise”? Wiem z praktyki, że przy większych projektach i dużych rotacjach w personelu ludzie często nie wiedzą co się stanie, gdy ruszą pewne części systemu. Jednak nie powinniśmy przyjmować, że zarządzanie systemu „enterprise” jest beznadziejnie, że nie ma dokumentacji i ludzie poruszają się w kodzie po omacku. Jestem ciekaw co dokładnie masz na myśli mówiąc, że to jest bzdurne i komplikujące życie rozwiązanie, gdy mi by ono je w znacznym stopniu ułatwiło. Mniej kodu, jasne zasady komunikacji model-widok, a nie klepane na poczekaniu „fraszki” w kontrolerze, które trzeba przyznać, są rzeczywiście przejrzyste i mało skomplikowane. Szeroki wachlarz możliwość po stronie „developerów interfejsu”, wybierają co chcą, rezygnują z czego chcą. Bez kontaktów z działem programistów, nie zajmującym się jakimiś bzdurami. Żyć nie umierać. Inne podejście do programowania? Inne doświadczenia z zespołem? Czekam na konstruktywną wypowiedź, jakieś uzasadnienie.

  18. matipl
    11:38 on Kwiecień 27th, 2010

    „dlaczego nie nadaje się do wprowadzenia w “enterprise”?”
    Nic takiego nie napisałem.

    „Wiem z praktyki, że przy większych projektach i dużych rotacjach w personelu ludzie często nie wiedzą co się stanie, gdy ruszą pewne części systemu.”
    Od tego są testy jednostkowe i funkcjonalne.

    i na tym EOT z mojej strony bo rozmawiamy o 2 światach.

  19. Damian Tylczyński
    18:06 on Kwiecień 27th, 2010

    @matipl, i na tym EOT też jak najbardziej z mojej strony, bo rozmawiamy o 4 różnych światach. Albo 5 światach. 6 światach? No bo… ja wiem… ale nie powiem.

  20. bigZbig
    15:05 on Kwiecień 29th, 2010

    Mam takiego kolegę, który używa kontrolerów (w Kohana PHP Framework) tylko po to aby pobrać dane i wrzucić je do widoku – równie dobrze mógłby przekazać do widoku obiekt modelu i kazać webdevowi samemu pobrać sobie wymagane dane i dopowiednio je przekształcić. Tak czy inaczej gdzieś musi być miejsce na tzw. obróbkę danych. Kiedyś pracowałem w Urzędzie Miasta – tam to się nazywało sporem kompetencyjnym. Damian dodatkowo poruszył problem pt. „kto się ma tym zająć” – z tego co pamiętam to nazywaliśmy to spychologią.

    No ok ale nie o to chyba chodzi Zyxowi czy Damianowi? Oni proponują odwrócenie flow. Z tego co zrozumiałem Zyxs proponuje aby frontend kontroler zamiast wywoływać kontroler „lokalny” który decydyje jakie dane pobrać i jakiemu widokowi je przekazać do wyświetlenia, wywoływał od razu widok (nazwijmy go świadomym), który pobierałby sobie niezbędne dane i w razie potrzeby użył dostępnych narzędzi do ich obróbki. Takim narzędziem byłby np. paginator, czy też komponent renderujący listę lub formularz. A ja się pytam czy taki widok byłby w takim razie dalej widokiem?

    Wracając do mojego kolegi. Jemu też się nie chciało wstępnie preparować danych np. generować url-i, obliczać cen brutto itp. A potem i tak dostawał na twarz te zadania tyle, że robił je w widoku zamiast w kontrolerze bo webdev jest od przesuwania boksów od 2 piksele do góry lub na dół a nie od martwienia się o to czy zbudował w widoku działające urle i czy cena brutto wyliczana jest poprawnie.

  21. matipl
    11:12 on Kwiecień 30th, 2010

    @bigZbig: dokładnie, aby widok był widokiem, pobranie danych i cała obróbka musi mieć miejsce gdzieś indziej (kontrol, helper widoku etc).
    Bo należy pamiętać, że widokami zajmują się frontendowcy, którzy potrafią usunąć wywołanie danej metody, a nie mówiąc co by było gdyby była tam większa logika.

  22. sokzzuka
    07:58 on Maj 4th, 2010

    Moim zdaniem front controller powinien na podstawie danych z requestu pobierać dane od modeli i wpychać je do odpowiedniego widoku, logika biznesowa powinna być w modelu.

    Moim zdaniem widok raczej powinien dostawać dane niż prosić o nie…

  23. thek
    09:57 on Maj 21st, 2010

    A ja poprę i autora i Zyx’a. Na forum php.pl także miałem post w dyskusji o wzorcu MVC i dla mnie powinien on dzialać jak dwukierunkowy trójkąt. Każdy z elementów powinien umieć się komunikować w pozostałymi. To, że we frameworkach wszystko idzie przez kontroler to pewien standard, który można jednak we własnych projektach sobie odpuścić. Jak dla mnie to o czym mówiono, czyli widok ma swój szablon jest dobrze widoczne we wszelkiego rodzaju stronach w sposób niejawny. To odwołania AJAXowe i ogólnie JS (jQuery m.inn.). Widok wyświetla pewien szablon, ale jego logiką kieruje JS. Odpowiada za choćby paginację czy tego typu elementy. Wtedy dzialanie wygląda tak:
    1. Wyświetl szablon strony ( szablon widoku )
    2. Pobierz domyślne ustawienia AJAX ( logika widoku )
    3. Pobierz dane i zwróć je ( model )
    4. Wypełnij szablon ( szablon widoku )
    Wszelkie zmiany na stronie to tylko zmiana logiki ( ustawień parametrów domyślnych czy tymczasowych ) widoku. Można więc powiedzieć, że programiści implementują funkcjonalność Widok Model ale na poziomie tworzenia kolejnego obiektu, którym jest obiekt AJAX, który też musi mieć swoje struktury wzorca MVC (M i C, bo tutaj akurat V jest zazwyczaj zbędny).

  24. anen
    23:08 on Maj 23rd, 2010

    Wógle sama idea trzymania się wzorca projektowego jest ciężka do pojęcia dla naszego mózgu :) Miałem przyjemność w lutym rozmawiać z gościem co tworzył ASP.NET MVC – koleś z holandi , od xx lat ma MVP ( tak wiem Microsoft – pojedzie po mnie ) ale to co on mi mówił – You have got Web Forms and MVC, normal person knows that where’s action there’s reaction but in MVC you get POST and GET (WTF).
    Prawda jest taka , php czy asp.net czy cokolwiek innego – nie zawsze MVC załatwia sprawę , a co bardziej MVVM , czasami liczy dobry projekt – wzorzec jest jako pomoc – nie wymóg( no chyba że specyfikacja mówi inaczej )

  25. Damian Tylczyński
    22:06 on Maj 24th, 2010

    @anen, Twój gość z Holandii poszedł trochę za daleko i próbuje porównywać paradygmaty porównując konkretne ich implementacje, nie same idee. Porównywał magię klasycznego ASP.NET w którym WebFormsy załatwiały za Ciebie niemal wszystko, a ASP.NET MVC w którym nie możesz być wykliko-sobie-mychą-programistą. A jest to związane tylko z implementacją tych dwóch frameworków, z trudnością obsługi. Nie uwarunkowaniem wzorców czy paradygmatów. ASP.NET też mógł wykorzystać wzorzec MVC, powiązanie zdarzeń z akcjami nie jest chyba jakimś wielkim problemem. Jednak Microsoft postanowił skopiować pierwszy lepszy framework istniejący już w sieci.

  26. anen
    22:37 on Maj 24th, 2010

    Ja tam uważam , że poprostu był pijany :) Informatycy Warszawcy mają dobre głowy skoro u nich idzie na uczelni kupić PIWO i Vodke :)

  27. MacDada
    23:48 on Lipiec 28th, 2010

    Sam jak dotąd widziałem rolę Kontrolera jako właśnie takiego pośrednika między Modelem a Widokiem; czyli Kontroler rozpoznaje co ma się dziać, odpala odpowiedni model, pobiera i interpretuje dane z modelu, na podstawie tego odpala odpowiedni widok, do którego przekazuje dane.

    Na forum.php.pl Zyx ujął MVC w inny sposób, który także prezentuje tutaj. Pod względem teoretycznym się z nim zgadzam. Wystarczy spojrzeć na diagram MVC na Wikipedii i wyraźnie widać, że Widok także może mieć bezpośredni dostęp do modelu.

    Stąd doszedłem do wniosku, że w praktyce zamiast MVC lepiej zrobić MVTC, czyli Model View Template Controller. W ten sposób mamy Kontroler, który odpala model i odpowiedni widok, widok odpala sobie w razie potrzeby model, a na koniec zbiera to co chce do kupy i przekazuje do Szablonu. W ten sposób wilk syty i owca cała, tzn Graficy bawią się jedynie na Szablonie, a jednocześnie Widok nie jest tylko Szablonem, ale zawiera także logikę Widoku w postaci paginatora, itp.

    Choć na razie to czysta teoria, bo takiego podejścia nie wypróbowałem i nie widziałem ;)

  28. MacDada
    01:07 on Lipiec 29th, 2010

    W sumie to co wyżej plus szczegóły pomysłu MVTC umieściłem na blogu:
    http://chaotycznie.pl/programowanie/mvtc-czyli-moj-pomysl-na-wzorzec-projektowy/

Niestety, skomentowanie tego wpisu jest niemożliwe.

No trackbacks yet.

Optimization WordPress Plugins & Solutions by W3 EDGE