Re: Poeksperymentujmy z MVC
Po wielu miesiącach posuchy nowa notka. ale też w tylko dlatego, że mi Zyx komentarza nie opublikował w całości. Publikuję ten tekst, utrzymany w konwencji odpowiedzi na wskazany wpis i proszę, wybaczcie toporny styl.
Oryginalny tekst Zyxa - lektura obowiązkowa: Poeksperymentujmy z MVC
Po wymianie e-maili, wygląda na to, że coś najwyraźniej poszło nie tak przy dodawaniu komentarza, co najwidoczniej przeoczyłem i Zyx nie dostał drugiej części, więc moje żale były nieuzasadnione, za co przepraszam.
Co do nomenklatury przyznaję Ci rację. Faktycznie odmianę trójwarstwowego podziału aplikacji (co jest istotą MVC) wdraża się we współczesnych FW pod postacią MVP. Ty dodajesz czwartą warstwę - Model (zgodnie z definicją Modelu Dziedziny). Tu też się zgadzam.
Ideą MVP i MVC jest wyodrębnienie 3 podstawowych warstw w aplikacji. Oba realizują to w nieco inny sposób, jednak w użytkowaniu niewiele się różnią, więc nawet nazywając MVP mianem MVC popełnia się błąd jedynie wtedy, gdy trzeba dookreślić relacje jakie istnieją pomiędzy tymi warstwami - to w jaki sposób współpracują (np podczas dyskusji dwóch programistów). W innym przypadku to po prostu uproszczenie. Może to źle, ale wyobrażasz sobie ten wysyp tematów na forum "MVC vs MVP - co lepsze?"
To trochę tak jak z "nie mieszaj php z html, używaj smarty" - wylansowany debilizm, ale pokutuje do dziś.
Jeśli mamy NewsModel, w którym dokonujemy wszelkich operacji na newsach i obiekt ten udostępnia spójny interfejs (wraz z Paginable itp.), to nadal pozostaje kwestia typu obiektu, który jest elementem kolekcji (np. NewsEntry - zgodnie z Row Data Gateway [pliki tekstowe też można "potraktować" tym wzorcem, ogranicza nas tylko konieczność implementacji flaków takiego tekstowego ORM). Zrób więc eksperyment - wygeneruj aplikację w Symfony, a następnie utwórz obiekty ModelTo, ModelTamto i zaimplementuj w nich to co chcesz, a następnie ogranicz kontroler do wyboru Modelu i wywołaj dowolny widok, który będzie korzystał z Twojego Modelu lub nawet Modeli) Dziedziny. W konsekwencji i tak staniesz przed koniecznością obsługi obiektu określonego typu. Żaden FW nie zrobi tego za Ciebie, bo po prostu nie wie jak wyglądają Twoje potrzeby biznesowe. Sam je musisz zdefiniować. Dlatego właśnie twórcy FW(tu Symfony) nie poszli na łatwiznę, Oni po prostu nie mogą tego zrobić inaczej. Mogą natomiast dodać domyślne źródło danych, czyli bazę danych, która przyda się 99% developerów. Jak mają niby dać ORM do txt, czy XMLA? No jak niby? Jak ktoś ma źródło danych w postaci XMLA, to rządzi się ten XML swoimi prawami - ma własną strukturę i nie da się dla niej stworzyć sensownej abstrakcji tak jak w przypadku baz danych mysql, czy postgresql.
ORM, jak nazwa wskazuje, umożliwiają mapowanie struktury i relacji występujących w bazie danych na obiekty dla języka programowania, zapewniają komunikację ze źródłem danych (też w osobnej warstwie - DBLayer) i dodatkowo, zapewniają interfejs do obiektowych operacji na tych relacjach w ramach wygenerowanych obiektów np.
To, że programiści idą na łatwiznę, wynika o dziwo z wiedzy o projekcie - z kontekstu. Jeśli wiem, że piszę aplikację do zarządzania danymi, to zazwyczaj jest ona związana z konkretną bazą danych i później źródło danych się nie zmieni, to jeśli wiem, że operacje które wykonuję są w efekcie operacjami na danych w bazie i ich relacjach, wystarczy mi użycie ORM bezpośrednio... bo szybciej z powodu automatyzacji. To zasada Brzytwy Okhama - tniemy zbędne obiekty. Zgoda, że potem można żałować niektórych decyzji, ale nadal wiem, jakich zmian (i gdzie) muszę dokonać, aby wyjść z opresji, więc w zasadzie nadal mam kontrolę nad całością. To oczywiście problem, jeśli piszemy oprogramowanie mocno elastyczne, pracujące w różnych warunkach (systemach/źródłach danych). Wtedy owszem, należy dodać Model (specjalnie przez wielkie M :) ) i na nim właśnie pracować. Jednak nie dla samej sztuki, tylko aby ograniczyć zasięg zmian przy modyfikacjach, więc znów cel jest praktyczny a nie abstrakcyjny.
Tak doszedłem do istoty sprawy, czyli do analizy potrzeb. W realnej pracy zachodzi konieczność wyprodukowania programu, który będzie działał i tyle.
Z kolei Ty musisz mieć kod źródłowy który da Ci pewność, że wiesz jak go rozszerzyć. To z kolei zapewnia Ci wiedza o ograniczeniach projektowych i technologicznych. Nie muszę wiedzieć, jak kontroler współpracuje z widokiem, bo z założenia ma to być przezroczyste dla mnie. Ja muszę fizycznie utworzyć nowy kontroler i nowy widok wg. jakiegoś schematu, który pozwoli mi np. wylistować jakieś rekordy z bazy, dodać interfejs sterowania i koniec. Jeśli zmieni się struktura danych, to zmieni się kod przynajmniej części widoku (np dodajemy nowe pole). To też można ograniczyć stosując jakieś datagridy, ale wtedy i tak często stoimy przed koniecznością modyfikacji parametrów datagrida. Gdzie i na jakim etapie, to już inna kwestia. Można to zrobić stosując szablon (tzw partial, a jak ma logikę to w komponent), który z kolei możemy wsadzić w layout w dowolnym miejscu i on również, wbrew temu, co piszesz, jest do wykorzystania w wielu różnych miejscach i tylko on wymaga modyfikacji w przypadku zmian zaistniałych "wyżej".
Nie powiem - grid, który pokazujesz ma sens, jest nawet wykorzystywany w niektórych FW. Chętnie bym coś takiego widział w Symfony jako alternatywę dla omówionego wyżej rozwiązania, choć z drugiej strony, pomyślnie wdrożyłem w symfony system na ajaxowym datagridzie (obsługującym propel), który w praktyce działa niemal tak samo .Poszedłem na łatwiznę i konfiguracja jest w kontrolerze, co mi się nie podoba do końca.
W szablonie mam jedynie:
Reasumując.
O ile zgadzam się z Tobą w 99% co do wzorców wdrożonych do sf, to nie zgodzę się co do praktyki. Napisałem kiedyś FW który potrafił wywołać w jednym żądaniu X "akcji", zebrać dane dla każdej niezależnie i na koniec dostarczyć widok, który miał w osobnych obiektach dane z nich i potrafił je zaprezentować włącznie z załadowaniem css/js dla każdego podwidoku. Dziwny twór, który zarzuciłem po napisaniu w nim 2 lub 3 małych aplikacji tylko dlatego, że podczas używania odnotowałem, że... pisze się niewygodnie, a 90% funkcji było zupełnie nieprzydatne :)
Nie chodzi więc tylko o to, aby coś się dało gdzieś przenieść do innego projektu, nie chodzi też o to, że coś jest zgodne w 100% z MVC, tylko chodzi o to, czy to jest wygodne w codziennej praktyce i czy nie musisz tworzyć X plików tylko dlatego, że założenia tego wymagają.
Całkowicie pomijasz programowanie komponentowe i sloty, które są chyba tym, co uczyniło z symfony tak popularne narzędzie, o programowaniu zdarzeniowym tam obecnym nie wspominając ;)
Kiedyś na forum, w jakimś temacie napisałem Ci, żebyś zainteresował się tym, jak wygląda kod CMS'a Apostrophe, ale nie wiem, czy to czytałeś. Niemniej, po bliższym zapoznaniu, to to nawet nie jest CMS (na pewno nie taki jak Joomla), to jest raczej rozszerzenie symfony, bo naturalnie się wkomponowuje w dowolny projekt w dowolnym zakresie funkcjonalności.
Tu nie chodzi o to, co Fabien mówi (bo zakładam, ze do niego pijesz mówiąc o guru), tu chodzi o to, że gość ma praktykę i napisał FW, który jest wygodny, praktyczny i jest napisany kilka razy lepiej niż konkurencyjne rozwiązania.
Znów wyszedłem na fanboja symfony, ale trudno, po prostu odnoszenie się do przykład w z tego FW jest dla mnie najprostsze, bo jako tako znam ten system.
Trinity sobie obejrzę i zobaczę jako to działa w praktyce (co podkreślam - bo to jest najważniejsze w FW).
Pozdrawiam.
Oryginalny tekst Zyxa - lektura obowiązkowa: Poeksperymentujmy z MVC
Po wymianie e-maili, wygląda na to, że coś najwyraźniej poszło nie tak przy dodawaniu komentarza, co najwidoczniej przeoczyłem i Zyx nie dostał drugiej części, więc moje żale były nieuzasadnione, za co przepraszam.
Co do nomenklatury przyznaję Ci rację. Faktycznie odmianę trójwarstwowego podziału aplikacji (co jest istotą MVC) wdraża się we współczesnych FW pod postacią MVP. Ty dodajesz czwartą warstwę - Model (zgodnie z definicją Modelu Dziedziny). Tu też się zgadzam.
Ideą MVP i MVC jest wyodrębnienie 3 podstawowych warstw w aplikacji. Oba realizują to w nieco inny sposób, jednak w użytkowaniu niewiele się różnią, więc nawet nazywając MVP mianem MVC popełnia się błąd jedynie wtedy, gdy trzeba dookreślić relacje jakie istnieją pomiędzy tymi warstwami - to w jaki sposób współpracują (np podczas dyskusji dwóch programistów). W innym przypadku to po prostu uproszczenie. Może to źle, ale wyobrażasz sobie ten wysyp tematów na forum "MVC vs MVP - co lepsze?"
To trochę tak jak z "nie mieszaj php z html, używaj smarty" - wylansowany debilizm, ale pokutuje do dziś.
Jeśli mamy NewsModel, w którym dokonujemy wszelkich operacji na newsach i obiekt ten udostępnia spójny interfejs (wraz z Paginable itp.), to nadal pozostaje kwestia typu obiektu, który jest elementem kolekcji (np. NewsEntry - zgodnie z Row Data Gateway [pliki tekstowe też można "potraktować" tym wzorcem, ogranicza nas tylko konieczność implementacji flaków takiego tekstowego ORM). Zrób więc eksperyment - wygeneruj aplikację w Symfony, a następnie utwórz obiekty ModelTo, ModelTamto i zaimplementuj w nich to co chcesz, a następnie ogranicz kontroler do wyboru Modelu i wywołaj dowolny widok, który będzie korzystał z Twojego Modelu lub nawet Modeli) Dziedziny. W konsekwencji i tak staniesz przed koniecznością obsługi obiektu określonego typu. Żaden FW nie zrobi tego za Ciebie, bo po prostu nie wie jak wyglądają Twoje potrzeby biznesowe. Sam je musisz zdefiniować. Dlatego właśnie twórcy FW(tu Symfony) nie poszli na łatwiznę, Oni po prostu nie mogą tego zrobić inaczej. Mogą natomiast dodać domyślne źródło danych, czyli bazę danych, która przyda się 99% developerów. Jak mają niby dać ORM do txt, czy XMLA? No jak niby? Jak ktoś ma źródło danych w postaci XMLA, to rządzi się ten XML swoimi prawami - ma własną strukturę i nie da się dla niej stworzyć sensownej abstrakcji tak jak w przypadku baz danych mysql, czy postgresql.
ORM, jak nazwa wskazuje, umożliwiają mapowanie struktury i relacji występujących w bazie danych na obiekty dla języka programowania, zapewniają komunikację ze źródłem danych (też w osobnej warstwie - DBLayer) i dodatkowo, zapewniają interfejs do obiektowych operacji na tych relacjach w ramach wygenerowanych obiektów np.
123 |
<?php
|
To, że programiści idą na łatwiznę, wynika o dziwo z wiedzy o projekcie - z kontekstu. Jeśli wiem, że piszę aplikację do zarządzania danymi, to zazwyczaj jest ona związana z konkretną bazą danych i później źródło danych się nie zmieni, to jeśli wiem, że operacje które wykonuję są w efekcie operacjami na danych w bazie i ich relacjach, wystarczy mi użycie ORM bezpośrednio... bo szybciej z powodu automatyzacji. To zasada Brzytwy Okhama - tniemy zbędne obiekty. Zgoda, że potem można żałować niektórych decyzji, ale nadal wiem, jakich zmian (i gdzie) muszę dokonać, aby wyjść z opresji, więc w zasadzie nadal mam kontrolę nad całością. To oczywiście problem, jeśli piszemy oprogramowanie mocno elastyczne, pracujące w różnych warunkach (systemach/źródłach danych). Wtedy owszem, należy dodać Model (specjalnie przez wielkie M :) ) i na nim właśnie pracować. Jednak nie dla samej sztuki, tylko aby ograniczyć zasięg zmian przy modyfikacjach, więc znów cel jest praktyczny a nie abstrakcyjny.
Tak doszedłem do istoty sprawy, czyli do analizy potrzeb. W realnej pracy zachodzi konieczność wyprodukowania programu, który będzie działał i tyle.
Z kolei Ty musisz mieć kod źródłowy który da Ci pewność, że wiesz jak go rozszerzyć. To z kolei zapewnia Ci wiedza o ograniczeniach projektowych i technologicznych. Nie muszę wiedzieć, jak kontroler współpracuje z widokiem, bo z założenia ma to być przezroczyste dla mnie. Ja muszę fizycznie utworzyć nowy kontroler i nowy widok wg. jakiegoś schematu, który pozwoli mi np. wylistować jakieś rekordy z bazy, dodać interfejs sterowania i koniec. Jeśli zmieni się struktura danych, to zmieni się kod przynajmniej części widoku (np dodajemy nowe pole). To też można ograniczyć stosując jakieś datagridy, ale wtedy i tak często stoimy przed koniecznością modyfikacji parametrów datagrida. Gdzie i na jakim etapie, to już inna kwestia. Można to zrobić stosując szablon (tzw partial, a jak ma logikę to w komponent), który z kolei możemy wsadzić w layout w dowolnym miejscu i on również, wbrew temu, co piszesz, jest do wykorzystania w wielu różnych miejscach i tylko on wymaga modyfikacji w przypadku zmian zaistniałych "wyżej".
Nie powiem - grid, który pokazujesz ma sens, jest nawet wykorzystywany w niektórych FW. Chętnie bym coś takiego widział w Symfony jako alternatywę dla omówionego wyżej rozwiązania, choć z drugiej strony, pomyślnie wdrożyłem w symfony system na ajaxowym datagridzie (obsługującym propel), który w praktyce działa niemal tak samo .Poszedłem na łatwiznę i konfiguracja jest w kontrolerze, co mi się nie podoba do końca.
W szablonie mam jedynie:
1234 |
<?php
|
Reasumując.
O ile zgadzam się z Tobą w 99% co do wzorców wdrożonych do sf, to nie zgodzę się co do praktyki. Napisałem kiedyś FW który potrafił wywołać w jednym żądaniu X "akcji", zebrać dane dla każdej niezależnie i na koniec dostarczyć widok, który miał w osobnych obiektach dane z nich i potrafił je zaprezentować włącznie z załadowaniem css/js dla każdego podwidoku. Dziwny twór, który zarzuciłem po napisaniu w nim 2 lub 3 małych aplikacji tylko dlatego, że podczas używania odnotowałem, że... pisze się niewygodnie, a 90% funkcji było zupełnie nieprzydatne :)
Nie chodzi więc tylko o to, aby coś się dało gdzieś przenieść do innego projektu, nie chodzi też o to, że coś jest zgodne w 100% z MVC, tylko chodzi o to, czy to jest wygodne w codziennej praktyce i czy nie musisz tworzyć X plików tylko dlatego, że założenia tego wymagają.
Całkowicie pomijasz programowanie komponentowe i sloty, które są chyba tym, co uczyniło z symfony tak popularne narzędzie, o programowaniu zdarzeniowym tam obecnym nie wspominając ;)
Kiedyś na forum, w jakimś temacie napisałem Ci, żebyś zainteresował się tym, jak wygląda kod CMS'a Apostrophe, ale nie wiem, czy to czytałeś. Niemniej, po bliższym zapoznaniu, to to nawet nie jest CMS (na pewno nie taki jak Joomla), to jest raczej rozszerzenie symfony, bo naturalnie się wkomponowuje w dowolny projekt w dowolnym zakresie funkcjonalności.
Tu nie chodzi o to, co Fabien mówi (bo zakładam, ze do niego pijesz mówiąc o guru), tu chodzi o to, że gość ma praktykę i napisał FW, który jest wygodny, praktyczny i jest napisany kilka razy lepiej niż konkurencyjne rozwiązania.
Znów wyszedłem na fanboja symfony, ale trudno, po prostu odnoszenie się do przykład w z tego FW jest dla mnie najprostsze, bo jako tako znam ten system.
Trinity sobie obejrzę i zobaczę jako to działa w praktyce (co podkreślam - bo to jest najważniejsze w FW).
Pozdrawiam.
