Witam po raz pierwszy na 4programmers.net/Forum.
Piszę grę dwuwymiarową z użyciem JS i elementu Canvas. Stworzenie gry samej w sobie nie sprawia jednak żadnych trudności, zamęt wprowadza wzorzec MVC, którego muszę użyć. W książce A. MacCaw'a "JavaScript. Aplikacje WWW" autor opisuje go:
"MVC to wzorzec projektowy, który dzieli aplikację na trzy części: dane (Model), warstwę prezentacji (widok, czyli View) oraz warstwę interakcji z użytkownikiem (kontroler, czyli Controller). Inaczej mówiąc, przepływ zdarzeń przedstawia się następująco: 1. Użytkownik wykonuje jakąś czynność w aplikacji. => 2. Wyzwalana jest procedura obsługi zdarzenia kontrolera. => 3. Kontroler pozyskuje dane z modelu i przekazuje je do widoku. => 4. W widoku dane są przedstawione użytkownikowi." s.19
. Z tym się zgadzam. Model...
"Model nie wie nic na temat widoków ani kontrolerów - powinien on zawierać wyłącznie dane oraz logikę bezpośrednio związaną z tymi danymi. Jakikolwiek kod źródłowy, który nie jest z tym modelem związany - procedury obsługi zdarzeń, szablony widoków czy logika - powinien być wyraźnie oddzielony od modelu. Z ewidentną oznaką pogwałcenia reguł wzorca MVC mamy do czynienia wówczas, gdy w modelu napotyka się kod widoków. Modele powinny być całkowicie oddzielone od reszty aplikacji." s.19.
Widok...
"Podobnie jak modele, również widoki należy wyraźnie oddzielić od reszty aplikacji. Widoki nie powinny mieć żadnej styczności z kontrolerami i modelami, lecz powinny być całkowicie niezależne. Przenikanie się widoków i logiki jest pierwszym objawem nadciągającej katastrofy. Nie oznacz to jednak, że wzorzec MVC nie dopuszcza żadnej logiki prezentacji". Logika nie może być jednak definiowana wewnątrz widoków. Logika prezentacji musi znajdować się w tak zwanych bibliotekach pomocniczych (ang. helper), czyli w skryptach pełniących rolę niewielkich narzędzi przeznaczonych wyłącznie do obsługi widoków." s.20.
Kontroler...
"Kontrolery są spoiwem łączącym modele i widoki. Kontrolery przyjmują zdarzenia i dane wejściowe pochodzące z widoków, przetwarzają je (nierzadko z zastosowaniem modeli) i odpowiednio zmieniają widoki. W trakcie ładowania strony kontroler dodaje do widoków procesy nasłuchiwania zdarzeń, które mają za zadanie na przykład identyfikować fakt przesłania formularza albo kliknięcia przycisku. Potem, gdy użytkownik wykonuje z aplikacji jakieś działania, zachodzące zdarzenia wyzwalają czynności wewnątrz kontrolerów." s.21.
Według powyższych cytatów sposób jawnej komunikacji wygląda następująco: M <= C => V. Można by też zaproponować że Kontroler tworzy Model i Widok i zna udostępniony przez nie interfejs. W sytuacji, gdy zachodzi jakieś zdarzenie Kontroler powiadamia model o zmianie danych i po ich zmianie musi uaktualnić widok. W jaki sposób model poinformuje kontroler, że wykonał już zadanie? Można wrzucić do modelu pustą funkcję, która będzie uruchamiana po wykonaniu czynności. A to co w niej będzie uruchamiane musi ustawić wcześniej kontroler za pomocą funkcji ustawiającej modelu. Podobnie można zrobić z widokiem. A co jeśli model będzie zawierał dane cyfrowe planszy gry w postaci dwuwymiarowej tablicy wypełnionej znakami. Widok aby narysować planszę musi najpierw pobrać dane z modelu, następnie przetworzyć zamienić je na obrazki i wyświetlić. I tu znowu problem. Widok nie powinien zawierać skomplikowanej logiki wyświetlania. Ale można by zrobić dodatkowe narzędzia pomocnicze, które się tym zajmą. To jakoś można pociągnąć. Ale co z tymi danymi? Jak widok ma je pobrać z modelu skoro nie wie o jego istnieniu. Nie wie również o istnieniu kontrolera czyli nie zna interfejsu, który udostępniają. Spoko to też można minąć, jeśli dane "wepchnie" mu kontroler. Ale co z obrazkami. Widok podmienia dane cyfrowe na obrazki i wyświetla. Ale obrazki to też dane gry, czyli powinny być w modelu. Tylko, że każdy obrazek ma nazwę. A skąd widok ma znać ich nazwę skoro należą one do modelu? i tu zaczynają się pytania. Co zrobić z tymi obrazkami? Jak wykonać widok aby mógł je przetworzyć nie znając danych cyfrowych, obrazków i sposobu mapowania? Gdzie powinna zawierać się logika (tzw. inteligencja) gry? w modelu? czy kontrolerze? a może tu i tu? W książce Eric'a Rowell'a "HTML5 Canvas Receptury" autor przedstawia kod gry opartej na modelu MVC. "Canvas Hero" - "http://www.html5canvastutorials.com/cookbook/ch8/index.html", która w gruncie rzeczy nie wydaje mi się zgodna z założeniami pierwszego autora. Proszę o pomysły i opinie. Dziękuję serdecznie i pozdrawiam.