Archiwum
Organizacja projektu – RobotLegs/MVC+
Ostatnie miesiące skłoniły mnie do ponownego rozważenia tego wydawałoby się trywialnego problemu, zacząłem doceniać jak dobrze zorganizowany projekt czy przemyślany układ katalogów może ułatwić programiście życie. Już kiedyś poruszałem to zagadnienie w kontekście RobotLegs i projektów realizowanych z jego użyciem – RL jak każdy framework architektoniczny (oparty o wzorzec MVC) narzuca pewien stopień organizacji oraz przynajmniej wstępny układ katalogów. Pisałem również wówczas że to co powinniśmy zapewnić w modelu MVC to daleko za mało aby sprawnie rozwijać projekt. Swoje stanowisko podtrzymuje a ostatnio dostrzegłem w całości nieco głębsze dno – otóż osobiście lubię jak wszystko jest poukładane, klasy nazywają się z sensem i mają ściśle i w oczywisty sposób zdefiniowaną misję a patrząc na pakiet w jakim się znajdują od razu wszystko wiadomo. Takie zaplanowanie całości i to już z góry w momencie zakładania projektu nie jest łatwe i myślę że wymaga pewnej dozy osobistego doświadczenia – bo jak inaczej przewidzieć co komu będzie potrzebne albo jaki stopień poukładania komu odpowiada? Przedstawię całość na własnym przykładzie, wypracowanym przy próbach rozwoju „uniwersalnej bazy projektu” (taki scyzoryk developera ze sprawdzonym kodem i narzędziami).
Pierwszorzędnym jest pytanie gdzie projekt utrzymywać – wiadomo ludzie dzielą się na tych co robią backup i na tych co będą robić:) Dla niektórych (chyba większości nawet) nie ma innej opcji niż github i jemu podobne ale czy jest sens zawracać sobie tym głowę gdy pracuje się w pojedynkę nad relatywnie małymi projektami o których z góry wiadomo że nie będą utrzymywane latami?
Na moim małym podwórku świetnie sprawdza się poczciwy dropbox – w chwili obecnej bez żadnych specjalnych sztuczek mam w nim 5gb przestrzeni co na wszystkie projekty starcza z zawiązką a opcja automatycznego przesyłania plików w tle zwalnia mnie z pamiętania o backupach. Nie wspominając już o dostępności z każdego miejsca na każdym sprzęcie:) Jedną tylko wadę tego rozwiązania odkryłem – nie nadaję się to zupełnie do pracy w grupie zwłaszcza jeśli developerzy korzystają jednocześnie z tych samych plików – wówczas zdarzyć się może że dropbox się zgubi.
Architektura:
- assets – katalog zawierający wszystkie materiały zewnętrzne do użycia w projekcie – w szególności czcionki które mają zostać osadzone, zestaw ikon do użycia w aplikacji, tła itp.
- fonts
- icons
- backgrounds
- commands – katalog dla komend z RL – z reguły wszystkie pogrupowane w trzy katalogi:
- getters – komendy służące pobieraniu danych z modeli ich obróbce i przekazaniu do widoków.
- opens – komendy modyfikujące widoki, głównie otwierające w ContextView nowe okna (PopUp).
- services – komendy odpowiadające za komunikacje z serwerem i ogólnie ze światem zewnętrznym aplikacji – wczytywanie danych i plików.
- contexts – katalog grupujący klasy związane z rozruchem aplikacji oraz jej ustawieniami:
- MainContext.as – plik contextu dla aplikacji.
- Setup.as – klasa której obiekt tworzony jest w MainContext.as – zapisuje wszystkie ważne dla aplikacji ustawienia – np dane serwera MySQL itp.
- BootstrapCommands.as – klasa której obiekt tworzony jest w MainContext – zawiaduje powiązaniami event – komenda.
- BootstrapMediators.as – klasa której obiekt tworzony jest w MainContext – zawiaduje powiązaniami widok – mediator.
- core – katalog na klasy bazowe – lekko zmodyfikowane wersje klas z pakietu mvc RL + klasa bazowa dla eventów, głównie w celu optymalizacji pracy.
- actor
- mediator
- command
- event
- events – pakiet z klasami eventów, jak już kiedyś pisałem eventy są wodą na młyn RobotLegs dlatego ich odpowiednie zorganizowanie jest bardzo istotne tym bardziej że w zasadzie w aplikacjach RL każdy powinien mieć swoje ściśle wytyczone zadanie i być unikalny.
- AppEvents – główne eventy aplikacji – najcięższa liga – są tu eventy dla błędów krytycznych itp na które zareagować ma cała aplikacja.
- OrderEvents – eventy płynąc do komend – głównie z mediatorów chociaż nie zawsze – główną idę jest odpalanie przez eventy z tej klasy komend z którymi są połączone w klasie „BootstrapCommands.as” (opisana wyżej).
- ResponseEvents – eventy płynące w odwrotną stronę – z komend do efektorów czyli głównie mediatorów/widoków/modeli itp.
- ServiceEvents – eventy za pomocą których serwisy porozumiewają się z komendami – głównie ERROR i SUCCESS.
- ViewEvents – eventy do komunikacji widoków z mediatorami.
- mediators – katalog z klasami mediatorów dla widoków, podzielony na pod foldery adekwatne do podziały widoków, o tym czemu akurat taki podział patrz poniżej.
- containers
- panels
- windows
- renderers
- models – pakiet z klasami przechowującymi dane w aplikacji.
- vo – vo = ValueObject – czyli obiekty danych – małe klasy służące do przekazywania danych pomiędzy obiektami.
- SessionManager.as – klasa zarządzająca sesją.
- Cookies.as – klasa korzystająca z SharedObject pozwala przechowywać dane pomiędzy sesjami.
- services – pakiet z klasami służącymi do komunikacji z serwerem i wczytującymi wszelkie dane.
- skins – katalog ze skórkami dla widoków – podział adekwatny do widoków.
- app
- containers
- panels
- renderers
- small
- windows
- styles – pliki css z odpowiednimi elementami stylii – osadzonymi czcionkami, ustawieniami skórek dla komponentów itp.
- Fonts.css
- Main.css
- Skins.css
- views – katalog z widokami, podzielony na odpowiednie elementy – patrz niżej.
- containers
- panels
- renderers
- small
- windows
- Main.mxml – główny plik aplikacji zawierający tag <s:Application>i stanowiący ContextView dla RobotLegs.
Każdy projekt ma swoją architekturę, w tym miejscu chciałbym wytłumaczyć taki a nie inny podział widoków/skórek/mediatorów – sam podział nie jest szczególnie istotny chodzi bardziej oto aby sobie odpowiadał – pozwala to zachować porządek w każdym projekcie. Osobiście jestem fanem jak najprostszego układu dlatego staram się rozwijać aplikacje w taki sposób aby na ekranie dashbordu użytkownik miał dostęp do wszystkich najważniejszych rzeczy, resztę natomiast udostępniam w postaci okien otwieranych w PopUpManager. Natomiast każdy samodzielny element stanowi u mnie panel, a najmniejsze składowe (w tym często powtarzające się) umieszczam w katalogu „small”. Teraz chyba wszystko jest jasne, jednak podkreślę to raz jeszcze – nie sam układ jest najważniejszy.
Resources #4
Zarządzanie projektami:
- https://www.trello.com/
- http://www.scrumdo.com/ – po więcej odsyłam do wiki.
Udostępnianie kodu:
as3 snippets 