Dobra struktura projektu AngularJS

Myślę, że wiele osób po raz pierwszy siadających do projektu opartego na frameworku AngularJS może zadawać sobie tytułowe pytanie: jaka struktura projektu AngularJS będzie odpowiednia? Nie inaczej było w moim przypadku, na szczęście kolega natknął się i polecił mi szkolenie na Pluralsight, które wiele mi rozjaśniło dzięki czemu mam teraz na ten temat jako taki pogląd i dziś właśnie podzielę się nim z Wami. Autorem tego szkolenia jest John Papa, a dla tych z Was, którzy posiadacie dostęp do serwisu Pluralsight tutaj link do rzeczonego szkolenia. No ale przejdźmy do rzeczy.

Typ czy funkcja?

No więc… Zanim zaczniemy organizować nasz projekt, powinniśmy się zastanowić wedle czego chcemy grupować poszczególne pliki. Generalnie mamy wybór między dwoma opcjami. Pierwsza opcja to grupowanie modułów według ich typu. Takie rozwiązanie od razu nasuwa się każdemu programiście .NET, który miał co nieco do czynienia z ASP.NET MVC - tam mamy właśnie takie podejście, a więc wszystkie kontrolery w katalogu Controllers, widoki we Views, modele w Models _itd._ Jak się pewnie już domyślacie, takie podejście nie jest idealne i sprawdza się raczej w mniejszych projektach gdzie z góry wiemy, że tych kontrolerów, widoków czy modeli nie będzie aż tak dużo aby powstał bałagan (w ASP.NET MVC mamy to niejako narzucone i myślę, że większość z nas wie jak potrafi wyglądać taki przeładowany funkcjami projekt).

A gdyby zrobić to inaczej? Przecież z punktu widzenia interfejsu użytkownika aplikacja podzielona jest na obszary funkcjonalne. Tym obszarom odpowiada zwykle jeden kontroler, kilka widoków powiązanych z akcjami kontrolera oraz kilka modeli. Dlaczego więc nie podzielić ich w ten sposób? Otóż w świecie AngularJS jest to właśnie zalecane podejście!

Struktura projektu AngularJS oparta na funkcjonalnościach

Ok, wiemy już, że lepiej jest organizować projekt AngularJS w oparciu o poszczególne funkcjonalności aplikacji. Jednak jak to wygląda w praktyce? Poniżej przykład tego jak ja to zrobiłem w jednym z projektów (oczywiście to tylko zdjęcie poglądowe):

Zwróćcie uwagę na lewą stronę - widzimy tam katalog app, który jest głównym katalogiem dla naszego projektu AngularJS. Jak widać, zawiera on katalogi takie jak accounts, demo, login i register. Są to foldery odpowiadające właśnie konkretnym funkcjom aplikacji. W ich wnętrzu znajdują się zarówno pliki *.js (w tym przypadku odpowiedzialne za kontrolery oraz definicje modułów) jak i pliki *.html będące szablonami wyświetlanymi przez dany kontroler. W ten sposób mamy w jednym miejscu wszystkie pliki odpowiedzialne za daną funkcjonalność.

Oczywiście, są też pliki wykorzystywane przez wiele komponentów. Te znajdują się w osobnym katalogu common i są w nim podzielone na podkatalogi odpowiadające ich funkcjom.

Dzięki takiemu podziałowi projektu, znacznie upraszczamy sobie proces implementacji poszczególnych funkcji systemu nawet jeśli wzrośnie on do znacznych rozmiarów. W opisany sposób łatwiej uzyskuje się także, separację odpowiedzialności (ang. separation of concerns) - w końcu takie podejście wymusza na nas takie dzieleni kodu aby rzeczywiście pojedyncza funkcjonalność znajdowała się w jednym kontrolerze, a co za tym idzie w jednym pliku. To skutkuje też tym, że po prostu łatwiej nam jest lokalizować kod odpowiedzialny za dane zadanie.

Czy to jedyne słuszne podejście?

Jasne, że nie! To co dziś pokazałem, to tylko wyznaczenie kierunku w jakim dobrze jest pójść. Nie narzucam sztywnego trzymania się przedstawionego układu katalogów itp. Przy bardzo dużych aplikacjach, zapewne dobrym pomysłem byłoby podzielenie pojedynczych funkcji na podgrupy jeśli w jakiś sposób są ze sobą powiązane. Myślę jednak, że dobra struktura projektu AngularJS (zresztą to się tyczy też innych projektów) to istotna kwestia. Warto od początku tworzenia pierwszych funkcjonalności zadbać o taką strukturę projektu aby nie było problemów gdy aplikacja się rozrośnie.