Duże strony internetowe MVC, użyj jednego kontrolera ... lub wielu?

Question

Mam dość dużą witrynę i szukam najbardziej efektywnego sposobu zarządzania nią (jestem jedynym programistą).

Próbuję zaprojektować bardzo prostą strukturę MVC (nie chcę używać frameworka), aby zachować cały mój kod w porządku.

W przypadku ogromnej witryny lepiej jest mieć tylko jednego kontrolera do obsługi wszystkich stron, czy lepiej i łatwiej dzielić je?

Jeśli tylko jeden, co jest dobrym przykładem kontrolera innego niż framework?

Answer 1

Chciałbym podzielić dowolne logiczne podziały na różne kontrolery - jeśli to wszystkie strony statyczne, to obsłużę je wszystkimi tymi samymi kontrolerami "statycznej strony".

Jeśli masz kilka stron statycznych, stronę FAQ (lub sekcję), listę produktów - użyj kontrolera dla każdej sekcji. Tak więc statyczne strony byłyby wyciągane z płaskich plików lub bazy danych przez jednego kontrolera, strony z najczęściej zadawanymi pytaniami byłyby generowane z tabeli najczęściej zadawanych pytań przez inny kontroler, produkty i informacje byłyby generowane niezależnie od źródła.

Za każdym razem, gdy generowana jest strona lub dane są dostępne, użyj innego kontrolera.

Oczywiście dziedziczenie klas może być użyte do utworzenia klasy bazowej z kodem wymaganym przez dowolnego kontrolera.

Nie jestem pewien, co rozumiesz przez kontroler inny niż ramowy - chciałbym sprawdzić, czy "Zend", "wzorzec" Zend, wzorzec MVC, a nawet sam kontroler, mogą być używane niezależnie od reszty szkieletu.

Answer 2

Zazwyczaj ludzie dzielą kontrolerów na kontrolerów skupionych na określonych obszarach funkcjonalności.

Następnie umieszczają przed sobą "kontroler przedni", więc istnieje tylko jeden punkt wejścia do aplikacji. Zadaniem pierwszego kontrolera frontowego jest kierowanie przychodzących żądań do odpowiedniego kontrolera.

Zobacz, w jaki sposób jest skonfigurowany komponent Zend_Controller. Może dostarczyć wszystko, czego potrzebujesz, i możesz go używać bez kupowania w pełnym Zend Framework.

Answer 3

To zależy od tego, jak będą działać inne części. Jeśli masz tylko jeden plik modelu, prawdopodobnie nie warto dzielić kontrolera. Jeśli możesz podzielić model na sekcje, a także kontroler, zrób to.

Jednak często stwierdzam, że istnieje zbyt wiele nakładających się na siebie modeli, aby je rozdzielić. Możesz mieć model artykułów, ale jeśli chcesz wyświetlić 20 pierwszych artykułów na pasku bocznym na innych stronach, kod ten powinien znajdować się w modelu artykułu - i będziesz potrzebować tego na każdej stronie.

Szczerze mówiąc, jedynym sposobem na zrobienie tego jest wypróbowanie go i zobaczenie. Zacznij od pojedynczego punktu wejścia, a jeśli będzie zbyt, nieporęczny, zredukuj go na mniejsze fragmenty.

Answer 4

Jeden router/dispatcher, wielu kontrolerów byłoby moją radą. Kontrolery powinny mapować na adresy URL, co oznacza różne funkcje. Kontroler będzie współpracował z różnymi usługami, aby zrealizować każdy przypadek użycia, więc jeden kontroler dla całej aplikacji stałby się zbyt nieporęczny, jeśli twoja aplikacja ma więcej niż kilka przypadków użycia.

Answer 5

Mam tendencję do dzielenia kontrolerów na podstawie ich odpowiedzialności na konkretną sekcję witryny/aplikacji. Dzięki temu utrzymanie kodu jest o wiele łatwiejsze. Ponadto I grupuje kontrolerów (i widoki, modele) w ramach modułów (folderów). Oto przykład z bieżącego projektu pracuję nad:

• Blog
• Posty
• Komentarze
• Kategorie
• Ustawienia
• postów
• Użytkownicy

Im bardziej złożona strona, tym więcej modułów jest używanych. Chociaż większość moich modułów zawiera tylko jeden kontroler "indeksu", podoba mi się organizacja, którą zapewniają.

Następnie używam routera (kontrolera frontowego), który odwzorowuje identyfikator URI stylu REST na odpowiedni moduł/kontroler/akcję. Na przykład: mysite.com/blog/posts/view/7 wywołałoby Controller_Posts :: view (7) z modułu "blog". Dodatkową zaletą korzystania z modułów jest to, że mogę mieć bardziej szczegółowe identyfikatory URI niż wtedy, gdy nie mam modułów. Chociaż przypuszczam, że można to naprawić, używając routera, który obsługuje definiowanie niestandardowych tras, ale nie przepadam za tym.

Tak wiele innych rzeczy sprowadza się do tego, z czym czujesz się wygodnie jako programista, ale prawdopodobnie możemy się zgodzić, że masz więcej organizacji, tym lepiej, jeśli nie komplikujesz się .

Na marginesie, polecam zajrzeć do korzystania z ramy. Rozumiem, jeśli nie chcesz już używać jednego z nich, ponieważ również tego unikałem. Skończyłem pisać własne, które przez ostatni rok służyły mi bardzo dobrze. To było wspaniałe doświadczenie edukacyjne i zawiera tylko to, czego potrzebuje/potrzebuje. Biorąc to pod uwagę, możesz chcieć zajrzeć do Kohany i CakePHP - nie są one zbyt rozdętymi IMO i na pewno zaoszczędzą ci czasu, jeśli zdecydujesz się nie pisać własnego.