Co powinieneś nazwać kontrolerem w MVC? Kiedy powinieneś utworzyć nowy?

Question

Mam pytanie, które naprawdę dotyczy każdej struktury MVC, używam Zend Framework MVC.

Kiedy dokładnie należy utworzyć nowy kontroler? Co dokładnie powinna określać warstwa kontrolera?

Stworzyłem kilka aplikacji z MVC, stopniowo staje się wielokrotnego użytku, ale zawsze zmagałem się z nazwami klas Controller. W większości przypadków pasuje on do żądanych adresów URL, więc logika biznesowa/front-end. Ale w niektórych przypadkach wydaje się całkowicie arbitralne.

Czy ktoś ma jakieś heurystyki/wytyczne do naśladowania? Wygląda na to, że z całym szumem na temat MVC, szczególnie w PHP, niewiele jest danych na temat rzeczywistych konwencji i heurystyki. Ponieważ dość łatwo jest stworzyć zdezorganizowaną aplikację MVC ...

Answer 1

Generalnie mam jeden kontroler dla każdej logicznej grupy funkcji. Często będzie to odpowiadać jednemu sterownikowi na model, czasami nie.

Wyobraź sobie, że tworzysz prosty katalog online, który wyświetla listę kategorii, a następnie, gdy użytkownik wybierze kategorię, wyświetli listę produktów z tej kategorii, wraz z panelem administracyjnym dla CRUD operacji na kategoriach i produktach. Miałem dwa modele (CategoryModel i ProductModel). Miałem kontroler, który generował listy kategorii dla interfejsu i innego kontrolera, który generował listy produktów (np. CategoryController i ProductController). Miałem wtedy kontroler kategorii i produktów na zapleczu (AdminCategoryController i AdminProductController). Dwa kontrolery zaplecza obsługiwałyby operacje list/add/edit/delete/view dla odpowiednich modeli. Jeśli uważasz, że struktura adresu URL i umieścisz powiązane funkcje na powiązanych adresach URL, struktura kontrolera będzie często pasować do struktury adresu URL. W rzeczywistości niektóre frameworki (np. CodeIgniter) żądania trasy oparte na nazwie kontrolera jako zachowanie domyślne.

Jeśli chodzi o to, co dzieje się w kontrolerach, pracuję nad ideą, że modele służą do dostępu do danych i zawijania i ukrywania struktury bazy danych. Logika taka jak "przypisz aktualny czas do zakończenia_pełnienia, gdy status jest ustawiony na" ukończ "" to modele doskonale dopasowane.

Wyświetlenia zawierają całą prezentację. Kontrolery/modele nie powinny generować ani obsługiwać HTML. Decyzje takie jak 2 kolumny lub 3 należą do widoków. Logika w widokach powinna być ograniczona do tej, która jest wymagana do wygenerowania widocznego wyniku. Jeśli chcesz przesłać zapytanie do bazy danych z widoku, prawdopodobnie umieszczasz za dużo logiki w widoku.

Sterowniki są za to, co zostało. Ogólnie oznacza to sprawdzanie danych wejściowych, przypisywanie danych formularzy do modeli, wybór właściwych widoków i tworzenie modeli wymaganych do obsługi żądania.

Answer 2

W przeważającej części śledzę wzór kontrolera na model. Mam kilka kontrolerów, które mogą obsługiwać wiele modeli (takich jak kontroler administratora, który obsługuje kilka modeli administracyjnych), ale ogólną zasadą jest jeden kontroler na model biznesowy.