Organizacja struktury katalogów dla dużych aplikacji

Ostatnimi czasy rozpocząłem tworzenie bardzo dużego projektu. W trakcie rozwoju oraz dodawaniu coraz to nowszych ficzersów wystąpił problem z organizacją hierarchii katalogów. Aplikacja nie miała wyraźnego podziału na część dla użytkownika bądź administratora. Dodatkowo w przyszłości cały system miał zostać rozbudowany o API oparte o protokół XML, a do prac nad nim miały dołączyć kolejne 2 osoby. Po dłuższych przeszukiwaniach w sieci i głębszej analizie struktur kilku aplikacji natrafiłem na artykuł, który po drobnych modyfikacjach oraz testach rozwiązał mój problem. Zapraszam do czytania!

Artykuł ku mojemu zdziwieniu został opublikowany na wikipedii framework’u Yii . Chciałbym zaznaczyć, że taka struktura katalogów jest zbyt skomplikowana dla małych projektów – w innym wpisie przedstawię strukturę dla mniejszych aplikacji. Natomiast poniższa hierarchia dobrze sprawdzi się w średnich oraz dużych projektach.
Główne katalogi w projekcie

Poniżej znajduje się listing z katalogu mojego projektu:

6-struktura-katalogow-yii-framework

Opis poszczególnych katalogów

W najwyższym poziomie znajdują się następujące katalogi:
backend Tutaj znajduje się aplikacja przeznaczona dla administratorów całego systemu.Katalog    Co w nim się znajduje
framework    Katalog w którym znajduje się framework.

frontend    Aplikacja widoczna dla użytkownika końcowego.
backend    Tutaj znajduje się aplikacja przeznaczona dla administratorów całego systemu.
console    Aplikacja udostępniająca możliwość wykonywania zadań w konsoli (np. tworzenie kopii bezpieczeństwa, plików wgranych przez użytkowników, etc. )
common    Katalog, który jest współdzielony z innymi aplikacjami znajdują się tutaj modele, widżety, klasy bazowe etc. )

Jak widzisz, podzieliliśmy cały system na mniejsze aplikacje: backend, frontend oraz console. Jeżeli istnieje taka potrzeba to dodajemy więcej aplikacji (np. web-api, sms-api etc.). Folder common służy do przechowywania plików współdzielonych przez wszystkie nasze aplikacje.

Katalogi aplikacji

Struktura katalogów jest prawie identyczna dla każdej aplikacji. Frontend oraz Backend mają identyczna strukturę katalogów ponieważ w tym przypadku są to aplikacje przeglądarkowe. Katalog    Co w nim się znajduje
components    Tutaj znajdują się helpery, widżety oraz klasy bazowe danej aplikacji.
config    W tym folderze trzymamy konfiguracje danej aplikacji.
controllers    Tutaj znajdują się pliki kontrolerów.
lib    Biblioteki firm trzecich umieszczamy w tym folderze.
models    Modele dla naszej aplikacji.
runtime    Ten folder jest wymagany przez yii framework
views    Tutaj znajduje się aktualny szablon dla naszej aplikacji
www    Główny katalog aplikacji

Struktura katalogów dla console jest troszkę inna, a mianowicie nie potrzebujemy folderów controllers, views oraz www. Zamiast nich będzie folder commands, w którym przetrzymujemy wszystkie pliki poleceń.

Katalog Common

W katalogu common przechowujemy elementy dostępne dla całego projektu. Przykładowo, każda z naszych aplikacji wymaga dostępu do bazy danych, dlatego w tym katalogu możemy przetrzymywać modele ActiveRecord lub formularze dostępne dla całej aplikacji. Podobnie jeżeli jakiś widżet albo helper są używane w więcej niż jednej aplikacji powinniśmy umieścić je w tym folderze, aby uniknąć powielania kodu.

W celu ułatwienia obsługi kodu struktura katalogu common będzie podobna do struktury aplikacji. Na przykład, mamy foldery components, models, lib, etc. Konfiguracja aplikacji trzymana jest w podfolderze config .

Kiedy rozwijamy duży projekt z długim czasem rozwoju, potrzebujemy mieć stale aktualną strukturę bazy danych. Dlatego, będziemy używać „migration” do śledzenia zmian w bazie danych. Przetrzymujemy wszystkie pliki migracji w podfolderze migrations.

Konfiguracja aplikacji

Aplikacje tego samego systemu wszystkie używają podstawowej konfiguracji, przykładowo konfiguracji bazy danych, parametry aplikacji i tym podobne. W celu eliminowania powtarzania kodu powinniśmy podstawową konfiguracje przenieść w centralne miejsce – do folderu config w katalogu common.

Kiedy nasza praca jest zorganizowana w drużynach, każdy programista może posiadać inne środowisko ( system operacyjny, konfiguracje bazy danych). Prawie zawsze środowisko programisty różni się do środowiska produkcyjnego. W celu uniknięcia konfliktów w konfiguracjach podzieliliśmy konfiguracje na dwie części: Podstawowa konfiguracja ( main.php, params.php) oraz lokalna konfiguracja (e.g. main-local.php, params-local.php).

Podstawowa konfiguracja powinna być włączona do systemu kontroli wersji, ponieważ powinna być współdzielona przez wszystkich developerów. Lokalna konfiguracja nie powinna być zapisywana w żadnym systemie kontroli wersji. Programista posiada w ten sposób pełną swobodę do modyfikacji swojej lokalnej konfiguracji.

Wdrożenie

Podczas rozwoju lub zakończenia projektu, musimy wdrożyć go na serwerze produkcyjnym. Zamiast wysyłać pliki na serwer za pomocą protokołu FTP, możemy używać systemu kontroli wersji do tego celu. Możemy traktować serwer produkcyjny jako specjalnego dewelopera, który ma serwer produkcyjny jako swoje środowisko programistyczne.

Najpierw pobieramy nową bądź aktualizujemy istniejącą kopię z systemu kontroli wersji do wybranej lokalizacji na serwerze produkcyjnym. Następnie tworzymy lub modyfikujemy lokalną konfiguracje na specyficzną dla serwera produkcyjnego. Przykładem może być ustawienie parametrów połączenia do bazy danych.

Ponieważ przechowujemy każdą aplikacje naszego systemu w oddzielnym katalogu, możemy wdrażać je na różne serwery.

Jeżeli macie pytania, bądź znacie lepsze rozwiązanie zapraszam do komentowania tego wpisu.

Comments

comments

Comments

Leave a Reply

You must be logged in to post a comment.