Pytanie proste jak budowa cepa i mam nadzieje ze odpowiedzi tez takie beda, bez owijania w bawelne.

A wiec dlaczego wedlug was wzorzec MVC jest bardziej "slyszny" niz HMVC jakie sa przewagi jednego nad drugim i jakie sa minusy...?

P.S interesuja mnie tylko sensowne odp na polskich forach o tym jest malo, a z tego co widze dalej wiekszosc "publicznych" fw korzysta z MVC oprocz Kohany 3, i moze jakiegos jeszcze...?

P.S2 a moze jakies inne ciekawe wzorce zwiazane z projektowaniem stron...?

~Zyx lubi pisać na takie tematy, odsyłam:
http://www.zyxist.com/pokaz.php/poeksperymentujmy_z_mvc
http://www.zyxist.com/pokaz.php/rozwazania_o_wzorcu_mvc

Nie ma czegos takiego ze wzorzec jest bardziej sluszny. Wybor wzorca podobnie jak i kwestia jego implementacji jest sprawa inwidualna.

Moze bardziej wybor zalezy od sytuacji, w tym przypadku jednak wzorce sluza do tego samego tylko ze maja male roznice jeden wprowadza nowosci w porownaniu do drugiego w tym tkwi roznica.

Nie chodzi o ktory jest bardziej sluszny chodzi mi o pro i contro dlaczego ktos z was wybralby MVC/HMVC lub potoczne MVP z kazdego php'owego fw

Zajrzyj do wiki (raczej angielskiej bo stoi jednak na wyższym poziomie), przeczytaj o każdym z tych wzorców, bo każdy z nich ma inne założenia a co za tym idzie wymusza inną implementację.

To są dwa różne wzorce z pewnymi wspólnymi elementami i służą do rozwiązywania różnych problemów.W takimi razie odsyłam do wiki - żaden z popularnych FW PHP nie implementuje MVC.

Żadnego z tych wzorców ((H)MVC, (H)MVP) nie da się zaimplementować w PHP z racji środowiska w jakim ten pracuje. To powinno już dawno skończyć dyskusję n/t ich implementacji, która jest po prostu nie możliwa.

PS. MVC i resztę można by zaimplementować wykorzystując WebSockets czy nawet starego, dobrego AJAXa - jednak taka implementacja byłaby dostępna jedynie dla "aplikacji internetowych", nie zwykłych stron, gdzie trzeba uwzględnić brak obecności JS.

Nie wiem czy te wzorce służą do rozwiązywania różnych problemów, ale jeśli dzięki nim możesz rozdzielić prezentację strony od jej logiki to jestem za Dodaj do tego możliwość ponownego wykorzystania kodu (z kontrolera) i czego chcieć więcej? IMHO wszystko się kreci wokół DRY, KISS i zachowaniu dużej ortagonalności kodu (luźne powiązania, wysoka spójność).


* programowanie komponentowe, np. Wicket http://en.wikipedia.org/wiki/Apache_Wicket
* view first z Lift'a http://wiki.liftweb.net/index.php?title=Lift_View_First

U mnie MVC pojawił się naturalnie wraz z rozwojem moich umiejętności programistycznych, po prostu w pewnym momencie zacząłem rozdzielać pewne elementy programu od siebie, potem przeglądając źródła innych FW PHP, trafiłem na ich rozwiązania MVC i w ten sposób skończyłem z praktycznie identycznym rozwiązaniem jak w Kohanie. A czy jest to idealne MVC, czy MVP, czy model powinien być przekazywany do widoku, czy tylko dane z modelu, to dla mnie przynajmniej, ma drugorzędne znaczenie. I w tej kwestii mam to samo zdanie co @NuLL.
W twoim przypadku polecam wypróbowanie obu metod i samemu ocenić co dla Ciebie jest bardzie naturalne i w czym wygodniej ci się pracuje. Nawet całkiem prosto można to zrobić właśnie w Kohanie przy użyciu wersji 2.4 i 3.

@kbsucha: OK, możesz tak robić, ale nie nazywaj tego MVC, bo to tym nie jest. Nawet jeżeli już skręcisz w dobrym kierunku, tj. do widoku przekazujesz model to nie znaczy, że masz MVC - nadal brakuje Ci dwóch podstawowych elementów tego wzorca - komunikacji widok->model i model->widok. To pierwsze jest bardzo ograniczone (bo masz tylko jedną możliwość nawiązania takiej komunikacji), to drugie w ogóle nie istnieje. Mowa tutaj oczywiście o PHP działającym w środowisku serwera HTTP.

Pewne elementy tych wzorców da się zaimplementować na potrzeby strony internetowej - ale one nie były tworzone z myślą o takim zastosowaniu.

PS. MVC to nie jest wcale jakieś "najlepsze rozwiązanie" - to tylko jedno z wielu. I każde ma swoje plusy i minusy.

Okresl jaki ROZNYCH problemow, jesli mozesz.

Wiem, wiem zagalopowalem sie mialo byc MVP

DLa tego mowimy o implementacji jaka da sie zrobic w srodowisku HTTP ;]

@Theqos na pewno sprawdze ;-)
@kbsucha ja wiem jak dzialaja, jak je uzywac, po co i dlaczego nie w tym sek.

Jako że jak zwykle przy temacie MVx pojawia się dyskusja o x pozwolę sobie wrócić do meritum sprawy.

HMxC nadaje się do budowania modularnych aplikacji i jest rozszerzeniem MxC. Trudno jest tutaj mówić o plusach i minusach, bo jak wspomniałem jedno jest dzieckiem drugiego. Korzystasz z którego jest ci lepiej w danej sytuacji.

~Crozin: Dlaczego widok nie może aktualizować modelu? Według mnie raczej to jest kwestia braku potrzeby takiej aktualizacji.

edit>
Literki mi się przestawiły zamiast MxV było MVx

Czemu MVP ?
Z wikipedi:


A jak my mamy w fw bajery typu

[PHP] pobierz, plaintext 
//view.phtml
<h1>view</h1>
<?php
$anyArray=model_form::cos();
$form->open('/any.php');
$form->create($anyArray);
$form->close('ok');
?>
<p>copy by foo</p>
[PHP] pobierz, plaintext 

To co? Mamy MVP z widokiem który ma dostęp do modeli ? Czy MVC ?

Ok nie zwracajmy uwagi poki co czy to jest HMVP/MVP czy HMVC/MVC lecz poki co skupmy sie na roznicy pomiedzy zwyklym MVP/MVC a rozszerzeniem z H ;]

Rozumiecie o co mi chodzi?
Chcialbym zeby poki co kazdy z was oprocz wykladow pomiedzy MVC a MVP i ich implementacji w php skupil sie pomiedzy zwyklym "modelowaniem" aplikacji za pomoca MVC/MVP a Gdy dodamy nastepny poziom "abstrakcji" Hierarchial.

Dla mnie HMVC/P jest bardziej naturalnie odrazu zaczolem pisac aplikacje modularnie, z klockow gdy tylko zapoznalem sie z MVC/MVP z czasem zorientowalem sie ze tworze aplikacje wlasnie "zgodnie" z HMVC.
TO jest najwieszka przewaga nie wyobrazam sobie pisac nie modularnie.

Dla was jakie sa plusy?Sa inne roznice itp...itd...?

@Crozin w sumie racja, najmniej bolesnym nazewnictwem dla wszystkich miłośników prawidłowej nomenklatury wzorców, będzie "trójwarstwowa architektura aplikacji"
@Marcio bardzo dobrze, że wiesz o co chodzi w tych wzorcach i w ostatnim poście napisałeś, że dobrze pisze Ci się w HMVC. Czy teraz jeżeli dla przykładu trzy, powiedzmy dość szanowane i ogólnie dobrze znające się na programowaniu, osoby z tego forum, wypiszą ci mnóstwo plusów na temat MVC, to porzucisz programowanie w HMVC, które wydaje Ci się naturalne i wygodne? Ja przyznam się szczerze przegapiłem moment w którym wzorce projektowe przestały być wskazówkami dla programistów, a stały sie kajdanami. Ale to tak zupełnie na boku .

Żeby nie było totalnego off-topa to dla mnie podstawową zaletą Hierarchical MVC, podobnie jak u Ciebie, jest jego modułowość, co pozwala na wygodne powtórne używanie kodu, no i co się z tym wiąże mniejsze zależności między konkretnymi modułami. No ale jak wcześniej pisałem, moja trójwarstwowa architektura wystarcza mi w zupełności w codziennej pracy.

Pozdrawiam

@marcio oczekujesz bardzo szczegółowej odpowiedzi na ogólne pytanie. A w rzeczywistości HMVP nie jest lepsze w niczym od MVP. Powiem więcej, MVP nie jest lepsze od HMVP.
Po prostu oba wzorce są najlepsze w zastosowaniu do odpowiednich problemów. Zaproponuj konkretny przypadek to dowiesz się jakie mogą być plusy i minusy (H)MVP.

Podobnie można dyskutować czy młotek gumowy jest lepszy od młotka żelaznego. A tak naprawdę oba są "lepsze".

To podaj jakies 2 przyklady gdzie lepiej bedzie pasowal jeden wzorzec a gdzie drugi, skoro pytam to znaczy ze nie widze 2 konkretnych przypadkow, dla mnie (H) bedzie zawsze lepsze niz zwykle tworzenie aplikacji, poprostu dla mnie modulowosc rozbijanie aplikacji na klocki to wielki plus, wyszlo mi to naturlanie z czasem wiec nie wiem dlaczego MVC/MVP mialoby byc lepsze w jakimkolwiek przypadku

TO jak dyskusja sie juz skonczyla, myslalem ze wyniosy z niej cos nowego,a tu nic!

Szczerze... mnie się już nie chce po raz 2342346 wałkować wątku z "MVC" w nazwie - szczególnie, gdy pytanie jest tak prymitywne:

http://www.google.com/search?client=opera&...-8&oe=utf-8

@Crozin jak nie masz co napisac na temat nie pisz wcale, mi sie nie chce wysluchiwac twojego marudzenia.
Takiego watku na forum jeszcze nie bylo, wiec pisze

Z google'a korzystac potrafie