Forum PHP.pl

Witam,
Nie jestem zawodowcem jeżeli chodzi o programowanie w PHP i postanowiłem nieco podnieść swoje umiejętności i poszerzyć wiedzę.
Najczęściej pracuje na CodeIgniter i w związku z tym zacząłem przeglądać tutki (szczególnie video) i troszkę się zaskoczyłem.

Kiedyś zgłębiając zasady wzorca MVC wielokrotnie spotykałem się z kilkoma fundamentalnymi zasadami takimi jak:
...
-kod html,JS,CSS może występować tylko w widoku
-kod SQL,kod operacji na plikach, WS itp może występować tylko w modelu
-kontroler pobiera dane od usera, jak trzeba przepuszcza je przez model i to co otrzyma z modelu wrzuca do widoku gdzie ubierane jest to w znaczniki i wyświetlane (więc kontroler raczej szczupłym tworem jest)
...

No i na owych tutorialach (mimo iż widać że programiści od wczoraj nie dziobią w PHP) to jest wolna amerykanka w stosunku do tych zasad. Najczęściej cała masa html jest produkowana w kontrolerze, a i w kilku przypadkach w modelu tworzony jest gotowy kod html do przesłania przez kontroler do widoku.


Co o tym sądzicie ?

pozdrawiam
KB

W MVC widok pobiera dane bezpośrednio z modelu, ale mniejsza z tym.
A co o tym można niby sądzić? Ot, widocznie kod jest słabej jakości, albo nie ma potrzeby silnej separacji warstw aplikacji. Ludzie zapominają, że "mityczne MVC" to jedynie nazwa dla pewnej, konkretnie zdefiniowanej architektury oprogramowania, określającej ogólną budowę aplikacji i przepływ danych w niej. Ale od kilku lat jest szał na nazywanie wszystkiego MVC-em.

Ten post edytował Crozin 28.09.2012, 17:27:03

Kontroler pobiera dane z modelu i wysyła je do widoku. Koniec. MVC jest tym jak sam je rozumiesz. Ilu koderów, tyle interpretacji, dlatego są od tego odłamy np. MVP.

Hmm ja zawsze pisałem aplikacje tak by kontroler sklejał wszystko tj. tak jak

tu:
(IMG:http://pragnakiran.com/wp-content/uploads/mvc-architecture.gif)
i tu:
(IMG:http://svn.akelos.org/trunk/docs/images/akelos_mvc.png)

i tu:
https://encrypted-tbn1.gstatic.com/images?q...SsXp-AiGG5NBV3g

i troche jak tu:
http://blog.agafonov.net.ua/image.axd?pict...2Fmvc-rails.png

i......

ale tak jak pisałem jestem hobbystą.

(IMG:http://www.beansoftware.com/ASP.NET-Tutorials/Images/MVC-Diagram.gif)

raczej tak powinno być.

View to nie html. tylko klasa.

Ten post edytował KotWButach 28.09.2012, 19:04:23

Mi się czasem wydaje że ludzie piszą zgodnie z hmvc (mają akcie i componenty co wywołują akcje) a i tak nazywają to mvc http://techportal.inviqa.com/2010/02/22/sc...ions-with-hmvc/

@!*!: Nie ma miejsca na interpretację wzorca. Własna, nowatorska implementacja? Tak! Ale nie interpretacja. Przez to nazywanie każdej wielowarstwowej architektury MVC-em, wzorzec ten de facto przestał być wzorcem. Niestety teraz pisząc "tu jest zastosowane MVC" nikt nie wie czego się spodziewać. I bynajmniej nie chodzi tu o nieznane szczegóły implementacji - chodzi o całą architekturę, która potrafi być zgoła odmienna.
Jak sam wspomniałeś istnieją odłamy MVC, np. wspomniany MVP czy MVVM. To nie są żadne odłamy/warianty tylko inne wzorce, o których co najwyżej można powiedzieć "MVC-like" albo, że pierwotnie wywodziły się z MVC. Ich autorzy - w przeciwieństwie do tego co widzimy dzisiaj - zauważyli, że w ich architekturze istnieją zasadnicze różnice względem MVC więc zrobili najprostszą, a zaraz jedyną poprawą rzecz - nadali swojemu tworowi inną nazwę by uniknąć niejednoznaczności.

Zresztą widać to chociażby po kilku schematach jakie zostały tutaj wrzucone - część z nich nie ma kompletnie nic wspólnego ze sobą.

@bor1904: To co podałeś to schematy całego żądania HTTP - nieco bardziej ogólnego procesu. Przedstawiają one architekturę jaką znajdziemy w większości PHP-owskich frameworków, z Symfony czy Zendem na czele. Na wikipedii jest całkiem sensowny jak na Wiki artykuł n/t tego wzorca: http://en.wikipedia.org/wiki/Model%E2%80%9...80%93controller Po przeczytaniu go, powinieneś zauważyć, że pokazane przez Ciebie schematy nie za bardzo pasują. Co więcej powinieneś zauważyć, że w środowisku protokołu HTTP bardzo ciężko jest zaimplementować MVC.

Zresztą MVC to jedynie wzorzec skupiający się na interakcji użytkownika z aplikacją, co stanowi jedynie małą część całej architektury aplikacji. W pogoni za "trendem MVC" praktycznie zapomniano w środowisku PHP o znacznie istotniejszym fragmencie aplikacji jakim jest przetwarzanie danych.
Nie znam PHP-owego frameworka, który spróbowałby chociaż podjąć ten temat - chodzi tu o takie warstwy aplikacji jak warstwa logiki biznesowej, warstwa usług, dostępu do danych i interakcji pomiędzy nimi. Stąd później takie potworki jak korzystanie z ORM-a w kontrolerach czy przekazywanie danych z kontrolerów do widoków, gdzie te ostatnie utożsamiane są po prostu z szablonami. Ach, no i oczywiście pomiędzy warstwą modelu (czyli ta najbardziej skomplikowana, rozbudowana i przez MVC kompletnie nieopisana - bo to nie jest zadanie dla tego wzorca), a ORM-em właściwie można postawić znak równości w większości projektów.

Ja tam jestem prostym chłopem i tak so to wydedukowałem:

Najpierw wybrałem sobie autorytet - CodeIgniter - dlaczego? (google: "php framework ranking" i kolejno...)

2 miejsce http://www.phpframeworks.com/top-10-php-frameworks/
1 miejsce http://davidjconnelly.wordpress.com/2011/0...mework-of-2011/
1 miejsce http://hotframeworks.com/languages/php
3 miejsce http://www.devshed.com/c/a/PHP/7-PHP-Frame...ed-For-Speed/2/
w 5 najlepszych ever http://www.wykop.pl/ramka/347003/5-najleps...warto-wiedziec/
....

Twórcy twierdzą że jest to FW oparty na MVC:
http://codeigniter.com/user_guide/overview/mvc.html

Do kotawbutach " A View will normally be a web page," a czym jest typowa strona WWW jak nie HTMLem?
(oczywiście prosta klasa View nie napisana jest w HTML ...ale chyba nikogo nie podejrzewa się o tak wyrafinowane myślenie)

Obsługę widoku i modelu przez kontroler zalecają tak w oficjalnym tutku:
http://codeigniter.com/user_guide/general/models.html

[PHP] pobierz, plaintext 
class Blog_controller extends CI_Controller {
 
    function blog()
    {
        $this->load->model('Blog');
 
        $data['query'] = $this->Blog->get_last_ten_entries();
 
        $this->load->view('blog', $data);
    }
}
[PHP] pobierz, plaintext 

Tego nie neguje nikt z wielu tysięcy developerów i użytkowników CI ...





Dlaczego więc głoszę nieprawdę ?

Dwa (nieświadome) błędy tutaj popełniłeś:
1. Rzuciłem szybko okiem na te pięć linków - część opiera się na kompletnie niemiarodajnych testach (zła konfiguracja, "mierzenie" bardzo małego fragmentu FW i rzutowanie wyników na całość), część nieco stara, część to mocno subiektywne oceny "jak mi się z niego korzystało", a w części w ogóle brakuje jakiejkolwiek argumentacji.
2. Posłużyłeś się autorytetem jako takim. Czyli uznałeś, że jakaś "prawda" jest lepsza bo napisał to ktoś, a nie dlatego, że stoją za tym solidne argumenty.

Nieświadome, bo ciężko od kogoś niezaangażowanego w temat wymagać tutaj cudów.

Podobnie jak twierdzą twórcy JSF-a, a oba frameworki działają w oparciu o diametralnie różną architekturę.

Bo widokiem może być również: obrazek, xml/json, pdf, email, mms, plik do druku, kod JS i wiele, wiele innych. Ale zazwyczaj będzie to szablon HTML.

PS. To, że te frameworki nie mają w rzeczywistości nic wspólnego z MVC nie znaczy, że są złe. Powiem więcej: MVC dla stron WWW to wyjątkowo zły pomysł - zresztą trudno, by wzorzec zdefiniowany dla aplikacji desktopowych dobrze wpasowywał się w strony WWW.

W zasadzie to... http://forum.php.pl/index.php?showtopic=80488&hl=MVC

dzięki za rozszerzenie mojego skrótu myślowego.

Ponieważ każdy uważa że jego rozwiązanie jest poprawne. Ci co chcą podciągnąć się bliżej MVC stosuja klasy/moduły w stylu View_Model
http://techportal.inviqa.com/2010/11/02/cr...wmodel-pattern/
Niewiem na ile jest to poprawnę, skuteczne i wygodnę ponieważ sam tego nie używałem.

Osobiście robie mniej więcej tak

[PHP] pobierz, plaintext 
public function action_add()
    {
        $this->template->content = $this->form();
    }
 
    public function action_edit() 
    {
        $value = array();
        $value = $this->model->get()->current();
 
        if(!$value)
        {
            throw new HTTP_Exception_404("No item found");
        }
 
        $this->template->content = $this->form($value);
    }
 
public function form($values = array)
{
     return View::Factory('form');
}
[PHP] pobierz, plaintext 

Oczywiście nie jest to poprane rozwiązanie.

z innej beczki,
zakładając, ze z fw za się tylko symfony1.4/2, jak bardzo problematyczne będize przejście na cakePHP?

Cake jak i Kohana to bardzo proste FW, nie trzeba nawet studiować tutoriala/dokumentacji bo 95% rzeczy można wyczytać analizując kod

nie wiem czemu, ale zawsze wydawało mi się że cake jest jakiś wyjątkowy

"No complicated XML or YAML files. Just setup your database and you're ready to bake."
to mi się bardzo podoba:D

Ten post edytował usb2.0 29.09.2012, 14:32:00

Dla nas wszystkich cakePHP powinien być wyjątkowy ze względu że zapoczątkował go nasz rodak (IMG:style_emoticons/default/smile.gif) Tak tak. Nazwiska jednak nie pomnę. Jednak koledzy po fachu twierdzą że przy większych projektach cake staje się nieco problematyczny nie wiem co jednak mieli na myśli gdyż na sale wnieśli pizze i przestało być to tak istotne (IMG:style_emoticons/default/wink.gif)

wracając do samego mvc niestety prawda jest okrutna oraz mocno ogólna.
http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf
http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html
Sam poszukuję złotego grala tego wzorca niestety nadzieje płonne.


a oto ten Pan
http://heim.ifi.uio.no/~trygver/
"I created the Model-View-Controller pattern as an obvious solution to the general problem of giving users control over their information as seen from multiple perspectives. MVC has created a surprising amount of interest. Some texts even use perverted variants for the opposite purpose of making the computer control the user. I have collected some relevant papers including my original technical note from Xerox PARC."

Ten post edytował KotWButach 30.09.2012, 00:56:23