[MVC] Czy dobrze interpretuję ?, ciągle to mvc :( |
[MVC] Czy dobrze interpretuję ?, ciągle to mvc :( |
25.05.2007, 22:02:58
Post
#1
|
|
Grupa: Zarejestrowani Postów: 278 Pomógł: 10 Dołączył: 13.02.2007 Skąd: Rybnik Ostrzeżenie: (0%) |
Witam,
Ciągle zastanawiam się, czy dobrze interpretuję zasadę MVC. Chciałem napisać coś takiego: KONTROLLER: Index.Controller.php: Pobiera $_GET['view'] i zwraca $this -> setView():
Następnie MODEL pobiera dane z mysql z danego projektu i zwraca:
W ostateczności Widok pobiera wszystko i generuje HTML:
Męczy mnie także pytanie, jak to wszystko połączyć, zeby działało? Chodzi o większą ilość widoków, lub modeli. Proszę mnie nie odsyłać do artykułów, bo z nich nic się (niestety) nie można dowiedzieć. Pozdrawiam, Matix: ) Ten post edytował matix 25.05.2007, 22:03:54 -------------------- Nawet, jeżeli nie jesteś zainteresowany usługami IT ani outsourcingiem, a Twoją pasją jest programowanie - zobacz naszą stronę. Piszemy dużo fajnych use-caseów, jak podchodzimy do tematu programowania dla naszych klientów. A tak na co dzień tworzymy budujemy mvp oraz tworzymy platformę b2b.
|
|
|
25.05.2007, 22:10:37
Post
#2
|
|
Grupa: Przyjaciele php.pl Postów: 1 224 Pomógł: 40 Dołączył: 6.07.2004 Skąd: Wuppertal Ostrzeżenie: (0%) |
kontroler:
- sprawdza dane z geta, posta itd itd - decyduje ktora akcje wykonac model: - pobiera//wstawia//edytuje dane w bazie - obrabia dane, ogolnie operacje na informacjach widok - wyswietlanie akcja - uzywa modeli zeby cos wykonac np akcja showNews uzywa modelu news (np $newsFinder->getNews($id)), i wywoluje odpowiedni widok a on wyswietla to co zostalo pobrane |
|
|
25.05.2007, 23:00:33
Post
#3
|
|
Grupa: Przyjaciele php.pl Postów: 1 467 Pomógł: 13 Dołączył: 22.02.2003 Ostrzeżenie: (0%) |
Widok wywołuje model aby pozyskać dane lub kontroler gdy wywołana zostanie akcja. Widok może też zostać zmieniony niezależnie od kontrolera ani modelu, np. przy zmianie kryteriów sortowania. Obsługuje "logikę wyświetlania".
Model zmienia widok, gdy sam zostanie zmieniony, nie wywołuje kontrolera. Przechowuje informacje. Obłsuguję "logikę danych". Kontroler zmienia model oraz obsługuje akcje. Kontroler to logika aplikacji. Akcja - to zapytanie do kontrolera, wywołanie kontrolera. Nie wydaje mi się też żeby kontroler decydował którą akcje wykonąć. To akcja decyduje który kontroler wywołać. Co do przykładu powyżej. ShowNews to akcja, która wywołuje kontroler News. Kontroler ten nie modyfikuje modelu, wyświetla natomiast widok, który pobiera z modelu dane. Raczej tak rysowłabym te zależności. Dlatego przygotowywanie danych do wyświetlenia już na poziomie kontrolera to troszkę wg mnie za wcześnie. To powinien zrobić widok. To taki prosty opis zależności. Widok może mieć odniesienia do akcji różnych kontrolerów. Tak samo kontroler po wywołani może zmienić widok - nie tylko zmienić aktualny widok, ale również zmienić samą instacje widoku. Tak to łaczysz. Pozdrawiam Ten post edytował Jabol 25.05.2007, 23:07:04 |
|
|
26.05.2007, 08:48:38
Post
#4
|
|
Grupa: Zarejestrowani Postów: 382 Pomógł: 0 Dołączył: 29.11.2005 Skąd: :jestem(); Ostrzeżenie: (0%) |
Hm...ja korzystam z trochę innej interpretacji, możliwe że prostszej, może Ci się przyda ten opis ale uwag też chętnie posłucham.
Mam jeden plik index.php który jest jądrem (logiką) aplikacji, jeden plik Controller który filtruje dane z GET i POST po czym odpala odpowiednią akcję (której nazwa i paramerty są w URL). Akcja wykonkuje operację na modelu po czym ustala nazwę widoku. Całość pracy polega na dodaniu pliku akcji i szablonu widoku. Można przygotować odpowiednie wersje Controllera pod różne rodzaje URLi, a obecnie testuję różne szablony bo smarty wg xDebuga trochę mi zbyt wiele czasu wykonania skrytpu zabierają. Rozumiem jak działają łańcuchy akcji ale nie potrafię ich zaimplementować, napisać (np. jak przechodzić z akcji do akcji i w jakiej postaci zwracane sa ewentualne wyniki (błędy) wykonanej akcji ?). Ten post edytował jastu 26.05.2007, 12:23:59 -------------------- Powyższy post wyraża jedynie opinię autora w dniu dzisiejszym. Nie może on służyć przeciwko niemu w dniu jutrzejszym. Ponadto autor zastrzega sobie prawo zmiany poglądów, bez podawania przyczyny.
|
|
|
26.05.2007, 08:49:22
Post
#5
|
|
Grupa: Zarejestrowani Postów: 118 Pomógł: 3 Dołączył: 6.07.2006 Skąd: Dublin Ostrzeżenie: (0%) |
Jeśli nie zamierzasz wywoływać metody statycznie, zamiast:
bardziej po bożemu było by tak:
Jeśli natomiast masz zamiar używać metody statycznie - konstrukcja winna wyglądać:
(To tak na marginesie jeśli mówimy o PHP5 ) -------------------- -----------------------
My hovercraft is full of eels! |
|
|
26.05.2007, 09:07:45
Post
#6
|
|
Grupa: Zarejestrowani Postów: 278 Pomógł: 10 Dołączył: 13.02.2007 Skąd: Rybnik Ostrzeżenie: (0%) |
Ok,
mniej więcej rozumiem i dziękuję za wszystkie przemyślenia na temat MVC. Mam teraz pytanie, czy np: Skrypt, który odbierze zmienną $_GET['type'] i wyświetli odpowiedni dla niego sposób widoku, będzie w kontrolerze ? Jeśli tak, to w jaki sposób powinien wyglądać ? Może tak:
Dałoby to radę? Pozdro -------------------- Nawet, jeżeli nie jesteś zainteresowany usługami IT ani outsourcingiem, a Twoją pasją jest programowanie - zobacz naszą stronę. Piszemy dużo fajnych use-caseów, jak podchodzimy do tematu programowania dla naszych klientów. A tak na co dzień tworzymy budujemy mvp oraz tworzymy platformę b2b.
|
|
|
26.05.2007, 09:52:22
Post
#7
|
|
Grupa: Zarejestrowani Postów: 118 Pomógł: 3 Dołączył: 6.07.2006 Skąd: Dublin Ostrzeżenie: (0%) |
Kod odbierajacy i filtrujacy dane z POST/GET (i wszelkie dane pochodzace od użytkownika) powinien znajdować się w metodach kontrolera, bardzo esencjonalnie zasady konstrukcji wzorca MVC podał ActivePlayer.
Polecam lekture dokumentacji Zend Framefork-a - kopalnia wiedzy o wzorcach i OOP. Źle natomiast zrozumiałeś zastosowanie metod statycznych. Nie ma powodu by Twoja metoda _set() była statyczna. Jej statyczne wykorzystanie i tak nie będzie mozliwe bo odnosi się do pól obiektu. Metody statyczne wywolywane są bez tworzenia obiektu, nie mogą więc odwolywać się do jego pól. Opisując Ci sposób tworzenia metody statycznej chcialem powiedzieć że statyczne wywolanie self::setView(); było niepotrzebne i gdyby setView() odnosiło się do pól klasy jej działanie okazać by się moglo inne niż oczekiwane. W tym konkretnym przypadku zamiast powinno być to wszystko. Konstrukcja:
Nie bedzie mogla być wywolywana statycznie, poza tym jest to bezzasadne. -------------------- -----------------------
My hovercraft is full of eels! |
|
|
26.05.2007, 10:46:39
Post
#8
|
|
Grupa: Zarejestrowani Postów: 1 597 Pomógł: 30 Dołączył: 19.02.2003 Skąd: Tychy Ostrzeżenie: (0%) |
Proponowałbym wprowadzić dwie klasy - Request (przechowuje zmienne get / post ) i Response (odpowiedzialna za wyświetlanie). W mojavi3 bodajże tak jest
U mnie kontroler jest jeden i to on uruchamia zależnie od $Response->action odpowiednią akcję Jest także odpowiedzialny za obsługę łańcucha akcji oraz autoryzację (niektórzy ten element wyodrębniają z frameworka, ale wydaje mi się, że niepotrzebnie). Ten post edytował sf 26.05.2007, 10:50:33 -------------------- Zapraszam na mój php blog, tworzenie stron.
|
|
|
26.05.2007, 11:12:48
Post
#9
|
|
Grupa: Moderatorzy Postów: 4 465 Pomógł: 137 Dołączył: 26.03.2004 Skąd: Gorzów Wlkp. |
Cytat Rozumiem jak działają łańcuchy akcji ale nie potrafię ich zaimplementować, napisać (np. jak przechodzić z akcji do akcji i w jakiej postaci zwracane sa ewentualne wyniki (błędy) wykonanej akcji ?). @jastu Co do zwracania błędów, to można się długo spierać. Ja rozwiązałem to poprzez zgłoszenie stanu aplikacji, co podpatrzyłem w książce (ok, error, jakiTylkoSobieWymyslisz). Łańcuchy akcji z kolei mi sie udało zaimplementować. Zapraszam do obejrzenia małej demonstracji (sorry za kiepską jakość, ale komp strasznie zwalniał przy nagrywaniu : ) @sf - Widzę, że mamy podobnie : > żądanie -> rozwiązanie żądania (tworzy początkowy łańcuch akcji) -> wykonanie żądania (wywoływanie w pętli akcji i ewentualna modyfikacja łańcucha akcji) -> zebranie danych do wyświetlenia -> Output (rózne np, XML, HTML) i jeszcze filmik, który niektórzy już widzieli Filmik prezentuje między innymi jeden ze sposobów obsługi braku parametru żądania (id) i dwie różne reakcje na ten błąd. http://cysiak.freeweb7.com/kvktest3 (plik video w formacie Theora, 2.8 MB) Pozdrawiam. -------------------- To think for yourself you must question authority and
learn how to put yourself in a state of vulnerable, open-mindedness; chaotic, confused, vulnerability, to inform yourself. Think for yourself. Question authority. |
|
|
26.05.2007, 11:26:44
Post
#10
|
|
Grupa: Przyjaciele php.pl Postów: 698 Pomógł: 3 Dołączył: 28.03.2004 Skąd: Wrocław Ostrzeżenie: (0%) |
Cytat Akcja wykonkuje operację na modelu po czym zwraca odpowiedni obiekt widoku. Tak być nie powinno. Akcja nie ma prawa być powiązana w żaden sposób z obiektem widoku. MVC polega na oddzieleniu od siebie tych trzech warstw, więc wprowadzanie zależności pomiędzy modelem a widokiem łamie podstawowe zasady tego wzorca. Zmiana widoku spowoduje katastrofę w klasach akcji... Model powinien zwracać kontener z danymi, który następnie zostanie przekazany do widoku, tak aby nie były tworzone powiązania pomiędzy warstwami. Sam pracuję w tej chwili nad implementacją MVC. Kontroler u mnie integruje całą aplikację, posiada wymienne Dispatchery, które tłumaczą żądanie HTTP na żądanie wykonania łańcucha akcji. Przed wykonaniem łańcucha, żądanie musi przejść przez filtry, w których np. można umieścić autentykację i autoryzację. Następnie kontroler iteruje przez kolekcję obiektów wywołujących akcje (czyli po prostu wykonuje kolejne akcje z łańcucha). W razie zmiany łańcucha, zostaje o tym poinformowany kontroler, który w razie czego wróci na jego początek. Kwestia implementacji obserwatora. Nad widokiem jeszcze myślę, gdzieś to upchnę po łańcuchu akcji... Dane są przesyłane w odpowiednich obiektach pomiędzy akcjami. W obiekcie kontekstu można zapisać informacje dotyczące całego żądania, czyli stan sesji itp... -------------------- |
|
|
26.05.2007, 12:11:59
Post
#11
|
|
Grupa: Zarejestrowani Postów: 382 Pomógł: 0 Dołączył: 29.11.2005 Skąd: :jestem(); Ostrzeżenie: (0%) |
Cytat Zmiana widoku spowoduje katastrofę w klasach akcji... Czy możesz dokładniej opisać ? Normalnie (chyba wg wzorca) to controller odpowiada za zarządzanie akcjami(łańcuchami) i w zależnosci od wyniku uruchamia widok ... u mnie jeden dla całej aplikacji controller(sprawdza ządanie) wywołuje jedną dla każdego żadania akcję i dopiero ona w zależności od wyniki operacji na modelu określa widok - ale widok uruchamia controller. W ten sposób tworzenia aplikacji ogranicza się do przygotowania szablonów widoku i pisania akcji. Powyższy opis sprawdza się przy aplikacjach o małym zróżnicowaniu uprawnień. Obecnie korzystając z tego modelu budowy do modelu trzeba wysyłać uprawnienia bierzącego użytkownika ( ). Przeczytałem kilka wątków o uprawnieniach użytkowników ale czytam chyba ze zbyt małym zrozumieniem - jak w MVC zarządzac uprawnieniami - musiałyby być przekazywane do Controllera ? do Widoku ? skąd ma obiekt widoku wiedzieć czy dany przycisk ma być wyświtelony czy nie ? -------------------- Powyższy post wyraża jedynie opinię autora w dniu dzisiejszym. Nie może on służyć przeciwko niemu w dniu jutrzejszym. Ponadto autor zastrzega sobie prawo zmiany poglądów, bez podawania przyczyny.
|
|
|
26.05.2007, 12:31:52
Post
#12
|
|
Grupa: Moderatorzy Postów: 4 465 Pomógł: 137 Dołączył: 26.03.2004 Skąd: Gorzów Wlkp. |
Obiekt widoku nie powinien nic wiedzieć o logice systemu. Jeśli chcesz wyświetlać coś, co jest zmienne, to możesz przesłać informacje z kontrolera do widoku w postaci jakiejś zmiennej i potem:
-------------------- To think for yourself you must question authority and
learn how to put yourself in a state of vulnerable, open-mindedness; chaotic, confused, vulnerability, to inform yourself. Think for yourself. Question authority. |
|
|
26.05.2007, 12:50:56
Post
#13
|
|
Grupa: Zarejestrowani Postów: 382 Pomógł: 0 Dołączył: 29.11.2005 Skąd: :jestem(); Ostrzeżenie: (0%) |
Skoro widok ma nic nie wiedzieć o logice systemu a ma otrzymać tylko dane modelu to znaczy że uprawnienia muszą wędrować do akcji lub controllera (albo do obu)...bo rozumiem że model nie interesuje się uprawnieniami - jest to logiczne jeśli chodzi o operację na modelu i akcje ... W tej sytuacji skomplikowanie obsługi żadania z uwzględnieniem uprawnień jest wysokie i uzasadnia to tworzenie oddzielnego controllera dla kazdego wywołania strony...tylko gdzie podejmuje się decyzję o uprawnieniach użytkownika dla elementu strony www.
Próbujemy - jeśli ze strony www którą tworzymy da się wyodrębnić elementy które decydują o nawigacji (np.menu bądz jakiś panel przycisków) i stworzyć z nich obiekty należące do obiektu widoku oraz przekazać im informację o uprawnieniach to...? Piszę o uprawnieniach bo męczy mnie pisanie oddzelnych panelów administracyjnych...przeglądam stronę i jest coś nie tak to klikam i poprawiam bez dodatkowego logowania i podobnych. Pozdrawiam -------------------- Powyższy post wyraża jedynie opinię autora w dniu dzisiejszym. Nie może on służyć przeciwko niemu w dniu jutrzejszym. Ponadto autor zastrzega sobie prawo zmiany poglądów, bez podawania przyczyny.
|
|
|
26.05.2007, 12:54:52
Post
#14
|
|
Grupa: Przyjaciele php.pl Postów: 698 Pomógł: 3 Dołączył: 28.03.2004 Skąd: Wrocław Ostrzeżenie: (0%) |
Dobrym rozwiązaniem jest wzorzec View Helper.
Chodziło mi o to, że akcje mają operować na danych i co najwyżej je zwracać. Komunikacją pomiędzy widokiem a modelem ma się zająć kontroler. Tak czy inaczej model nie ma prawa nic wiedzieć o widoku, ma tylko zrobić to, o co go proszono (operacje na danych). Wybieraniem widoku powinien zajmować się kontroler... -------------------- |
|
|
26.05.2007, 14:10:27
Post
#15
|
|
Grupa: Moderatorzy Postów: 4 465 Pomógł: 137 Dołączył: 26.03.2004 Skąd: Gorzów Wlkp. |
Może ustalimy jakieś słownictwo? Każdy tu używa innych definicji i stąd większość problemów.
Implementacji MVC i innych wzorców jest wiele - wiele z nich również inaczej definiuje pojęcia. Moja propozycja jest następująca: Model (nie mylić z modelem dziedziny (domain model)) Pozyskiwanie danych z bazy danych lub innych źródeł - udostępnia zwarty interfejs dostępu do danych. Wykonuje wszystkie operacje za tzw. zamkniętymi drzwiami. Controller Z premedytacją nie definiuję tu Front Controllera i Application Controllera, bo ich implementacje najczęściej są łączone i z biegiem czasu wychodzą poza definicje tych wzorców. Tu definicje będą dwie: a ) Controller jako klasa zawierająca akcje Najczęściej spotykana odmiana implementowana przez np, CakePHP. W jego ramach definiujemy metody naszej aplikacji. Jest on częścią logiki aplikacji b ) Controller jako obiekt sterujący akcjami Nie zawiera żadnych metod odpowiedzialnych za logikę aplikacji, a jedynie steruje obiektami (np. polecenia/akcji) i reaguje na wyniki ich działania. Widok Tu jest wiele niedomówień a ) Widok jako obiekt systemu (Output) Część systemu odpowiedzialna za renderowanie (tu strony www). Odwołuje się do danych (udostępnionych przez kontroler, bądź model, co zależy od implementacji). b ) Widok jako szablon W praktyce plik, który jest wypełniany danymi przez aplikację (php, smarty, opt, i inne) Można podzielić na: - pasywny - przyjmuje dane, ale nie odwołuje się do metod kontrolera, czy modelu, czy innych obiektów obecnych w systemie. Operuje tylko na danych, które otrzyma. - aktywny - to samom co wyżej, ale może się odwołać do innych obiektów systemu Akcja Tu również definicje mogą być różne, choć wszystkie dotyczą logiki aplikacji a ) Akcja rozumiana jako obiekt polecenia Wykonuje działanie (np. modyfikuje pobrane z modelu dane) i jest w jakiś sposób sprzężona z kontrolerem b ) Akcja rozumiana jako część kontrolera Jest metodą w ramach klasy kontrolera c ) Akcja rozumiana jako użytkownik kodu Wykorzystuje zarówno kontroler, model jak i inne klasy/obiekty w systemie. Sami widzicie, ile może być różnych znaczeń słowa kontroler. Większość z Nas używa różnych kombinacji, co prowadzi do nie zrozumienia. Jeśli ktoś widzi inne możliwe definicje, to niech się podzieli. Zapewne można jeszcze parę znaleźć - można by stworzyć osobny topik : ) Pozdrawiam. -------------------- To think for yourself you must question authority and
learn how to put yourself in a state of vulnerable, open-mindedness; chaotic, confused, vulnerability, to inform yourself. Think for yourself. Question authority. |
|
|
26.05.2007, 15:33:58
Post
#16
|
|
Grupa: Przyjaciele php.pl Postów: 698 Pomógł: 3 Dołączył: 28.03.2004 Skąd: Wrocław Ostrzeżenie: (0%) |
Mi się wydaje, że MVC to nieco wyższy stopień abstrakcji niż klasy, obiekty itp... Dlatego nie powinniśmy rozmawiać o klasach, tylko o tym, czego te warstwy dotyczą.
Model, czyli warstwa biznesowa, to po prostu wszelkie operacje na danych. Widok, czyli warstwa prezentacji. Prościej mówiąc warstwa odpowiedzialna za interakcję użytkownika z aplikacją. Widok nie może być jednym obiektem, gdyż do widoku zaliczamy wszelkie żądania, odpowiedzi. Tego w jeden obiekt nie można zamknąć, głównie z powodu podstawowych zasad OOP. Kontroler, to warstwa, która pośredniczy pomiędzy dwiema poprzednimi. Odbiera żądania, rozdziela zadania, współuczestniczy przy transferze danych pomiędzy warstwami modelu i widoku. Nie ma tu znaczenia, czy rozmawiamy o Front Controllerze czy Application Controllerze. Akcja to po prostu jakieś działanie na danych. Akcje oczywiście, można pozamykać w obiekty, ale tak czy inaczej akcja jest raczej ogólniejszym pojęciem. Wzorce projektowe są narzędziem nie są związanym z warstwą implementacji. Dlatego np. programiści PHP korzystają z katalogu wzorców J2EE. Każdy implementuje wzorce na swój sposób. Inny nie znaczy zły... Natomiast w rozmowie o wzorcach, rozmawiamy o architekturze, a nie implementacji. -------------------- |
|
|
26.05.2007, 16:05:21
Post
#17
|
|
Grupa: Moderatorzy Postów: 4 465 Pomógł: 137 Dołączył: 26.03.2004 Skąd: Gorzów Wlkp. |
Cytat Model, czyli warstwa biznesowa, to po prostu wszelkie operacje na danych i za chwilę Cytat Akcja to po prostu jakieś działanie na danych. Akcje oczywiście, można pozamykać w obiekty, ale tak czy inaczej akcja jest raczej ogólniejszym pojęciem. Mógłbyś to sprecyzować? Jakie działania wykonuje tu model? Model zawiera akcje, czy odwrotnie? Zgadzam się, że MVC dotyczy warstw aplikacji, nie klas (nazwałem widok obiektem - powinienem warstwą). Wszystko rozbija sie jednak o implementację. Mówisz, że warstwa kontroli pośredniczy pomiędzy modelem, a widokiem. Mi się wydaje, że jej działanie może być nieco szersze. Może kontrolować sposób wyświetlania (np. może decydować o wyświetlaniu dokumentu w formie zwykłego XML, wysłać do przeglądarki stronę www, a nawet wysłać "goły" tekst - decyduje o tym żądanie, a nie model, czy widok). Właśnie te różnice utrudniają komunikację, bo to, co dla Ciebie należy do warstwy modelu, u mnie robi akcja. To, co dla Ciebie już jest widokiem, dla mnie może jeszcze być logiką. Trudno więc rozmawiać o MVC bez podparcia się konkretną implementacją, bo jest to zbyt szerokie pojęcie. Osobiście jako model mogę potraktować klasę:
U Ciebie zapewne wygląda to inaczej i inne partie sytemu odpowiadaja za wykonanie tego żądania url, który podałem jest rozpracowywany przez obiekty wchodzące w skład kontrolera, u Ciebie może to robić obiekt wogóle nie związany w kontrolerem. Jednak jedno i drugie będzie dalej MVC Pozdrawiam. -------------------- To think for yourself you must question authority and
learn how to put yourself in a state of vulnerable, open-mindedness; chaotic, confused, vulnerability, to inform yourself. Think for yourself. Question authority. |
|
|
26.05.2007, 16:30:45
Post
#18
|
|
Grupa: Przyjaciele php.pl Postów: 698 Pomógł: 3 Dołączył: 28.03.2004 Skąd: Wrocław Ostrzeżenie: (0%) |
Tak jak pisałem, model to dane i operacje na nich. Skoro akcje zawierają operacje na danych, to zawierają się w modelu. Model jako obiekt nie powinien według mnie istnieć. Po prostu nie lubię pojęcia model, bo do niego zalicza się wszystko... Weźmy za przykład sklep internetowy.
Do modelu zaliczymy dane dotyczące produktów, działów, klienta oraz wszystkie operacje związane z nimi. Jeżeli klient kupuje książkę, to do modelu musimy wliczyć wszystkie operacje dotyczące produktu, zamówienia i użytkownika. Akcje odpowiadałyby za kolejne zadania: utworzenie zamówienia, związania zamówienia z użytkownikiem, dopisania produktu do list itd... Cytat Może kontrolować sposób wyświetlania (np. może decydować o wyświetlaniu dokumentu w formie zwykłego XML, wysłać do przeglądarki stronę www, a nawet wysłać "goły" tekst - decyduje o tym żądanie, a nie model, czy widok). Żądanie jest elementem widoku, bo widok jest warstwą prezentacji. Z kolei warstwa prezentacji odpowiada za interakcję z użytkownikiem, a jest nią bez wątpienia wysłanie żądania w dowolnej formie. W aplikacjach okienkowych żądaniem jest np. naciśnięcie przycisku. W aplikacjach sieciowych tę rolę pełnią żądania, w szczególności HTTP. Racja leży po środku, bo obie warstwy są w to zaangażowane. Tak czy inaczej, wszystkie te działania prowadzą do ustanowienia komunikacji pomiędzy modelem a widokiem. Wszystko w końcu musi się trzymać kupy... Na schemacie widać to doskonale: http://java.sun.com/blueprints/patterns/im...ure-generic.gif -------------------- |
|
|
26.05.2007, 18:44:26
Post
#19
|
|
Grupa: Zarejestrowani Postów: 278 Pomógł: 10 Dołączył: 13.02.2007 Skąd: Rybnik Ostrzeżenie: (0%) |
Wybaczcie, ale z tego co widzę to MVC to jedno wielkie nieporozumienie, każdy go pisze inaczej i według innego jest to źle No sory, ale poczytajcie se wszystkie posty;D
Mógłby w takim razie ktoś napisać jakiś prosty przykład z wykorzystaniem Controllera, Modelu i Widoku wraz z połaczeniem tego? Bo ja już teraz nic z tego nie wiem, jedyne co wiem to do czego to wszystko służy, lecz niestety każdy mówi, że w "tym czymś" ma być coś innego W takim razie proszę o przedstawienie waszych praktycznych przykładów z życia programisty korzystającego z MVC Pozdro -edit- Btw. Który z tych dwóch: Controller czy Model powinien łączyć się do mysql. Chodzi o mysql_connect / mysql_close(nie mówię o mysql_query, itp) ? Ten post edytował matix 26.05.2007, 18:55:15 -------------------- Nawet, jeżeli nie jesteś zainteresowany usługami IT ani outsourcingiem, a Twoją pasją jest programowanie - zobacz naszą stronę. Piszemy dużo fajnych use-caseów, jak podchodzimy do tematu programowania dla naszych klientów. A tak na co dzień tworzymy budujemy mvp oraz tworzymy platformę b2b.
|
|
|
26.05.2007, 19:31:23
Post
#20
|
|
Grupa: Moderatorzy Postów: 4 465 Pomógł: 137 Dołączył: 26.03.2004 Skąd: Gorzów Wlkp. |
Przykład dotyczy wyświetlenia wartości wpisanej w pole formularza.
jest on bardzo prosty, a mój framework wymaga nieco nakładów pracy przy tworzeniu aplikacji, więc proste przykłady wyglądają dziwacznie. plik index.php, czyli akcja index unit oznacza nazwę modułu (mam tak, bo nie ma namespaces w php - jak będzie php6, to zmienie)
plik actions.xml zawierający informacje dla kontrolera dotyczące akcji i tego, jak ma reagować na różne zgłoszone przez nią stany
Teraz warstwa prezentacji plik index.slot.php - sloty to miejsca, przez które pliki szablonów są wstawiane na stronę www
plik pokaz.tpl plik error.tpl - zostanie wyświetlony, gdy nie przesłano danych
---edit Zobacz, że klasa akcji jest maksymalnie izolowana od warstwy prezentacji - nie wybiera sama pliku, który ma zostać wyświetlony - zgłasza tylko stan, a resztą zajmuje się jądro systemu. Podobnie działają przekierowania. Ba! można w ten sposób nawet wyrzucić wyjątek. Ten przykład nie zawiera manipulacji danymi, ale jeśli takie są konieczne, to robi się to właśnie w ciele akcji lub wydziela się następną akcję, która to robi (to już bardziej zaawansowana zabawa) Ten post edytował Cysiaczek 26.05.2007, 19:44:27 -------------------- To think for yourself you must question authority and
learn how to put yourself in a state of vulnerable, open-mindedness; chaotic, confused, vulnerability, to inform yourself. Think for yourself. Question authority. |
|
|
Wersja Lo-Fi | Aktualny czas: 23.04.2024 - 23:22 |