Witam,
jako że nie od dziś można zaobserwować rozsiane po blogach i forum (forach?) posty dotyczące MVC czy MVP
proponuję rozmowę na temat wzorców architektonicznych w php.
Wszystkie wzorce mają być w jednym temacie? Jeśli chcesz tylko porównywać MVP i MVC to zaznacz to w temacie.
Temat jest poświęcony wszystkim wzorcom architektonicznym w php.
W tym MVC, MVP, HMVC.
Może i lekko flameogennie, ale...
Żadnego z wymienionych nie da się w sumie zrealizować w PHP. Lekko "ułomne" implementacje (pozbawione części założeń) są możliwe, ale wtedy już o MVC, MVP, MVA, PAC czy "jakie mi się tam inne 3-4 literki na myśl nasuną" nie można mówić (a przynajmniej nie powinno się).
Żaden z tych wzorców nie został stworzony z myślą o środowisku HTTP (a to w nim przecież pracujemy), ani tym bardziej do rozwiązywaniu problemów w nim panujących.
Swoją drogą chętnie zobaczyłbym jakąś sensowną implementację któregokolwiek z nich (a raczej tego "czegoś" co ma się z nich wywodzić) w dowolnym języku "webowym", w jakiejś większej aplikacji.
Podobnie nowszy asp.net nazywa sie jakos asp mvc czy on implementuje "prawdziwy" mvc?
Najlepszym wzorcem jest nieużywanie wzorców dla samego używania. Można nawet powiedzieć, że wzorce to zło. Warto je poznać w celach komunikacyjnych i dla jakiegoś tam poszerzenia horyzontów, ale nic nie zastąpi myślenia. Potem widać takich "ekspertów" z biegunką wzorcową wpychających je wszędzie na siłe i wyzywających ludzi od debili "bo to nie jest prawdziwe MVC".
@Crozin - skoro w php nie da się zaimplementować mvc czy mvp to powiedz mi co implementują obecne fw? Wydawało mi się że wzorzec mvc , potem ktoś mi próbował udowodnić że mvp a teraz ?
+ z jakiego wzorca ty korzystasz ?
a co to jest?
Kontroler steruje aplikacją i wywołuje moduł i dalszą kontrolę przejmuje "subkontroler" (nie wiem jak to nazwać). Subkontroler składa z klocków aplikacje.
Te klocki wyglądają tak:
widok - moduł (który wylicza) i warstwa danych (w zależności z czego ma brać dane: plik, baza, czy co innego).
widok jest wysyłany do składaka (nazwałem to tak bo składa do kupy warstwe wyglądu) i wyświetla całość na ekranie...
jak to nazwać? takie misz-masz?
efekt działania jest normalny - jak w przypadku waszych magicznych cudów niewidów...
@sniver to o czym mowisz to "hmvp/hmvc" dalem w cudzyslowia zeby nie bylo, ale ich idea opiera sie wlasnie na modularnosci.
Kazdy modul ma swoj/e widoki i modele i kontroler.
@Crozin nie bardzo się mogę z Tobą zgodzić.
Również mnie irytuje fakt gdy np. ajaxa nazywa się językiem programowania etc, ale mówienie o tym że MVC/MVP nie zostały stworzone z myślą o HTTP i dlatego żaden język webowy nie może implementować MVC/MVP wprost jest bzdurą.
Jak doskonale wiesz wzorce projektowe są uniwersalnymi rozwiązaniami pojawiających się problemów. Wzorce projektowe są tylko wytycznymi jak coś robić żeby było dobrze i spójnie - jeżeli zrobisz inaczej wiadomo że mijasz się z definicją danego wzorca (modyfikujesz go). Ale jeżeli postępujesz (kodujesz) zgodnie z założeniami danego wzorca to nada go używasz - nie ważne czy używasz php, jsp czy innego języka webowego. To tak jakbyś powiedział że nie można implementować Singletona do php bo mamy klonowanie.
Z praktycznego punktu widzenia programowania webowego i używania fw który opiera się na architekturze MVC - programujemy używając wzorca MVC!
Natomiast z punktu widzenia odbiorcy/usera masz rację że w grę wchodzi protokół HTTP i dochodzi kolejna warstwa jaką jest browser:
Na koniec powiem, że jeżeli udało się zaimplementować wzorce projektowe z architektury do informatyki, to dlaczego niby miałoby się nie dać zaimplementować MVC do języków webowych?
Przypominasz zatwardziałego JAVA'owca który krzyczy "OMG, OMG on pisze w językach skryptowych - on nie jest programistą bo nie kompiluje" ...
Pozdrawiam
...
@FanFataL: Łady rysunek, ale brakuje mi w nim jednego - gdzie są strzałeczki pomiędzy Widokiem, a Modelem? - bo to one są w sumie najważniejsze. I dlaczego dane płyną przez kontroler, skoro Widok powinien sam odpytać Model, odpowiednio go do tego przygotowując wcześniej?
O ile jeszcze mogę zrozumieć brak strzałeczki z Modelu do Widoku (bo środowisko webowe uniemożliwia istnienie takiej), o tyle brak strzałeczki z Widoku do Modelu i podpis "Resulting Data Arrays" z Modelu do Kontrolera (gwoli ścisłości: Model może zwracać do Kontrolera jakieś dane, ale nie w celu przekazania ich przez ostatniego do Widoku) to zaprzeczenie idei tego wzorca.
Schemat, który pokazałeś to model wykorzystywany w większości FW. I dobrze! On jest całkiem dobry, sam pracując w PHP z reguły z czegoś takiego korzystam. Ma nawet swoje zalety względem MVC. Ale... on nie ma wiele wspólnego z MVC samym w sobie. Istnieje trójpodział aplikacji, ale działa on inaczej niż w przypadku tego cholernego MVC. Co więcej taki schemat z reguły oznacza, że Kontroler wykonuje większość logiki, która powinna spocząć na Widoku, a ten ostatni jest ograniczany do szablonów HTML/PDF/innych.
Co do schematu od FanFataL to rzeczywiście razi brak model<->vidok.
Bark kontaktu vidoku z modelem wykorzystuje mvp z tego co pamiętam.
ajax, ajaksem...z definicji jest to połączenie aplikacji z serwerem i przeładowanie części strony bez konieczności ponownego odświerzania. Odbywa się to za pośrednictwem javascript i xml...
no i dobra tyle wiemy, a ja i tak wole format json, a nie xml. No i mniej z nim problemu
No i jest implementowany przez jquery...
A najlepsze jest to że każdy piszę że to technologia (wrrr..) jak by to było niewiadome co..a przecież to tylko dodatkowy bajer w java script...
Swoją drogą widzę że w wiki też pisze że to technologia - więc może zmienię zdanie
Co do tych wszystkich wzorców - rozumiem gdy ma to na celu usystematyzowanie i stworzenie wszędzie "takiego samego kodu". Wiele z firm dlatego wykorzystuje ZF, Kohane czy inny fw. Czy jest to warunek konieczny? Według mnie nie - bo i tak efektem działania tego całego zamieszania jest..uwaga: zwykła strona www! A klient czy który odwiedza strone i tak nie wie czy to MVC zaimplementowane w PHP, JSP czy innym języku...
Co do tego obrazka @FanFataL przypomina mi się full-ajax'owa aplikacja. Widok odwołuje się do różnych części aplikacji i uzupełnia stronę - ja to tak rozumiem...
@FanFataL: Co to znaczy EOT?
I tak dla każdego Modelu, to nie... wszystkie kontrolery/szablony muszą być generowane. ListView, FilteredListView, FormView, DetailView - trzy widoki wystarczyłyby do wyświetlania właściwie wszystkiego. Później kontrolery ograniczają się do wybrania odpowiedniego modelu (np. aktualności, posty etc.).
public function listAction() { return new ListView(new NewsModel()); }
@sniver http://pl.wiktionary.org/wiki/EOT
Co do tematu to tez zgadzam sie z tym ze jesli dana aplikacja jest zaprojektowana w sposob gdzie widok = szablon to jest blad bardzo to ogranicza i do tego powoduje ze nawet nie mozna zaimplementowac "mvc"
@Crozin symfony jednak ma widok w Twoim rozumieniu, zresztą podobnie jak Agavi (tutaj jest to jeszcze lepiej zorganizowane). To, że nie zostało to wykorzystane do AG to się zgadzam i żałuję.
Kilka tygodni temu jako podsumowanie tej dyskusji postanowiłem zebrać wiadomości nt MVC do kupy w postaci artykułu Wikipedii z odpowiednimi przypisami.
http://pl.wikipedia.org/wiki/Model-View-Controller
Artykuł jest nieźle uźródłowiony i podaje definicję tego wzorca zgodnie z pierwszą pracą go opisującą datowaną na 1979 rok, a także późniejszymi klasykami takimi, jak "Wzorce projektowe: Elementy oprogramowania obiektowego wielokrotnego użytku". Dodatkowo znalazłem świetny katalog opisujący wzorce architektoniczne rozwijany przez pana Martina Fowlera, gdzie jest sporo na ten temat. Jest też m.in. oryginalna praca wprowadzająca Model-View-Presenter.
Kwestia tego, że oryginalnie wzorzec był zdefiniowany dla aplikacji desktopowych wiele tu nie zmienia, bo są to de facto dalej te same założenia, tylko uwzględniające specyfikę środowiska web i niekolidujące z oryginałem (w sensie: jak robimy aplikację WWW, musimy z konieczności korzystać z wariantów dla aplikacji WWW). Jednak z tych wszystkich materiałów dość jasno wynika, że w świecie frameworków WWW coś takiego, jak MVC zasadniczo nie istnieje. Zawsze są to jakieś pochodne oryginału... tyle że mają one swoje własne nazwy i w żadnym wypadku nie są MVC. Dominują:
- Model-View-Presenter - uproszczenie modelu i widoku na rzecz warstwy prezentera.
- Model-View-Presenter z Pasywnym Widokiem - jw. + zerwanie połączenia między modelem, a widokiem.
Jedna Kohana coś tam niby kombinuje, ale co - nie wiadomo, bo autorzy dalej lecą sobie w kulki z dokumentacją. Ponadto w przypadku hierarchicznych odmian jeszcze się tak do końca nie dokopałem do oryginalnych źródeł.
Dodatkowo, w ramach eksperymentu rozwijam na Githubie framework mający implementować założenia MVC (tego prawdziwego): https://github.com/zyxist/Trinity/tree/lightweight - i generalnie pisze się w nim zupełnie inaczej, niż w popularnych frameworkach, co moim zdaniem dość dobrze świadczy, gdzie są frameworki, a gdzie MVC.
Witam
Jakis czas temu wykonałem framwork którym do tej pory sie posługuje ,jego schemat działania wygląda tak :
http://www.fotosik.pl/pokaz_obrazek/ce6473e3d0258aca.html
ciekaw jestem waszych opini na jego temat .
Pozdrawiam
Cojack... Nie bądźmy złośliwi Czysty MVC jest nie do zaimplementowania w architekturze webowej i każdy rozumiejący ten wzorzec programista jest w pełni tego świadom. Mozna sobie rzeźbić i cuda wymyślać, ale pewnych możliwości MVC w komunikacji webowej nie uzyskasz, bo nie pozwala na to protokół. Bylo to już poruszane wielokrotnie. Zyx na pewnoma ten sam problem i jak mniemam zastosuje jakąś technikę mającą emulować brakujące formy komunikacji pomiędzy warstwami, na które http nie pozwala. Rozumiem, że pewne rzeczy mogą Ci nie pasować, ale moim zdaniem spośród osób tutaj siedzących ma on jedne z największych doświadczeń jeśli chodzi o "bebechy" stojące za tym wszystkim i z racji, tego to co rzeźbi jako autorski framework, może być ciekawe. Na razie się nie zagłębiam w niego, ale gdy wyjdzie jakaś wersja oficjalna, to chętnie przejrzę, bo być może sam coś z jego pomysłów uznam za wartościowe/nowatorskie rozwiązanie. Poza tym czytając to co piszę ja i co pisze on, to trudno nie zauważyć, że akurat oboje uznajemy, iż to co wiele frameworków nazywa MVC, nie jest nim, tylko pewnym wariantem zmodyfikowanym na tyle by był implementowalny dla sieci web. Tak więc jeśli coś ma implementować założenia MVC lepiej, to chętnie zobaczę JAK ma to robić zamiast marudzić
phpowiec84 -> fajne te zaokrąglone ramki. Niezła czcionka przy numerkach. A na serio może byś tak rozwinął trochę tę myśl nieco?
thek no ale tego
Najprawdopodobniej moje rozumienie wzorca MVC jest bardziej zbieżne z tym co podają dokumentacja, książki i Zyx, zamiast tym co próbują frameworki nazwać MVC
Wy nadal to samo...
Pisanie czegokolwiek po to tylko, aby implementowało jakiś wzorzec jest całkowicie sprzeczne z tym, co jest ideą wzorca projektowego, mianowicie dobrego i sprawdzonego sposób rozwiązania problemu. Nazwa jest tylko po to, aby można było łatwiej zapamiętać, zaprezentować i przedyskutować możliwe rozwiązania. Skoro żaden webowy FW nie implementuje prawdziwego wzorca MVC, to należy zadać pytanie, dlaczego tak się dzieje, że setki doskonałych programistów nie widzi zalet takiej idealnej implementacji i jej do tej pory nie zrealizowało w żadnym powszechnym frameworku? Hmm? Ja myślę, że to dlatego, że taka implementacja generuje więcej problemów (przynajmniej w świecie programowanie webowego) niż rozwiązuje.
Jednak sama architektura trójwarstwowa jest w porządku, więc modyfikują MVC w takim stopniu, aby nie stracił nic ze swego ducha i po prostu wdrażają. Potem 100 innych gości wpada na to samo, 50 z nich lubi klasyfikować różne rzeczy, więc dla odróżnienia nazywają to coś wspólne MVP i dzięki temu prowadząc akademickie dyskusje mają uszczegółowioną siatkę pojęć. Pozostałych 50, którzy mają w głębokim poważaniu ten podział, robi w tym czasie narzędzia implementujące ideę podziału na logikę działań, kontrolę pracy i prezentację wyników, w skrócie LCV.
Wracam do pracy.
A prawda jak zwykle pośrodku Cysiaczek ma rację co do niepotrzebnego popadania w szczegóły. W końcu ma to działać, bo to najważniejsze. No i faktycznie pełna implementacja MVC w środowisku webowym jest niemożliwa z racji cudowania między modelem i widokiem, które nie mają możliwości mieć prostego połączenia, bez uciekania się do nowego żądania, które jest kolejnym, głębiej ukrytym MVC. Ale Zyx i wookieb mają racje co do złego nazywania. Niektórzy bratka nazwali by różą bo obie rośliny to kwiaty, więc co to za różnica? Analogicznie twórcy frameworków MVP nazywają je MVC bo to bardziej chwytliwe i znane "słowo-klucz", a mają podział na 3 warstwy odpowiedzialne za określone działania, więc co to za różnica czy ostatnia literka to P czy C? Równie dobrze możesz właścicielowi rodowego psa powiedzieć, że ma kundla On to rozumie zupełnie inaczej niż Ty. Dla niego kundel to mieszaniec, pies bez rodowodu. Dla Ciebie kundel = pies w bardziej negatywnym znaczeniu (może kiedyś zawarczał na Ciebie i go nie lubisz). Dwa różne punkty widzenia na to samo słowo. Kłótnia jakakolwiek nie ma tu sensu. Dla mnie MVC jest w środowisku web nieimplementowalny i tyle. Każdy kto twierdzi inaczej jedynie się zbliża do niego bardziej niż inni i tyle, ale nic więcej. Pewnych barier nie przeskoczy, a to one sprawiają, że MVC jest niemożliwy do uzyskania w czystej postaci.
Z komputerem i prockiem to trochę zły przykład Komputer to w najbardziej pierwotnej wersji architektury (von Neumanna) urządzenie posiadające jednostkę obliczeniową, pamięć i jakąś formę urządzeń I/O. Od biedy wystarczyło by do procka podpiąć jakiś czujnik i by działał w oparciu tylko o swoja pamięć cache z wbudowanym programem. Jak chce, ale działałby
No i właśnie to co ty teraz zrobiłeś jest popadanie w szczegóły przykładu, który nie miał na celu wskazanie dokładnych znaczeń słów "procesor" i "komputer" a jedynie wykazać istotę potrzeby nazywania pewnych rzeczy.
Na temat porównania co rzeczywiście jest procesorem a komputerem z "definicji" można prowadzić ogromny wywód który zrobiłby to samo co Zyx na temat MVC.
P.s. Przypominam post o analizie twej osobowości - punkt o "zmianie tematu"
To co wskazałem to oczywiście przesada jak sam zauważyłeś. Dla większości ludzi komputer to takie pudełko duże lub nieco mniejsze i ma jakieś tam podzespoły. Dla informatyka, a nimi przecież oboje jesteśmy, to pewna "fizyczna implementacja" jakiejś architektury. To samo tyczy także wzorców architektonicznych. Dla ogółu to po prostu taka czarna skrzynka, którą z grubsza rozumieją po swojemu. Nie zawsze w sposób prawidłowy. To potem prowadzi do nieporozumień. Przykłady mamy także na forum tutaj. Ktoś coś chce, nie do końca rozumie czego chce, a używa terminologii w sposób niewłaściwy, co tylko nas wprowadza w błąd. My się wkurzamy, on się wkurza. Ile nieporozumień można by uniknąć gdyby określone zwroty czy frazy były jednoznaczne dla obu stron? A tak mamy galimatias, bo myśli się A, opisuje się to jako B, a inna osoba z tego wszystkiego rozumie C.
Tak więc nie chodzi mi tu o rozmycie tematu, ale ustalenie jednolitej definicji co jest czym. Zauważ, że ludzie mają problem nawet by określić co ma być w której warstwie wzorca MVC. Potem pakują do kontrolera to, co ma być w modelu i robi się syf. Oczywiście nie widzą tego, bo nie rozumieją do końca tego co robią i na czym określony wzorzec polega oraz co wynika z zastosowanych przez nich założeń czy środowiska. Taki się uprze, że to jest MVC i mu nie przegadasz, że się myli. Tylko że właśnie przez takie mylenie pojęć ludzie tylko tracą i czas i nerwy.
Ja osobiście nie lubię marketingowego bełkotu tylko łapie za specyfikację lub dokumentację i tyle. Więcej z niej zrozumiem. I kij z tym, że nieraz zasypie mnie kilkadziesiąt stron czy więcej. Przynajmniej to jest zazwyczaj pisane językiem ustandaryzowanym, a nie bełkotem. Weź sobie głupie kółka z tymi 3 literkami i narysuj możliwe w sieci web połączenia między nimi, a od razu stanie sie jasne, że MVC jest niemożliwy do implementacji. Ja to wiem, Zyx to wie, Ty też to wiesz i Cysiaczek także. Tyle że nie każdy z naszej czwórki przystaje na takie uproszczenia i to jest przyczyną tutejszej niezgodności.
A to co napisałem tyczy nie tylko MVC, ale każdego dowolnego wzorca projektowego. Dopóki nie będzie jednolitego standardu i dopóki ludzie na A będą mówili B to musi taki bajzel być czy to sie nam podoba czy nie. Nie sądzę by był sens ciągnąć dalej wątek co jest a co nie jest MVC bo i tak utkniemy na osobistych preferencjach, a nie rzeczowych argumentach. Dla mnie wykładnikiem są książki i twórcy tego wzorca, a nie jego implementacja przez frameworki i tego pierwszego się będę trzymał, choć ktoś inny da się przekonać i mnie by za takie podejście zjechał. Nie ma naprawdę sensu robić flame'a, bo i tak nas to nigdzie nie zaprowadzi. Jedynie wywoła kolejne akademickie dysputy. Mało ich już jest na innych stronach? Może niech ktośzłapie sie za inny wzorzec i to jego omówimy równie dogłębnie jak MVC? Przynajmniej byłby wtedy jakiś pożytek z tych rozważań na poziomie akademickim. Bo te 3 literki to już chcą mi uchodzić każdym możliwym otworem ciała
Nie miałem zamiaru uderzać w system nazewnictwa. Po prostu uważam, że stawianie sztywnych granic w takiej dziedzinie wiedzy jak wzorce projektowe bywa pozbawione sensu praktycznego i niekiedy jest śmieszne.
Nie chodzi wcale o wyjaśnienie dokładnego działania wzorca na poziomie współpracy jego części, tylko o nadanie sensu, naszkicowanie sposobu w jaki można rozwiązać napotkany problem. To jest podstawowa korzyść wynikająca ze zbierania doświadczeń przez wiele lat. Katalogowanie takich wzorców jest z kolei czynnością, bez której one same nadal pełniłyby swoje funkcje. Im bardziej szczegółowo je katalogujemy ze względu na różne kryteria, tym bardziej rozmywamy ideę. Zgoda, że do typowo "naukowych" rozważań, możemy trzymać się konkretów, ale nie popadajmy w przesadę, bo co jest łatwiej powiedzieć?
- "Architektura trójwarstwowa w rozumieniu takich jakie prezentują MVC i/lub MVP "
czy
- "Takie tam coś jak MVC"
W zwykłej forumowej odpowiedzi na pytanie nowicjusza "Jak ten kod uporządkować?" lepiej powiedzieć "Poczytaj o MVC" lub bardziej ogólnie "o wzorcach" niż "Poczytaj o różnicach między MVC i MVP, bo to niezwykle istotne, bo żaden FW nie implementuje MVC, bo blablabla". Co to obchodzi kogoś, kto szuka ogólnej drogi do rozwiązania ogólnego problemu?
Mała dygresja związana z tym topikiem:
@Cysiaczek: Głupoty piszesz. Mówiąc "MVC" powinno się mieć na myśli konkretną architekturę, ze ściśle określonym sposobem działania i jasno określonymi zależnościami pomiędzy elementami owej architektury. Zmieniając założenia powinniśmy już przestać używać takiej nazwy, bo to jedynie wprowadza w błąd (gdyby od początku nie pisano MVC, MVC, MVC, MVC tylko [tutaj jakaś nazwa dla architektury] nie byłoby żadnego problemu).
MVC nie jest pojęciem dla "przeciętnego turysty", a dla doświadczonego obieżyświata.
To trochę tak jakbyś przyszedł na rajd samochodowy i mówił, że twój samochód z faktycznym napędem na przednie koła ma napęd 4x4 bo przecież cztery koła się kręcą jak jedziesz. Ten pogląd podchwyci grupa ludzi i nagle samochód z toczącymi się czteroma kołami zaczynamy nazywać samochodem z napędem 4x4. I teraz dupa. Bo jak normalni kierowcy mogą mówić o "flakach" swoich samochodów, o tym że jeden ma FWD, drugi RWD a trzeci 4x4, że ten pierwszy powinien wziąć przykład z ostatniego biorąc udział w rajdzie terenowym itd?
@Crozin, Pokaż mi konkretny i absolutnie właściwy sposób interpretacji tego... bo już na pewno nie wzorca wg tego co piszesz.
http://pl.wikipedia.org/wiki/Wzorzec_projektowy_%28architektura%29
Chyba tutaj chciałeś podlinkować: http://pl.wikipedia.org/wiki/Wzorzec_projektowy_(informatyka) oraz chciałeś zapewne zacytować
Link dałem dokładnie taki jaki chciałem.
Tak, masz rację zgadzając się z wikipedią, zgadzam się też z Twoim opisem MVC i nie widzę powodu dla którego trójwarstwowa architektura posiadająca Widok zajmujący się prezentacją danych, Model odpowiedzialny za logikę biznesową oraz Kontroler zajmujący się obsługą żądania. Tu dopiero pojawia się małe rozróżnienie w relacji miedzy warstwami w przypadku MVC i MVP (pomijam ograniczenia protokołu). Otóż zakłada się i to zupełnie niesłusznie, że w obecnych FW webowych nie można pisać inaczej niż zgodnie ze wzorcem MVP. W MVP to kontroler (presenter) ma za zadanie "obrobić" dane dla widoku
np.
public function executeShow() { $this->setVar('name', $request->getParameter('name')); }
public function executeShow() { $this->setVar('MyUserModel', new MyUserModel($request->getParameter('name'))); // widok sobie poużywa tego wg własnego widzimisię }
Czy ja wiem... Jak dla mnie to podane dwa przykłady nie różnią się wiele jeśli chodzi o efekt końcowy. Czemu? Ponieważ i tak najpewniej do widoku trafią te same dane w obu wypadkach gdyby programista trzymał się minimalizmu. Kto pośle do widoku obiekt z 50 zmiennymi, skoro widok wymaga kilku zaledwie? KISS się kłania. W pierwszym wypadku zapewne kontroler gdzieś i tak wywoła model by mu te dane podesłał. Czy będzie taka różnica wielka między wysłaniem żądania danych do modelu by potem te dane (zapewne nawet nie tknięte jakąkolwiek metodą, helperem, whatever) wysłać do widoku (który i tak sobie je zinterpretuje wedle wewnętrznych mechanizmów), a bezpośrednim zestawieniem modelu i widoku? Dla mnie to tylko ciut inny zapis. Różnica w 2, góra 3 linijkach. Ogólnie to co napisałeś to więc nadal nie MVC dla mnie. Gdyby jedynym parametrem było tylko określenie widoku to bym się zgodził. zauważ, że w obu wypadkach i tak nakazujesz by widok skorzystał z określonych danych, tylko raz dajesz mu już konkretne, a w tym drugim mówisz by użył konkretnego modelu. Tak czy inaczej wymuszasz zestawienie tylko że albo pośrednio, albo bezpośrednio.
IMHO MVC ma miejsce gdy kontroler nawet nie musi zestawiać tego połączenia. Kontroler woła po prostu model, który sam decyduje, patrząc na dane, jaki widok wywołać. I vice versa. Kontroler chce dane w określonym widoku, a ten na podstawie owego żądania określa jaki model ma wywołać. Zauważ, że w www jest trudno uzyskać taką autonomię warstw. Trudno bowiem by widok widoczny u usera samodzielnie wywołał model na serwerze bez udziału pośrednika przetwarzającego żądanie. I stąd mamy MVP, czyli to Presenter wie jakie pary modelu i widoku wywołać, by je zestawić. Dzięki temu ten sam element może być wykorzystywany wielokrotnie do różnych celów. Najważniejszy jest tylko "styk" modelu i widoku. Muszą tutaj dane być identyczne zarówno dla strony wysyłającej, jak i odbierającej by zestawienie się powiodło. Jeśli wybiorę widok to musi mi Presenter podesłać dane przez ów widok wymagane. A to, z jakiego modelu, to już mało istotne. Z kolei wybierając model Presenter musi określić w jakiej formie zwrócić. Czy widokiem ma być plik strony www czy może wygenerowany pdf. I właśnie tak działają chyba niemal wszystkie frameworki php. Jawnie zestawiasz te połączenia. To dalekie od autonomii warstw.
IMHO różnica jest dość ostra, w drugim przypadku mamy relację widok-model, w pierwszym jedynie jakąś anonimową daną
Jak dla me różnica jest tylko taka, że w 1 przypadku dostajesz gotowe dane, zaś w 2 obiekt danego modelu. Tak więc to co robi zazwyczaj Presenter scedowałeś na Widok. A mimo to i tak w razie konieczności zmiany widoku lub modelu musiałbyś wrócić do Presentera ponownie by wykonał operację zamiany. Tak więc jedynie moim zdaniem poprzerzucałeś część zadań między warstwami lub prościej pisząc: uprościłeś Presenter za cenę skomplikowania Widoku.
Niektórzy zapomnieli, że w MVC warstwa widoku to nie tylko bezmyślne wyświetlanie danych. Mimo wszystko... kolejny wątek zmienił się w pierdolnik o tym czym MVC jest, a czym nie jest, więc czy jakiś moderator mógłby go wydzielić ten fragment dyskusji do innego wątku?
@Crozin piszesz ze MVC nie jest stworzone do HTTP, to mam rozumiec ze wszelkiego rodzaju serwlety JAVA rowniez go nie moga obslugiwac ? To przeciez tez HTTP
Nie mogę zrozumieć jednej rzeczy... Po co ciągle wykłócacie się o nazewnictwo wzorca projektowego ? Ja wiem że jest to żywa pogadanka na pewien temat, ale chyba założenia tematu są nieco inne. Po to tutaj jesteśmy żeby wymyślić jakieś nowe podejście, nowy obraz na dany temat ( np. jak to robi ZyX ). Także jeśli mogę prosić, od tej pory opierajmy się tylko na konkretach, z których coś wyniknie. Za to wielkie dzięki!
dyskusja umarla smiercia naturalna....
A jakby tak spojrzeć na to z innej strony. Czy jest wzorzec, który powstał z myślą tylko i wyłącznie o środowisku HTTP? Jeżeli nie, to warto taki opracować. Może na razie jest to gdybanie, ale warto spróbować. Nowatorski wzorzec biorący pod aspekty wszystkie cechy webowych aplikacji. Bez podciągania pod MVC, MVP, HMVC i inne...
Co wy na to?
Dorzucę swoje trzy grosze.
Ciekawym jest fakt, że "twórcy" wzorców, a przynajmniej główni propagatorzy czyli banda czworga w swojej książce katalogu wzorców traktują MVC jako złożenie wzorców i w ogóle go nie ma w tym katalogu jako wzorzec. Co ciekawe na początku książki opisują jednak MVC oraz z czego się składa i jakich wzorców używa.
Także z jednej strony mamy wzorzec złożony MVC który korzysta z innych wzorców, a z drugiej wzorzec MVC który sam w sobie jest czystym wzorcem ?
Ja byłbym skłonny uznać MVC bardziej za koncepcję aniżeli osobny wzorzec. Jeśli uznamy MVC za koncepcję wszelka dyskusja nt. nazewnictwa hMVC, sMVP jest bezużyteczna, bo to jedynie kolejne koncepcje wykorzystania wzorców czy mechanizmów logicznych wędrówki danych.
A co jeśli ja przedstawię taką implementację koncepcji (!) MVC:
M - model obsługiwany przez C++ i OracleDB
C - obsługiwany przez PHP
V - widok obsługiwany przez Javascript i HTML (przeglądarka www w komputerze stacjonarnym, telefonie, telebimie)
Komunikacja między trzema warstwami logicznymi odbywa się poprzez SOAP. Czym będzie taka implementacja rozdziału logicznego aplikacji ? Będę mógł powiedzieć: mój program został napisany przy użyciu MVC ?
@LSM: To co pokazałeś to jedynie podział aplikacji na różne warstwy (chociaż akurat V to powinno być coś co generuje HTML / JS, a nie przeglądarka). MVC i cała reszta natomiast konkretnie określają sposób w jaki tych kilka warstw współpracuje ze sobą. I robią to dosyć precyzyjnie. Tak więc jeżeli w Twojej aplikacji poszczególne warstwy współgrają ze sobą zgodnie z definicją tego cholernego MVC, wtedy możesz z czystym sumieniem powiedzieć, że implementują ten wzorzec.
Widok opisuje, jak wyświetlić pewną część modelu w ramach interfejsu użytkownika. Ale nie mówi nam jak mamy to robić. Na tym polega wzorzec że nie jest sprecyzowany. Jak na niego patrzymy to widzimy trzy kulki ze strzałkami - reszta należy do naszej wyobraźni.
Ok nazwę swój wzorzec: ProtocolBased MVC, albo nie, SOAP-fucking-brutal-MVC, Jahuuu ! ;-)
Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)