Wypróbuj

Nozbe - get things done

i zwiększ swoją produktywność

Dobra struktura projektu AngularJS

4

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):

Struktura projektu AngularJS

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.

CHCESZ DARMOWEGO E-BOOKA?

Jeśli chcesz otrzymać mojego e-booka: Rozmowa Kwalifikacyjna - pytania z podstaw JavaScript zostaw mi swój e-mail:

Oprócz tego co poniedziałek dostaniesz maila z listą moich wpisów z poprzedniego tygodnia!

  • Miro

    Ale się zlożyło, 3 dni temu oglądałem na YT 10 najlepszych praktyk w angular js wg johna papy a dzisiaj czytam ten art.

  • Qba

    Hej,
    Ciekawe podejście, musze je wypróbować w swoim projekcie, bo latanie miedzy folderem controllers -> models -> views w juz średnio dużym projekcie stalo się uporczywe.

    Powiedz mi co myślisz o angularze? Jak się sprawdza w dużych projektach? Ciagle słysze dużo krytyki na temat angulara że na dużę projekty jest zły, że powstaje wersja 2.0 zupelnie nie kompatyblina z 1.* i takie tam.

    Wydaje mi się że angular bije na głowę inne frameworki popularnością i elastycznością. A co do angulara 2.0, trzeba będzie sie dostosować technologię ciągle się zmieniaja 😀

    • Bartłomiej Dybowski

      No wlasnie zdania sa podzielone – osobiscie mam jak na razie wieksze doswiadczenie z knockoutjs ale z tego co widze to angular wydaje sie byc stworzony do duzych projektow. Nie wiem jednak jak jest z wydajnoscia – byc moze tutaj jest pies pogrzebany bo chyba z takimi glosami tez sie spotkalem.

    • piotrek

      a po co tak? W każdym IDE istnieje ficzer, dzięki któremu można wpisać nazwę pliku i go otworzyć bez latania po folderach 😉