Jak organizujesz swoją platformę MVC, wspierając moduły / wtyczki? [Zamknięte]

Istnieją dwie główne struktury baz kodu, które widziałem, jeśli chodzi o frameworki MVC. Problem polega na tym, że oba wydają się mieć błąd organizacyjny, który im towarzyszy.

Standardowy MVC

/controller
/model
/view

Problem: Brak separacji powiązanych elementów (forum, blog, użytkownik itp.)

Modułowy MVC

/blog
    /controller
    /model
    /view
/user
    /controller
    /model
    /view
/forum
    /controller
    /model
    /view

Wybór systemu opartego na modułach pozostawia problem.

• Długie nazwy (Forum_Model_Forum = forum / model / forum.php) (jak Zend)
• System plików wyszukuje za pomocą, is_file()aby znaleźć, który folder ma model forum? (Jak Kohana)

Czy mają jakieś inne struktury MVC, które działają dobrze podczas próby oddzielenia różnych modułów? Czy brakuje mi tych struktur?

Próbować:

/blog 
    /controller
    /view
/user
   /controller
    /view 
/forum
    /controller
    /view
/model
    User
    BlogPost
    Comment
    ....

Twoje modele są sercem Twojej aplikacji. Powinieneś zaprojektować i zakodować je jako samodzielny pakiet. Kontrolery są tylko klientami twojego modelu, które przekształcają aktywność użytkownika w działania dla twojego modelu. Widok jest tylko jednym szczególnym sposobem wyświetlania danych z twojego modelu. Jeśli Twoja aplikacja rośnie, możesz jeszcze bardziej oddzielić klientów od modelu:

WebClient
    /blog 
        /controller
        /view
    /user
       /controller
        /view 
    /forum
        /controller
        /view
CommandLineClient
    delete_spam_posts_script
RestApiClient

/model
    User
    BlogPost
    Comment
    ....

To powinno sprawić, że oczywistym będzie, że możesz mieć wielu klientów, którzy w ten czy inny sposób wchodzą w interakcje z jednym modelem.

;)

Znalazłem najlepszą strukturę dla MVC / HMVC Framework. Do głównego musisz użyć kontrolerów bazowych / modeli / widoków ... ale dla poszczególnych elementów modułów kursu ...

Więc w mojej strukturze frameworka MVC / HMVC wygląda to tak:

/application
  controllers/
  models/
  views/
  modules/
    blog/
      controllers/
      models/
      views/ 
    user/
      controllers/
      models/
      views/
    forum/
      controllers/
      models/
      views/

Również w razie potrzeby dodam biblioteki modułów, i18n lub pomocników.

Konwencja nazewnictwa jest łatwa, do kontrolerów i modeli dodam przyrostek _Controller i _Model. Do kontrolerów i modeli z modułów dodaję także przedrostek z nazwą modułu, np. Profil kontrolera w module Użytkownik zostanie nazwany jako User_Profile_Controller.

Więc bardzo łatwo i szybko znajdziesz to, czego potrzebujesz.

Problem: Długie nazwy (Forum_Model_Forum)

Systematyczne nazywanie klas pomaga uniknąć konfliktów nazw między komponentami. Długie nazewnictwo klas raczej nie nakłada surowych kar za wydajność. Uważam, że ten schemat nazewnictwa jest raczej pomocny podczas kodowania, ponieważ łatwo jest zobaczyć, skąd pochodzi.

wyszukiwania w systemie plików (który folder ma model forum?).

To bardzo zależy od tego, jak system został zaimplementowany, ale struktura systemu plików zwykle jest zgodna z konwencją, która pozwala na natychmiastowy dostęp do właściwego komponentu bez rozległych wyszukiwań systemu plików.

Oto przykład, załóżmy, że należy użyć komponentu forum:

Informacje:

• Nazwa komponentu: forum

• Nazwa kontrolera: indeks

  $ ścieżka_kontrolera = BASEDIR. „moduł /”. $ nazwa_komponentu. '/kontroler/' . $ nazwa_kontrolera. „.php”;

Należy również zauważyć, że podczas uruchamiania typowej witryny internetowej istnieją dosłownie setki zapytań dotyczących systemu plików, więc dodanie niektórych nie zaszkodzi.

Pracuję ze stronami internetowymi, które zaczęły się od pierwszego „Standardowego MVC”, ale ostatecznie stały się „Modularnym MVC”.

Jeśli prowadzisz małą stronę internetową i nie masz dużego doświadczenia, możesz zacząć od „Standardowego MVC”. Jeśli już wiesz, że strona internetowa będzie bardzo złożona i duża, musisz przyzwyczaić się do „Modular MVC”, na początku będzie to trochę trudne, ale ostatecznie przyzwyczaisz się do to.

Właściwie sam pracuję nad frameworkiem i używam kombinacji zarówno struktury katalogów opartej na modułach, jak i swobodnych. Moja domyślna struktura kodu witryny przy użyciu frameworka to:

/Configuration (stored a bunch ini files for security related information like passwords)
/Functions (stores file(s) with standard procedural functions)
/Libraries (general use classes)
/Models (all models go here)
/Modules (each module refers to one controller
/Modules/Site (controller class store in this folder if there is a controller)
/Modules/Site/Views (views for the controller)

Możesz także mieć folder modułu, który nie odnosi się do kontrolera, i domyślnie istnieje jeden moduł wywoływania Core, który służy do przechowywania szablonów w całej witrynie, takich jak nagłówek i stopka. To dla mnie daje to, co najlepsze z obu światów. Możesz łatwo dowiedzieć się, gdzie jest kontroler, ponieważ jest jeden kontroler na folder, ale w przypadku klas takich jak modele nie musisz szukać, gdzie znajdują się pliki, ponieważ znajdują się w jednym katalogu (dzięki czemu nazwy modeli są czystsze) .

Sposób ładowania plików jest nieco inny, ponieważ pozwalam użytkownikowi konfigurować różne katalogi, w których mogą znajdować się klasy, więc wstępnie analizuję katalogi i przechowuję wszystkie lokalizacje plików klas w pliku json, a następnie używam tego do szybkiego wyszukiwania wszystkie inne prośby (chociaż szukam sposobów, aby to poprawić).

Odpowiedź na to pytanie podyktowała propozycja PSR-0 którą wszystkie duże systemy zaczynają dostosowywać lub już przyjęły.

Struktura jest:

\Doctrine\Common\IsolatedClassLoader => /Doctrine/Common/IsolatedClassLoader.php
\Symfony\Core\Request => /Symfony/Core/Request.php
\Zend\Acl => /Zend/Acl.php
\Zend\Mail\Message => /Zend/Mail/Message.php

Oznacza to, że nie można nic zrobić, aby naprawić długie nazwy plików:

$controller = new \Blog\Controller\Archive => /Blog/Controller/Archive.php

/Blog
    /Controller
        Archive.php
    /Model
    /View
/User
    /Controller
    /Model
    /View
/Forum
    /Controller
    /Model
    /View

Oznacza to również, że musisz używać niemych plików wielkimi i małymi literami zamiast wszystkich małych liter (jeśli nie, biblioteki innych firm nie będą działać).

Rozwiązanie Mathiases ma sens. Użycie jego struktury folderów nie zapobiega zawartości, którą można podłączyć, na przykład dodanie niezależnej / galerii / mogłoby wyglądać następująco

WebClient
    /blog 
        /controller
        /view
    /user (uses /model/User/)
       /controller
        /view 
    /forum
        /controller
        /view
    /gallery
        /controller
        /view
        /model
CommandLineClient
    delete_spam_posts_script
RestApiClient

/model
    User
    BlogPost
    Comment

Teraz mamy wspólny „model” i niezależne, jeśli to konieczne