Witam,

Ostatnio okoliczności zmusiły mnie do korzystania z CodeIgnitera z jego wersją MVC.

I nawet sobie radzę, nie o to chodzi. Tylko tak ciekaw jestem ilu z Was używa MVC (w dowolnym frameworku lub bez) a ilu pozostaje przy "staroświeckim" stylu?

Edit: ojej, i gdzie moja sonda? Tak się starałem.
Możecie w takim razie odpowiedzieć tylko: używam/nie używam w odpowiedzi?

używam

O, dziękuję za pierwszą odpowiedź, na razie 100% członków forum.php.pl używa MVC

A jakie jest rozróżnienie na "staroświecki" styl i "niestaroświecki"?

No staroświecki to ten bez MVC, znaczy budujemy sobie jakieś pożyteczne klasy, następnie gdy chcemy zrobić jakąś stronkę 'nowa_strona.php' , includujemy te klasy i w jednym pliku robimy odczyt z bazy danych, wypisanie treści, reakcje na akcje użytkownika (ajax/wysyłanie formularza etc).

Hm... a czy Ty wiesz czym w ogóle jest MVC? Rozumiesz subtelne różnice między OOP i programowaniem strukturalnym, bo wydaje mi się, że nie do końca. To alternatywą jest tylko MVC?

Nie no wiem co to jest programowanie obiektowe.... i również tego używam bez MVC, więc wiem, że można i że to nie ma związku.

Nie chodzi mi w pytaniu o używanie bądź nie OOP, tylko właśnie o MVC.
A może są jakieś inne znane wzorce projektowe (czy tam architektoniczne) niż MVC?

http://stackoverflow.com/questions/141912/...ives-to-the-mvc

I używasz któregoś z nich?

No dobra, to zmieniam odpowiedzi na pytanie:)
1. Nie, nie używam żadnego wzorca architektonicznego
2. Tak, używam MVC lub coś innego

To w ogóle jest sens robienia wszystkiego bez MVC? (niekoniecznie musi być obiektowe)

No właśnie chcę się dowiedzieć jak to statystycznie wygląda.

Jak przeglądam to forum (i inne) to dużo problematycznych skryptów (w pytaniach forumowiczów) łączy widok z manipulacją/odczytem bazy danych.

No bo tak na moją głowę, to MVC przydaje się gdy mamy do zrobienia wiele widoków dla jednego zestawu danych (zwykła strona/mobilna strona/rss, wszystko np. z controlera newsy). No ale jak ja wiem, że tak nie będzie?

Właściwie to wykorzystuje się go do odseparowania części logicznych tworzonej aplikacji. Jeżeli design jest dobry, to programista nie musi się przejmować jak wygląda widok, a jedynie musi tam dostarczyć odpowiednie dane. Dzięki temu, jeżeli kiedyś znudzi nam się wygląd, to jedyne czego dotykamy, to właśnie pliki widoku, a reszta nas nie interesuje. Kontroler zapewnia ci 'połączenie' pomiędzy widokiem, a modelami, natomiast większość logiki powinna być wykonywana w modelach.
Więc tak naprawdę używa się tego dla wygody i przejrzystości kodu.
Ja osobiście od jakiegoś czasu pisze w Zendzie oraz Kohanie, gdzie jest zaimplementowane MVC, więc siłą rzeczy jestem na niego skazany:)

No to jak na razie wciąż 100%



No ja to do tej pory robiłem tak, że w każdej stronie umieszczałem require_once('inc/layout.php') w której miałem funkcje echo Layout::pageStart(tytuł, słowa klucz... etc), potem treść, a potem echo Layout::pageEnd(); i jeszcze parę funkcji zw. z layoutem. Poza tym klasy pracujące na poszczególnych tabelach (coś w rodzaju modelu, klasy te też includowałem w tym pliku) i też byłem zadowolony, mogłem łatwo zmieniać wygląd header'a, left/right menu, footera i innych stałych elementów. A to co pomiędzy pageStart i pageEnd to i tak było różne ze strony na stronę. Więc nadal nie kumam tej mani MVC:)

Ja staram się od niedawna pisać wszystko zgodnie z MVC... Polecam
Ten artykuł
aby zrozumieć co to w ogóle jest to MVC...

I tu już masz jakieś oddzielanie, ponieważ zakładam, że ten twój layout generuje przede wszystkim html'a z danymi przekazywanymi w metodach. Raczej nie ma w nim żadnej logiki tzn. nie ma tam np. metody do pobierania danych z bazy.

No i tak jest zazwyczaj:)
Chodzi jedynie o przejrzystość kodu i jego logikę.
Załóżmy, że masz wyświetlić na stronie tabele z danymi z bazy, parę buttonów określających sortowanie tej tabeli, paginację i filtrowanie tych danych.
Więc w widoku miałbyś:

[HTML] pobierz, plaintext 
<table>
<?php foreach($data as $row) {
  ?>
     <tr><?php foreach($row as $col) {
      ?><?php echo $col; ?><?php
      } ?></tr>
  <?php
} ?>
<table>
<!-- tutaj jeszcze buttony z paginacją itd. -->
[HTML] pobierz, plaintext 

W kontrolerze;

[PHP] pobierz, plaintext 
<?php 
$model = new DataModel();
// tutaj ustawienia przesłanej paginacji, sortowania i filtrów
$this->view->data = $model->getData();
[PHP] pobierz, plaintext 

A w modelu całą logikę pobierania danych.

I teraz widok możesz używać wielokrotnie i nie interesuje cię jakie dane i skąd je pobiera.
Kontroler odbiera tylko to, co dostał od użytkownika (sortowanie itp.) i ustawia to dla danego modelu.
Cała logika pobierania danych jest natomiast w modelu (np. pobiera dane z bazy).

No dobrze bastard13 Już jestem przekonany, właśnie ściągnąłem Kohanę i z nią walczę




No ja też już mam teraz taki zamiar, ale powiem, że ten artykuł mi nieco zamieszał w głowie - widok odwołujący się do modelu? A już myślałem, że zaczynam kumać MVC...
Ale poza tym blog bardzo ciekawy.

Dzięki Wam za wszystkie odpowiedzi.

Szkoda, że tak mało głosów, bo miałem nadzieję jeszcze na "sondę" pt. jaki framework, ale pewnie znowu wyjdzie "100%" czyli jeden głos będzie:)

Np. jakiś MenuModel, który w zależności od roli zalogowanego usera zwraca inne menu. Idealnie pasuje, aby wywołać go bezpośrednio w widoku:)

No ja to najchętniej w ogóle bym się pozbył albo kontrolera albo modelu Nazwałbym to wzorcem VS (View & Something). Tak więc podoba mi to

W tej chwili Symfony2 tylko i wyłącznie do własnych projektów. W pracy jestem przymuszany do CakePHP. :<

Tylko nie twórzmy kolejnego tematu o wyborze frameworka:

Wybór Frameworka.

Konrados... Kohana to też nie MVC. W wersji 2.x to MVP, a jako 3.x to HMVP I od razu mówię... Jeślizaczynasz to będziesz mial niesamowity problem, bo dokumentacja niby jest, ale nie dość że słaba to jeszcze z błędami. A to co zrobili przy 3.1 woła o mordobicie Trochę pozmieniali w 3.1rzeczy i się lekko parę rzeczy wywaliło z powodu utraty kompatybilności wstecz. Dlatego szczerze mówiąc, to bierz się za jakiś FW bardziej wspierany. Z Kohaną, mimo iż prosta, będziesz tylko mięchem rzucał. Wiem, bo sam pracuję od jakiegoś czasu z 3.1 i często głowię się nad teoretycznie prostymi rzeczami, bo muszę grzebać po całym frameworku by coś znaleźć. Tak więc fw jedynie dla osób, które mają miłość do grzebania w kodzie i na dodatek rozumieją co w nim jest Wielu osobom się wydaje że to potrafią, bo gdy myślą, że znają parę funkcji php to już potrafią wszystko i zrozumieją także wszystko. A potem dostają obuchem i jest płacz. Zacznij od czegoś co jest dobrze udokumentowane i uwierz, że to tylko z troski o Twoje nerwy

Ale wracając do tematu. Ja wolę MVC, ale to po prostu samo tak wyszło w trakcie nauki, gdy jeszcze wzorców nie znałem. Lubię porządek w kodzie i tyle. A to czy uzyje do tego kodu strukturalnego czy obiektowego to już tylko kwestia zapisu i potrzeb w danej chwili. Ja piszę zarówno nowe rzeczy w OOP, jak i dopilnowuję, konserwuję stare skrypty, gdzie spaghetti to norma i nieraz trzeba się nieźle nagimnastykować, by po przeróbkach miało to ręce i nogi No ale z czasem poprawiając serwisy tworzysz biblioteki, które przenosisz między nimi i nabierasz takiego doświadczenia, że lokalizujesz każdą możliwą awarię w kilkadziesiąt sekund. Znasz bowiem kod na wylot. Po jakimś czasie dochodzisz do wniosku, że te biblioteki to zalążek czegoś dużego i tak powstają moduły do frameworków czy całe frameworki. Wtedy masz już taką wiedzę zazwyczaj, że polemika na temat "Czy to jest MVC?" Cię już nie interesuje i wolisz sie zająć czymś bardziej sensownym niż flamewar. Mido tego poziomu jeszcze daleko,ale zauważam u siebie symptomy, że idę w dobrą stronę powoli

I ta wypowiedź naprawdę mi się spodobała.

Czym jest MVC ,jak nie zbiorem bibliotek zrobionym w OOP

MVC to nie zbiór bibliotek. To sposób patrzenia na zależności, przepływ informacji, wzajemne powiązania oraz podział kompetencji pomiędzy obiektami. Zbiór bibliotek to "jedynie" framework, który mniej lub bardziej może na jakimś wzorcu czy ideologii bazować.

Jest tutaj stanowczo wykonywany inny model biznesowy programowania,co nie znaczy że język programowania jest inny.
Procesy ,algorytmy,struktury danych, muszą być w czymś napisane,a w czym jak nie w OOP albo języku strukturalnym,gdzie dane użytkownika są "przechwytywane i przerabiane przez te procesy,i wyświetlane jako wynik końcowy tych ów procesów.

Owszem, ale MVC nie znaczy od razu, że musimy korzystać z OOP. Równie dobrze mogę sobie rozbić kod strukturalny na wiele plików, które mi z grubsza podziałowi MVC będą odpowiadać i też będzie to poprawne. Dlatego jak wspomniałem... MVC jest wzorcem, który powinien być rozpatrywany niezależnie od języka programowania, a w określonym może być lepiej lub gorzej implementowany. W PHP jest z tym kiepsko, ale taka jest specyfika tego języka, że w nim ciężko to zrobić poprawnie, ponieważ sieć www jest bezstanowa i wykonuje się od żądania do żądania, a więc komunikacja jest mocno ograniczona i w zasadzie trwa jedynie na okres trwania wykonania skryptu. Nie ma możliwości by sobie coś poczekało i potem samo z siebie zakomunikowało coś do innego obiektu. To już by było nowe żądanie i nowy skrypt. Skrypt oparty na zdarzeniach miałby dużą szansę na prawidłową implementację, ale powiedz mi jak skrypt miałby sam siebie sprawdzać czy coś się stało? Ano to byłyby kolejne żądania w sieci i na dodatek musiały by być rozpoznane oraz przechwycone. tak więc jak sam widzisz, nie ma tak różowo...

Ja piszę zarówno nowe rzeczy w OOP, jak i dopilnowuję, konserwuję stare skrypty, gdzie spaghetti to norma i nieraz trzeba się nieźle nagimnastykować, by po przeróbkach miało to ręce i nogi i wcale nie jest różowo.


Ale jeśli chodzi o MVC a dokładniej o jego odmianę MVVC z tego co widzę, to się w MS VS.NET sprawdza,może trzeba poczekać na MVC dl PHP trochę dłużej-od niedawna przecież PHP weszło, żebym mógł powiedzieć"w szerszy świat obiektówki".Nie od razu Rzym zbudowano:).

Ok, rozumiem, że widzisz sens w posiadaniu widoku:)
Co do podziału na kontroler i model, to chodzi o to, że wyobraź sobie, że masz stronę z formularzem i jej logika wygląda tak:
1) Sprawdzasz czy zostały przesłane dane.
2) Dane zostały przesłane, więc walidujesz.
4) Przeszły walidację, więc zapisujesz do bazy.
5) Nie przeszły, więc zwracasz odpowiednie błędy dla pól
6) Tak, czy inaczej wyświetlasz komunikat.
7) Tak czy inaczej wyświetlasz formularz
8) Może wyświetlasz jeszcze jakiś tekst, który jest pobierany z bazy?
9) Może dane nt. uzytkownika, które są trzymane w sesji

I teraz implementacja z kontrolerem i modelami wygląda mniej więcej tak ($this = kontroler):

[PHP] pobierz, plaintext 
if ($this->dataWasSent())
{
 $validator = new Validtor();
 if($validator->isValid($this->getData()))
 {
    $dataModel = new DataModel();
    $dataModel->setData($this->getData());
    $dataModel->save();
  }
  else
 { 
   $this->view->errors = $validator->getErrors();
  }
}
 
$this->view->form = new Form($this->getData());
[PHP] pobierz, plaintext 

Jeszcze jak dorzucisz do tego bloki try-catch, bo np przy savie może wystąpić exception, to już ci się kod rozrasta.
Cała logika natomiast, czyli wygląd DataModel i zapisywanie, walidacja i cały jej proces, tworzenie formularza, przerzucasz na modele.

A teraz spróbuj to zrobić bez modeli:) Ile więcej kodu i o ile mniej przejrzysty?

O to chodzi w programowaniu obiektowym, żeby nie mieszać logiki obiektów, więc np model danych nie powinien posiadać walidatora i formularza do wyświetlenia, Form powinien tworzyć formularz i go wyświetlać i tyle. Żadnej dodatkowej funkcjonalności, która nie jest powiązana z logiką, bo później będziesz miał coś takiego, że zrobisz new Form() i okaże się, że została wykonana operacja pobierania danych z bazy, ich filtrowanie i walidacja. Czy to ma sens?


Framework, to nie jest zbiór bibliotek. Zbiór bibliotek to po prostu większa biblioteka:) Framework jest narzędziem do wspierania tworzenia aplikacji i z założenia wymusza pewną architekturę, musi również posiadać jakieś jądro oraz dostarczać klasy (lub inną implementację) ustawiania środowiska frameworka.


No trzeba się zgodzić, że w PHPie nadal nie ma wielu rzeczy, które by się przydały, ale uważam, że w PHPie nie da się programować w pełni obiektowo. Da się, tylko trzeba unikać pewnych możliwych rozwiązań i radzić sobie bez niektórych niezaimplementowanych:(

Z całym szacunkiem, ale dawno nie przeczytałem takiej głupoty. PHP jest językiem wieloparadygmatowym, więc siłą rzeczy nie wszystko będzie robione na obiektach. Jeśli zaś uważasz, że brakuje czegoś w modelu obiektowym, to tym bardziej językiem obiektowym nie jest Java. Programowanie obiektowe nie polega na tym, że język udostępnia dużo bajerków. Zapewniam Cię, że PHP posiada wszystko, czego potrzeba, natomiast reszta to mniej lub bardziej wyszukany lukier składniowy i magia.

apropo MVC:
co sądzicie o przeniesieniu do Javascriptu Kontrolera i Widoku, a po stronie serwera zostawić tylko Model?

Takie rozwiązanie pozwala na zrealizowanie obsługi zdarzeń, czyli tego czego brakuje w "MVC" tylko po stronie serwera.

@up Zyx

Miało być: że w PHPie DA się programować w pełni obiektowo:) Mój błąd:P

Zgadzam się całkowicie z tym co napisałeś


Ja uważam, że przy większych aplikacjach dobrze jest traktować to co po stronie klienta i to, co po stronie serwera jako dwie osobne aplikacje, a fakt, że w jakiś sposób są ze sobą zsynchronizowane, to inna kwestia.
Tak naprawdę i po jednej, i po drugiej stronie implementacja MVC jest możliwa, a przy większych projektach nawet wskazana, bo pozwala uporządkować kod w jakiś sensowny sposób.

No dobra, ale jesli już decydujemy się na napisanie części aplikacji w Javascript (przy założeniu że nie dodajemy obsługi bez JS), to po co dublować kod? Po co po stronie serwera nam kontrolery i widoki, jak potrzebujemy tylko dostęp do danych?

I chcesz całą stronę generować za pomocą js po stronie klienta?
Chcesz obsługiwać każdy model za pomocą JS? To spowoduje sporą ilość requestów.
Np. prosty formularz:
Skoro kontroler jest po stronie JS, to powinno wyglądać tak:
1) wypełniam formularz i wysyłam request z danymi do walidatora
2) otrzymuję request, czy walidacja przeszła poprawnie
3) wysyłam request o zapis danych do bazy. I co? Waliduje je jeszcze raz (przecież nie mogę zakładać, że są dobre), a skoro dochodzi walidacja, a później zapis, to już są dwa modele i do ich synchronizacji przydałby się kotroler:)

@bastard13 : jeszcze raz wielkie dzięki, dzięki Tobie do mojego małego Kubusiowego mózgu powoli docierają zalety pełnego MVC

@thek, napisałeś:


Wiem, że już była/jest dyskusja na temat frameworków, wspomniania tutaj ( http://forum.php.pl/index.php?showtopic=96851 ) ale ona się ciągnie na 20 stron i trwa od 2008 roku, jestem mniej więcej w połowie:)

Mam takie pytania: korzystasz z Kohany bo musisz (np. w pracy) czy jednak bo chcesz:)?
Bo jednak Kohana 3x, chyba najbardziej mi się podoba. Chcę frameworku, który od razu wspiera jakąś tam architekturę (strukturę folderów, nazewnictwo klas etc, podobnie jak CodeIgniter). Jeśli chodzi Symfony to z pobieżnej lektury wynika, że ciężko to będzie zainstalować na shared hosting. Zend Framework to podobno tylko kupa klas, z którą trzeba sobie poradzić, zresztą też instalacja na shared hosting jest skomplikowana. CodeIgniter mniej więcej znam, ale używają klas raczej jako namespaców co średnio mi się podoba. Pozostałe frameworki są b. mało znane i nie chciałbym w coś takiego wchodzić.

Pozostaje Kohana 3x:) Dlatego tak pytam, dlaczego jednak Ty i wielu innych, mimo słabej dokumentacji, diametralnych zmian API (podobno) robicie jednak w Kohanie 3x?

Że niby w czym ta trudność?

No pierwszy link w googlu to parę stron procedur:
http://trac.symfony-project.org/wiki/Insta...SharedHostNoSsh

W tym trzeba umieścić jakieś foldery poza public_html i nie jestem pewien czy każdy host pozwoli na dostęp do tych plików z plików w public_html, ale się średnio znam:)

Poza tym wydaje mi się to raczej trickiem niż jakąś standardową metodą...

Proszę, jeśli się mylę to mnie popraw, na każdym shared hosting ten trick pójdzie? To w takim razie symfony też bym spróbował

Najłatwiej (przynajmniej w Symfony2) jest po prostu przekierować domenę do katalogu niżej (w tym wypadku "web") i wtedy nie ma problemów. Z poziomu domeny nie dostaniesz się do katalogu niżej (czyli do głównego katalogu Symfony2).

Oj, teraz widzę, że symfony nie ma czegoś takiego:
http://docs.kohanaphp.com/libraries/database/builder
Znam to z codeignitera i bardzo mi się spodobało. Widzę, że SF ma Propel, ale to dużo nauki, szczególnie gdy przyjdzie to uwzględnienia relacji w tych obiektach
Dodatkowo widzę, że są i inne problemy z SF niż tylko 'wskazanie folderu': http://forum.php.pl/index.php?s=&showt...st&p=548485

Tak więc jednak chyba Kohana. Tylko niech jeszcze ktoś potwierdzi, że dobrze myślę i przestanę Was męczyć z tym tematem a zacznę męczyć z Kohaną

Nie rozumiem pewnej rzeczy. Wybrałeś Kohanę i teraz na siłę doszukujesz się wad w innych frameworkach. Gdybyś choć TROCHĘ zainteresował się innymi, to zauważyłbyś, że to, czego nie posiada wg ciebie Symfony, posiada KAŻDY framework. Ale możesz też żyć w iluzji, że tylko w Kochanie możesz robić operacje na poleceniach do bazy danych. Twój wybór.

Jeśli chcesz szybko i przyjemnie załapać OOP, to tylko Symfony2. I zapewniam Cie, że ma wszystko czego potrzebujesz.

Nie miałem styczności z Symfony, więc się nie wypowiem.
Co do zenda, to na początek rzeczywiście może jest zbyt rozbudowany.
Ja zacząłem od zenda i po pierwszym prostym cmsie doszedłem do wniosku, że nie wiem na cholerę to całe MVC:)
Następna była Kohana 2.x i muszę przyznać, że mi się osobiście bardzo przyjemnie pracowało. Była na tyle prosta, że nie przerażała, a na tyle dobra, że wymuszała pewne słuszne zachowania.
Po jakimś czasie, jak zacząłem budować większe aplikacje i obiektówka była już czymś naturalnym, to brakowało mi interfejsów i klas abstrakcyjnych (wersja 2.x, nie wiem jak jest teraz). Ten cały core z klasami core_something z deklaracją klasy i pusta klasa something extend core_something:) Do tej pory nie za bardzo pojmuje czym twórcy kierowali się tworząc takie konstrukcje:)
Ogólnie, po pewnym czasie moja praca z kohaną wyglądała tak, że miałem drugi core, który był mój, a z klas kohana korzystałem sporadycznie. W tym momencie przesiadłem się na zenda i powiem ci, że nie miałem z nim już najmniejszych problemów.

Podsumowując, to Kohana (przynajmniej 2.x) jest uboga, ale na początek, moim zdaniem, dużo lepsza niż Zend, bo tak bardzo nie odstrasza. A po pół roku lub roku pracy z Kohaną przesiadka na Zenda będzie czymś naturalnym i bezbolesnym:)

No to jest fakt, ale czy nie ma tak większość z nas? Ciągle czytam http://forum.php.pl/index.php?showtopic=96851&st=160 tam to leci flame...


No to ewentualnie też tak skończę

Dziękuję wszystkim raz jeszcze.

nie rozumiem skąd Ci się bierze sporo ilość requestów, skoro większość logiki jest po stronie klienta, to wybór kontrolera, modelu i widoku nastepuje po stronie klienta,
zaś samo połączenie z modelem/modelami może nastąpić w jednym requeście


w twoim przykładzie juz w punkcie 1):
model otrzymuje dane, więc sprawdza poprawność *(jesli nie, odpowiedni response) i od razu zapisuje do bazy (jesli błąd, także response)

także w wiekszości standardowych przypadków zawsze można się zmieścić w jednym żądaniu do serwera

*, no można powiedzieć, że jako taki kontroler też mógłby byc po stronie serwera

Przeczytaj jeszcze raz to zdanie i popatrz na podkreślone fragmenty. Od razu widać, że powinny być dwa modele, ponieważ logika klas nie powinna się mieszać, czyli musisz mieć model walidatora i model obiektu bazy danych.
A co dostaje dane i dba o to, żeby otrzymał je walidator, a następnie obsługuje scenariusze w przypadku poprawnej i nie poprawnej walidacji? Do tego jest kontroler:)

W sporych aplikacjach MVC powinno być i po stronie serwera i klienta, ponieważ pomaga to lepiej się zorientować w tym co się dzieje.

dlatego zreflektowałem się zaraz po napisaniu tego i dodałem gwiazdke, że w zasadzie powinien byc jeszcze kontroler po stronie serwera, ale na pewno nie taki sam jak po stronie klienta, jakby zastosowac terminologię c#, można powiedzieć, że będziemy mieli dwa party klasy Kontroler

ale faktycznie sprawa nie jest prosta, jednak dobrze napisana aplikacja w ten sposób powinna dać sporo więcej możliwości dla GUI