Forum PHP.pl

otototo.. wiele wyzwalaczy kontrolerów, a nie wiele kontrolerów.. czyli np możesz mieć powiedzmy trzy wyzwalacze:

sklep.php
hurtownia.php
costamjeszcze.php

...wszystko będzie działało na tych samych klasach, ale będą inne konfiguraje odpalone. Tutaj mamy jedną witrynę podzieloną na trzy niezależne aplikacje korzystające z tych samych klas/bibliotek etc. Po co osobne konfiguracje? A po co hurtownia ma wiedzieć jakie są akcje dostępne w sklepie oraz na odwrót?

Oczywiście nie we wszystkich przypadkach jest sens tak robić... ale czasem takie myślenie może się przydać (np: gdy korzystając z phienda zaczyna nam się konfig niebezpiecznie rozrastać ;>)) )



A tam.. po prostu uważnie prześledziłem manual phienda ;>)P

witam,

więc bez zbędnych wstępów parę pytań:

1. nie wiem czy dobrze rozumuje: model to czesc programu, ktora jest posrednikiem pomiedzy DB a widokiem/akcja. wykonuje ona zapytania, wstawia dane i je zwraca ( w czystej postaci). dobrze rozumuje??

2. czy dla skryptu forum (ktory wlasnie chce zaprojektowac w oparciu o MVC) cos takiego bedzie poprawne:

a) dla wyswietlenia tematow

- kontroler ustala, ze przegladarka chce zobaczyc topiki. wywoluje widok 'showforum($forumid)'
- widok wywoluje model 'showforum($forumid)' ktory zwraca dane z bazy danych w czystej postaci (tablica)
- widok obrabia te dane, i przekazuje wynik do szablonow

(IMG:http://forum.php.pl/style_emoticons/default/cool.gif) dla wstawienia postu

- kontroler ustala ze przegladarka chce dodac posta. wywoluje akcje 'addpost'
- akcja wywoluje model 'addpost' ktory tylko robi polecenie insert i zwraca, czy udalo sie wstawic posta
- ta sama akcja po udanym wstawieniu wywoluje widok 'showtopic($topicid)'
-widok wywoluje model 'showtopic($topicid)' ktory zwraca dane z bazy w czystej postaci (tablica)
- widok obrabia te dane i przekazuje je do szablonow (smarty)

3. zamierzam wszystkie metody (nawet takie standardowe jak showtopic, showforum itp) umiescic jako moduły. Czyli taki moduł powinien składać się z modelu i widoku/akcji ?

to o czym myslisz to raczej DAO



- kontroler wywołuje akcje showtopic
- akcja wywołuje model
- widok odpowiada za wyswietlanie np. Smarty



moduł to raczej logiczny zbior akcji

A czy taki przebieg pracy aplikacji jest zgodny z modelem MVC?

• Tworzymy instancję Kontrolera
• Kontroler pobiera dane od Routera sparsowane dane _POST, _GET oraz _SESSION i na podstawie tych danych określa jaką akcję którego modułu ma wykonać (powiedzmy folder 'maths' plik 'mnozenie.action.class.php' i metoda 'execute();' albo plik maths.class.php, metoda 'mnozenie();' BTW który z tych sposobów wydaje się wam lepszy? )
• Akcja wykonuje jakieś operacje logiczne (np. w akcji, która za zadanie miałaby pomnożyć liczby, akcja by za to była odpowiedzialna) i przesyła odpowiednie dane do odpowiedniego widoku (np. mnozenie.view.class.php)
• Widok określa czy potrzebuje jeszcze jakiś danych, jeśli tak to pobiera je od modelu (np. $model->getData(); - tutaj pytanie - jak akcja powinna pobierać dane od modelu? Rozumiem, że nie ma być to kod SQL ale w takim razie jak uniezależnić to co chcemy pobrać od tego, w jaki sposób jest to przechowywane)
• Model korzysta z abstrakcji odpowiedniego źródła danych, pobiera te dane i wysyła je spowrotem do Widoku
• Widok zbiera te wszystkie dane do kupy i przekazuje do systemu szablonów.
• System szablonów parsuje dane pobrane od widoku na kod HTML i przesyła spowrotem do Widoku.
• Widok wysyła te dane w odpowiednie miejsce: np. przeglądarka, albo jakiś cache.

Tak w zasadzie wygląda moja koncepcja. Jak widać nie ma jednej klasy Widoku, jest ich wiele, natomiast Model i Kontroler jest tylko jeden.
Oczywiście to jest prosty przykład, bez żadnych łańcuchów, ale chciałbym wiedzieć, czy ta idea jest dobra, a jeśli nie to co w niej wymaga poprawienia.

ale teraz wywiązuj się pytanie: jeżeli dodam nową funkcjonalność do aplikacji (powiedzmy wyświetlanie userów) to oprócz widoku, który przetwarza dane z modelu, musze także dodać model odpowiedzialny za wyciągnięcie odpowiednich danych z bazy i przekazanie w czystej postasci widokowi. czy tak?

Nie wiem czy moja idea jest dobra ale czy mozna najpierw pobrac dane z GET POST i SESSION, potem wg nich stworzyc lancuch akcji a potem w petli while je wykonac (IMG:http://forum.php.pl/style_emoticons/default/questionmark.gif) oczywiscie ostatnią akcją byłoby wyswietlenie odpowiedniego widoku ...(IMG:http://forum.php.pl/style_emoticons/default/questionmark.gif)

Nie. W moim rozumowaniu model dostaje od widoku zapotrzebowanie na jakieś dane. Pobiera te dane i wzraca je widokowi. Niezależnie od tego jakie zadanie ma wykonać akcja Model pozostaje ten sam i służy za pośrednik pomiędzy aplikacją a źródłem danych. Takim źródłem danych może być baza danych obsługiwana przez klasę abstrakcji.

Prosiłbym o wypowiedź kogoś obeznanego w tych tematach i o poprawienie moich ew. błędów w rozumowaniu.

Ten post edytował matid 30.10.2004, 21:31:16

no tak, ale jeżeli nowy widok bedzie kozystal z nowej tabeli w db to skad model ma o niej wiedziec, a jak ma stworzyc odpowiednie zapytanie zwracajace odpowioednie dane?

ArticleModel:
- dodaj
- edytuj
- usun
- get title
- get author
- get body



ArticleView:
pobiera z modelu ArticleModel -> get title, get author, get body, formatuje i wyswietla


AddArticleAction:
dodaje za pomoca ArticleModel -> dodaj

W ten sposób mamy obiektowość. Można by było zrobić każdą metodę ArticleModel jako osobny model ale po co??

Co sądzicie?

@ogólnie:

Nie ma sensu zastanawiać się, czy model jest jeden, dwa czy dwadzieścia. Model to tylko warstwa. To tak jakby mieć dwie warstwy bazy danych. Można mieć dwie bazy danych, ale obie należą do warstwy bazy danych. Masłomaślanizm powyższego dowodzi, że mówienie o modelach jest bez sensu.

Ja jestem przeciwny jakiemuś akcentowaniu w nazwach itd. że mamy do czynienia z modelem. Po prostu klasy Article, User, itd. Cała zabawa polega przecież na tym, żeby model był odseparowany od HTTP i innych okropności. Żeby był to ładny, elegancki projekt obiektowy (OOD), bez zawiłości protokołów, sesji, itd. Więc nie żadne $model->getData(), nie żadne metody modelu, tylko po prostu $articleContainer->getArticleById(12345) itd.

A nazywanie klasy ArticleModel jest niekorzystne z tego powodu, że skoro model jest odseparowany od całej reszty, to też nie wie nic o kontrolerze i o MVC. Jak tworzę klasę do artykułów, to nazywam ją Article. Jak tworzę klasę do artykułów w aplikacji MVC, to powinienem postępować tak samo jak poprzednio. W końcu o to chodzi w MVC.

@dag:

To już zagadnienie nie MVC, tylko ogólnie OOD, ale podane przez ciebie metody do Article(Model) są złe. Tzn nie złe z punktu widzenia modelu, tylko złe z punktu widzenia hierarchii klas. Jeżeli są sobie artykuły, to logiczne jest, że potrzebuję klasy Article. Ale potrzebuję też kontenera artykułów. Inaczej się nie da tego sensownie zrobić. Jeżeli mam zbiór artykułów (a przecież mam), to ten zbiór musi być "czymś", czyli musi mieć obiekt. A jak obiekt to i klasa. Kontener. Na tym etapie też robi się tzw. projekt trwałości, czyli po ludzku zaznacza, co siedzi w bazie danych (artykuły). I kontener je wyciąga.

hmm no tak w MVC nigdy nie wnikalem ale teraz moje podstawe pytanie nie odnosi sie w sumie tylko do MVC.

jeden Artykul obrazuje klasa Article powiedzmy

[PHP] pobierz, plaintext 
<?php
 
class Article
{
   var $author, $title, $content;
}
 
?>
[PHP] pobierz, plaintext 

Teraz hawk mowisz o kontenetrze. Czyli on trzyma kolejne instancje klasy Article (czyt. kolejne artykuly). Pytanie on trzyma wszyskie arty czy np. tylko 10 (bo powiedzmy porcjowanie wynikow na www jest co 10 artow). I czy pobieranie do niego danych polega na tym
ze z bazy sql pobieramy wszystkie rekordy, w petli tworzymy kolejne obiekty klasy Article uzupelniajac je danymi a potem wkladamy je w ten kontener. Chyba zle to rozumiem bo to zbyt ergonomiczne nie jest ;]

Zaczynamy od tego, że mamy ten Article tak jak w twoim kodzie. Wyszukiwanie artykułów nie jest zadaniem dla samego artykułu, więc potrzebujesz coś do tego. Kontener. Manager. Jak zwał tak zwał. Nie chodzi o to, żeby ten kontener trzymał 10 czy 100 artykułów, tylko żeby umożliwiał do nich dostęp. A to, że artykuły są w bazie, i że jest jakiś SQL, to jest jego wewnętrzna sprawa.

Pewnie, może sobie wszystkie wczytać i przechowywać, ale to będzie mało wydajne.

Popatrz na to z punktu widzenia MVC. Nie możesz do akcji wrzucić zapytania SQL, które wyciąga artykuły, bo to jest Model. Więc gdzieś to zapytanie musi się znajdować, i to najlepiej w jednym miejscu. Nie może znajdować się w klasie Article, bo musiałbyś stworzyć artykuł a potem go wyciągać - masło maślane. No chyba że w metodzie statycznej, wtedy klasa Article pełni podwójną funkcję. Więc potrzebujesz osobną klasę która potrafi wyciągać artykuły.

Dobrze jest sobie popatrzyć na dostępne systemy DAO, takie jak Turbine/Propel etc. Chociaż tam akurat rozwiązali to poprzez metody statyczne.

hm dzis sobie w szkole myslałem o mvc i narysowałem taki oto "projekt"

1. Kontroler odwołuje się do Router
2. Router parsuje URL i wyciąga z niego nazwe akcji
3. Nazwa akcji jest przekazywana do Kontrolera
4. Kontrole wywołuje akcje
5. Akcja odwołuje się do Modelu
6. Model odwołuje się do DB
7. Model zwraca dane
8. Akcja operuje na danych z Modelu
9. Akcja zwraca przetworzone dane do Kontrolera
10. Kontroler wywołuje Widok
11. Widok zwraca dane do USER_AGENTa

Niech ktoś skoryguje błedy (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

I teraz mam pare pytań:
1. Dotyczy punktów od 9. wzwyż, czy dan są przekazywane przez Kontroler do Widoku czy bezpośrednio z Akcji ?
2. Gdzie są trzymane dane o akcjach ( we Phiendzie w pliku XML, ale jaka jest sensowna alternatywa )
3. Jak są generowane linki (IMG:http://forum.php.pl/style_emoticons/default/dry.gif)
4. Jeżeli dane są przesyłane przez Kontroler do Widoku, to w jakiej formie no przepływają ?
5. Jak sensownie rozwiązać kwestie szablonów ? Wiadomo, że szablon dla artykułów różni się od szablonu forum
6. @hawk skąd ty brałeś informacje (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

1. Ja bym to zrobił tak, że Widok może dostać dane bezpośrednio od Modelu. Tzn normalnie pobiera dane. Pamiętając o tym, że nie wolno mu niczego modyfikować, ale nie da się tego wymusić przez jakieś zabronienie dostępu.

2. Hmm, gdzie? Można w pliku ini. Można w wielkiej tablicy php (np. phrame). Można mieć wszystko hard-coded w kodzie akcji (np. mojavi). Nie widziałem jeszcze sensownego systemu, gdzie to wszystko siedziałoby w bazie danych, ale jest to niegłupie rozwiązanie - ułatwia zarządzanie akcjami.

3. Jak chcesz. To jest niezależne od MVC. Ale po to wymyślałem router, żeby był obiekt odpowiedzialny za tworzenie linków (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

5. -

6. Szablony są niezależne od MVC. Klasa Widoku to w końcu tylko klasa. Jaki szablon ma w środku, to już jej sprawa, i reszcie aplikacji nic do tego.

7. Jestem genialny (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif) . Serio, w sumie to nie wiem. phparchitect. sitepoint. phrame. Polecam też materiały Suna i Microsoftu na temat MVC i takich. Oni to mają trochę lepiej uporządkowane.

A router to wyszedł tak sam z siebie, i nie ma go ani w Javie, ani w .NET.

Ja zazwyczaj komunikację pomiędzy modelem a widokiem sprowadzam do tego, że w akcji pobieram jakieś dane z modelu, które przesyłam do widoku, który je jakoś iteruje i wyświetla.
Skoro jednak w php5 mamy swietną obsługę iteratorów, pozwalającą na pełną symulację tablicy przy pomocy obiektu, to często najlepszym sposobem, jest właśnie pobranie od modelu iteratora (który w sumie również jest częścią modelu) i przesłanie go do widoku.
Oczywiście - dzięki temu zyskujemy nie tylko wydajność - (zamiast przechowywać dane w tablicach, można je "na żywo" pobierać z bazy), ale również upewniamy się, że widok nie będzie nam w żaden sposób 'wpływał' na model.


heh - Ty go tylko ładne nazwałeś (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)
Patern pozwalający na pobieranie nazwy wykonywanej akcji z adresu jest jednak chyba nieco starszy niż phiend...

@DeyV: ale phiend wcale nie ma routera. Ba, nie znam żadnego obecnie funkcjonującego frameworka, który ma router. Owszem, wszędzie przejawia się koncepcja, że z URLa trzeba wyciągnąć nazwę akcji, i jakiś kawałek systemu się tym zajmuje. Niektóre systemy dają tutaj kilka możliwości (index.php?page=foo, index.php/foo, itd). Np. phiend daje kilka możliwości.

Ale nie o to chodzi. Chodzi o to żeby wywalić tą funkcjonalność poza kontroler. Zrobić takie MVCR. I to mi daje dużą elastyczność bo mogę router wymieniać nie ruszając reszty systemu.

A co do wymyślania i nazywania - w sumie to bez znaczenia. I tak nikt routera nie patentuje (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) .

to moze trzeba opatentowac (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) bill ci opatentowal podwojne klikniecie to i my mozemy (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif)

no to już całkiem się zakręciłem (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

jezeli dane są bezpośrednio wysyłane z Modelu do Widoku to jaki sens akcji ?

bela_666 @ przeczytaj dokładnie artykuł o MVC na php.pl.

Akcja to np. dodawania usera, usuwanie artykułu.

Widok wyświetla, jak sama nazwa wskazuje czyli to co widzimy ;-). Wytłumaczone łopatologiczne, tak na chłopski rozum ;-) lepiej masz wszystko opisane w artykule.

przeczytałem, przeanalizowałem i znalazłem błąd (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

z tego co zrozumiałem jezeli dane sie nie zmieniają / są tylko pobierane to akcje nie istnieją, jeżeli są jakies operacje na danych to w gre wchodzą akcje, w drugim miejscu jest napisane że model jest odpowiedzialny za zmiene danych, pogubić się można (IMG:http://forum.php.pl/style_emoticons/default/dry.gif) a wiec jak są rozróżniane zapytania wymagające i nie wymagające akcji ?