W ramach MVC, jakiej struktury katalogów oczekiwaliby inni deweloperzy?

Question

Generalnie frameeworks MVC mają strukturę, która wygląda mniej więcej tak:

/models 
/views 
/controllers 
/utils 

Jednak w apartamencie aplikacji internetowych, zdecydowałem, że zbicie wszystkich modeli, widoków i kontrolerów razem prawdopodobnie nie byłby najlepszy dla jasności, chyba że potraktowałem system jako jedną aplikację zamiast pakietu aplikacji. Jednak niektóre rzeczy wiążą każdą "aplikację" ze sobą, podobnie jak pojęcie użytkowników i ról użytkowników.

Więc mam trzy możliwe rozwiązania:

(1) Czy to, co tak naprawdę nie chcą robić, i zachować każdy model, widok i kontroler razem, z których niezależnie app należy. To traktuje pakiet jako pojedynczą aplikację, ponieważ są one powiązane przez kilka wspólnych wątków, w tym użytkowników.

(2) Pogrupuj kod według aplikacji.

/app1 
    /models 
    /views 
    /controllers 
    /utils 
/app2 
    /models 
    /views 
    /controllers 
    /utils 

(3) Pogrupuj kod według typu, umożliwiając udostępnienie kodu użyteczności dla wszystkich aplikacji.

/models 
    /app1 
    /app2 
/views 
    /app1 
    /app2 
/controllers 
    /app1 
    /app2 
/utils 

Czy istnieje opcja, którą przegapiłem? Jaki byłby najbardziej logiczny schemat dla przyszłych programistów? Osobiście wolę 2 i 3, ale być może większość ludzi oczekiwałaby 1.

Answer 1

Wygląda na to, że 2) byłoby najlepszym rozwiązaniem, zakładając, że chcesz mieć kilka separacji aplikacji. Możesz także mieć folder "/ common" na poziomie "/ app #" dla współdzielonych zasobów we wszystkich aplikacjach ... takich jak wspólna klasa narzędziowa lub cokolwiek innego.

Answer 2

Jeśli Twoje aplikacje udostępniają dane, może to oznaczać (dla mnie) zgrupowanie modeli razem.

Jednak w przypadku widoków i kontrolerów prawdopodobnie bardziej sensownym rozwiązaniem będzie ich oddzielenie, ponieważ zakładam, że mają oddzielną logikę biznesową i prezentacje.

Co więcej, jeśli twoje aplikacje są przechowywane osobno w kontroli wersji (korzystasz z kontroli wersji, prawda? :), co utrudnia implementację pierwszej lub trzeciej opcji.

Podsumowując, prawdopodobnie oddzielę aplikacje na najwyższym poziomie, tak jak w drugim przykładzie.

Answer 3

Zazwyczaj grupuję kod według funkcji, więc w twoim przypadku grupowanie według aplikacji będzie dla mnie najbardziej sensowne. Powodem jest to, że jeśli chcę pracować nad konkretną funkcją, nie powinienem przeszukiwać trzech oddzielnych folderów szukających potrzebnych składników. Jeśli pogrupujesz według funkcji wysokiego poziomu, wiesz wszystko, czego potrzebujesz, jest razem.

Answer 4

2 to dobry początek. Powinieneś rozważyć posiadanie wspólnego folderu, w którym możesz przechowywać wszystkie popularne modele, widoki i narzędzia używane przez wszystkie aplikacje w pakiecie aplikacji.

/app1 
    /models 
    /views 
    /controllers 
    /utils 
/app2 
    /models 
    /views 
    /controllers 
    /utils 
/common 
    /models 
    /views 
    /utils