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:
Opis poszczególnych katalogów
W najwyższym poziomie znajdują się następujące katalogi:
backend
framework
frontend
backend
console
common
Tutaj znajduje się aplikacja przeznaczona dla administratorów całego systemu.
Katalog w którym znajduje się framework.
Aplikacja widoczna dla użytkownika końcowego.
Tutaj znajduje się aplikacja przeznaczona dla administratorów całego systemu.
Aplikacja udostępniająca możliwość wykonywania zadań w konsoli (np. tworzenie kopii bezpieczeństwa, plików wgranych przez użytkowników, etc. )
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
config
controllers
lib
models
runtime
views
www
Tutaj znajdują się helpery, widżety oraz klasy bazowe danej aplikacji.
W tym folderze trzymamy konfiguracje danej aplikacji.
Tutaj znajdują się pliki kontrolerów.
Biblioteki firm trzecich umieszczamy w tym folderze.
Modele dla naszej aplikacji.
Ten folder jest wymagany przez yii framework
Tutaj znajduje się aktualny szablon dla naszej aplikacji
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.
