W systemie MVC tylko modele powinny być obietami - do takich wniosków doszedłem. Czy słusznie ?

skad taki wniosek?

Nie, nie słusznie. Zazwyczaj w MVC wszystko jest oparte na klasach, popatrz choćby na Zend Framework.

Modele bardzo łatwo przedstawić za pomocą obiuektów dlatego świetnie się do tego nadają.
Widoki to poprostu powinny być pliki .phtm dlatego z obiektowośćią nie mogą mieć nic wspólnego.
Próby opakowania kontrolera w obiekt są wymuszone.

Przykłąd:
Klient zleca nam dobudowanie kalendarza w storpce strony. Kalendarz powinien się pokazywać w parzyste dni miesiąca, przy czym dla każdej wersji językowej musi mieć inny szablon kolorystyczny.

Rozwiązanie:
Jeden z modeli to komponent "kalendarz". Łatwo stworzyć obiekt Calendar- jest to naturalne.
Widok to plik .phtml który wykorzystuje dane z modelu np "BlueCalendar.phtml".
Kontroler powinien zająć się sprawdzaniem czy dziń jest parzysty, no i dla wersji jezykowej ładować odpowiedni szablon.

Moje pytanie:
Dlaczego miałbym pakować kontroler w obiekt? Czy nie wydaje się wam to wymuszone skoto kontroler to tak naprawdę tylko "switch"? Taki switch o nazwie "CalendarController.php" Powinien być poprostu includowany gdzieś na stronie.

nie tylko switch. Aplikacja wybiera kontroler, a kontroler wybiera jakie skladniki bedą mu potrzebne. Pomysl ze chcesz zrobić dodawanie użytkownika i w nim wybór grupy z bazy danych

[PHP] pobierz, plaintext 
<?php
class Controller {
publuic function adduserForm()
{
$oCal = $this->modelGroup('getAllGroups');
$this->viewUser('addUser', $oCal);
}
}
?>
[PHP] pobierz, plaintext 

:]

Dzis pierwszy kwietnia ?

NuLL, piątek trzynastego, dlatego takie pechowe myslenie

[PHP] pobierz, plaintext 
<?php
switch ($_GET['form']) {
   case 'add_user':
          $data = $user->authorization->getUserGrouops();
          include 'Forms/AddUserForm.phtml';
          $data = null;
       break;
}
?>
[PHP] pobierz, plaintext 

To ja może taką złotą myśl co usłyszałem niedawno od człowieka, który zajmuje się tworzeniem bardzo rozbudowanych aplikacji:

Łączenie kodu obiektowego i strukturalnego jest jak zabawa z plastikową lalką - do pewnego wieku (poziomu doświadczenia) to rzecz normalna, potem zaczyna to być chore i zboczone.

Rzecz w tym, że z czasem liczy się przede wszystkim prędkość rozwoju aplikacji i jej utrzymania (sprzęt zawsze można dokupić - jest on tańszy niż praca profesjonalisty), a programowanie obiektowe potrafi znacznie przyśpieszyć tworzenie aplikacji (kod strukturalny jest ciężki w utrzymaniu kiedy się rozrośnie). Dlatego też warto ograniczać ilość kodu strukturalnego do niezbędnego minimum.


---- edit ----

Wiesz Black-Berry, kod który podałeś wydaje się brzydszy i mnie czytelny niż gdybyś go zawarł obiektowo w klasie.

Tak, tylko zwróć uwagę że w przypadku Web Developerki nie robi się 1 duzego projektu ale raczej dużo małych i czesto. Jeśli struktury obiektowe są ze sobą sztywno powiązane to za rok kiedy zadzwonią do Ciebie i każdą dodać jakiś plugin to może się okazać że przez ten sztywny projekt dodałeś sobie zbędnej pracy.


Ale zgodzisz się chyba że kontrolery działają strukturalnie? Zwykłe przełaczniki. Dla mnie brzydkie wydaje się ukrywanie tego.

black-Berry teraz żeby skontrolować np. uruchamiane akcje musisz dopisać np. kolejną zmienną.

Skąd masz zmienną $user? Ja metodą call, pobieram co wywolac, odczytuje jaki model/widok i jaką metodę. Mam łatwy dostep do bazy danych dziedzicząc z Syd_Application_Action (u mnie nazywa sie to action), gdzie ustawione są wszystkie motedy

[PHP] pobierz, plaintext 
<?php
class Action_User extends Syd_Application_Action
{
public function addUserForm()
{
$sLink = $this->url('Article/view?name=FAQ'); //stworzy urla <a href=\"http://site.com/doc/faq/\" target=\"_blank\">http://site.com/doc/faq/</a>
$this->oDb->Update();
$this->oDb->Insert();
$this->oDb->getRow();
$this->oDb->getAll(); // caly dostpe do bazy
 
if($this->getIsset('test'))
{
echo $this->getString('test');
}
 
$int = $this->getInt('id');
 
$this->forward('Index'); //header location
 
if($this->check())
{
echo formularz napisany poprawnie; // a w viewie <input error="noempty" type="text" name="test" />
}
}
}
?>
[PHP] pobierz, plaintext 

Teraz przenieś to do swoich switchów

EDIT:
Tak wiem, model ma dostep do Db, ale ja rozdzielilem Update, Insert do akcji a pobieranie do Modelu. Najwazniejsze to $this->check(); oraz getInts/String itd. ;]

Programuję w PHP'ie od 2003 roku, jeden projekt do dziś dnia u klienta aktualizuję. Błędem było napisanie go strukturalnie bo rozbudowa jego byłaby o wiele prostsza jakby był obiektowo napisany (fakt, że wtedy obiektowość w PHP kulała).

Dziś nie piszę dużo małych projektów, za to mam na utrzymaniu cztery duże i to mi wystarczy by żyć na odpowiednim poziomie i mieć sporo czasu dla siebie.

--- edit ----

Jeśli dla Ciebie kontroler to zwykły przełącznik to znaczy, że w ogóle nie potrzebujesz obiektów do niczego. U mnie kontroler robi bardzo dużo, i zapisanie tego strukturalnie było masochizmem zamierzonym

Dążę do tego żeby kontroler robił jak najmniej - żeby był tą częścią aplikacji której nie da się upakować w żaden poziom abstrakcji.

@bim2 Masz chyba podobne podejście do Kocurro. Kontrolery robią u Ciebie dużo. W moim przypadku dodawaniem np usera zajmuje się model - $user->manager->addAccout($args). Nie bardzo rozumiem przykąłd jaki podałeś. Dlaczego metoda addUserForm() miałaby tworzyć url do FAQ? Jeśli formularz miałby mieć w stopce link do FAQ to moim zdaniem powinno być to zawarte w widoku. Nie wydaje mi się też aby musiały istnieć procedury generujące linki. Próbuję tak ustawić .htaccess'a aby było to zbędne.

@Black-Berry, ja Ciebie tego nie uczyłem Skąd ty wyciągnąłeś takie brednie.
Czemu uważasz, że np. widok nie powinien być obiektem? Przecież widok też posiada swoją wewnętrzną logikę, której w funkcje nie opakujesz... musi być obiekt. Spójrz chociażby na agavi, którzy obiektowść widoku bardzo uwypuklili: Creating Actions and Views

Nie powinieneś również mylić szablonów z widokiem. To dwie różne rzeczy. Widok korzysta z szablonów i zależnie jaki to widok, to jako szablony możesz użyć plików PHP, Smarty, XSLT etc.

@kocurro, wbrew pozorom kontroler dużo robić nie powinien. Istnieje taka zasada

Kontroler nie znajduje się w tzw warstwie dziedziny (domain layer) i odpowiada raczej, za workflow aplikacji.

Pozdrawiam

LBO: A co według Ciebie jest dużo ?

Uwierzytelniania, autoryzacja, routing, ładowanie modułów, obsługa błędów, obsługa wywołania akcji, obsługa łańcucha wywołań, obsługa cache'u jeśli jest używany - to jest mało ? To są zadania kontrolera (chociaż fakt niektóre są dzielone z modelami ale to głównie kontroler musi robić).

To jest workflow aplikacji. O ile uwierzytelnianie i autoryzacji częściowo przeniesiona może być do modelu to jednak nie w całości.

Dla mnie to jest właśnie bardzo dużo roboty. Fakt jeśli wziąć w garść wszystkie modele to one wykonują o wiele więcej roboty, jeśli jeszcze dołożyć do tego widoki to okazuje się, że faktycznie kontroler robi mniej niż procent. Ale czasem dwa promile mogą przesądzić o wszystkim.

I jak chcesz to wszystko zapisać na switchach ? Bo dla mnie zapisanie tych wszystkich rzeczy, zależności tylko i wyłącznie na switchach byłoby masochizmem.

pozdr.
Łukasz

Na switchach można oprzeć projekt gdy jest mały, a poszczególne kontrolery nie są ze sobą ściśle powiązane. Sam tak robiłem, szło nieźle, ale przekonała mnie łatwość modyfikacji kodu opartego na kontrolerze obiektowym i akcjach w jego metodach, bo nie musiałem dla każdego kontrolera dodawać oddzielnych linijek kodu w switchu, a w samym kontrolerze wybierać odpowiedniej akcji, a teraz zaczynam powoli wykorzystywać inne możliwości takiego kodu .

Może trochę inaczej.
Powszechnie za nazwa "kontroler" zamiennie używana jest z "akcją" i taką nomenklaturę przyjąłem.
Zgadzam się z tym co napisałeś, kontroler posiada pewne obowiązki, które spełniać musi (ale nie wszystkie, które wymieniłeś. O tym za chwilę). Zasada, która podałem odnosi się bardziej do operacji biznesowych, które niekiedy w całości przenoszone są do kontrolera/akcji (wystarczy przejrzeć nawet kilka postów na forum dot. ZF ).

Co do deto co napisałeś o uwierzytelnianiu, cache'u routingu - nie są one częścią kontrolera. Poczytaj o wzorcu Intercepting Filter lub nawet obejrzyj, chociażby w sf, albo Agavi (w Agavi implementacja jest dużo lepsza IMHO).

Pozdrawiam

P.S. Ja o żadnym switchu nie pisałem wogóle się do Tego nie odnosiłem, bo jest śmieszne

Dzięki za wszystkie posty. Przynjamniej moje intuicyjne założenie żeby maksymalnie ograniczyć kontolery było słuszne. Nie opakowuję ich w obiekty tylko inkludowane pliki bo jest szybciej. Dzieki temu nie musze przekazywać kontekstu, pobierać go, bawić się w opakowywanie metod.

@LBO Faktycznie chyba źle rozróżniam widok od szablonu dzięki za naprostowanie.

Nadal uważam, że źle robisz.... zobaczymy jak dojdziesz do takiego etapu kariery, że będziesz musiał testować kod

Może masz rację ale bez eksperymentów nei ma postępu ... Liczę na to że kontrolery okroję do max 10 małych plików a wtedy może nie będzie tak źle. Obecnie mam:

RoutingController.php
PostController.php
ActionController.php
BodyController.php

Zawierają tylko switche. Z tego co zauważyłem nie zapowiada się aby było ich potrzebnych wiele więcej. Reszta to modele.

nie myl eksperymetów z wymyslaniem koła na nowo....

moim zdaniem controller powienien być klasą, wtedy jest łatwiej wszystkim zarządzać, mamy moduły, które mają odpowiednie akcje i wykonują odpowiednie zadania, mamy możliwość dekoracji, o stale wykonujące się zadania itp.

No i to jest dobry cytat bo bywa tak że kontorlery pasują do obiektów jak koło od karocy do bolidu F1 Zależy od frameworka.... Zrestą sam już nie wiem. Może poprostu mam mniejszą aplikację i dlatego nie mogę tego wepchnąć w klasy. Rozrośnie się albo nie sprawdzi to zmienię.

Rozumiem że nikt się nie zgadza z moją tezą ?

nikt

I to mnie właśnie dziwnie zastanawia. Zazwyczaj było tak że jak się ktoś ze mną nie zgadzał na Forum to wiedziałem że może mieć rację bo mój kod był do bani i nie działał za dobrze. Tym razem jednak wszystko działa bardzo dobrze dlatego coś jest nie tak jak powinno:D Pewnie okaże się że za pół roku przyjdzie mi pisać wszysko od nowa...

Ale nie ma źle. Zostaną mi chociaż modele

Dzieki za wszystkie posty i pozdrawiam.

Potwierdzam. Podejście do bani.
Kod nie musi się wywalać żeby był do bani. Działające rzeczy też potrafią być do bani.

życie jest do bani, o tym zapomniałeś