Robotlegs AS3 lightweight framework

(1100 linii kodu)

Czym jest framework

• Generalnie jakikolwiek zbiór klas lub bibliotek wielokrotnego użytku, Flex, jQuery, RoR...

Robotlegs – KOMUNIKACJA I WSPÓŁPRACA• Robotlegs koncentruje się na ułatwieniu komunikacji i współpracy

pomiędzy poszczególnymi częściami aplikacji• jednokierunkowa komunikacja – obiekt posiada referencję do innego i

wywołuje publiczne metody (API)• Komunikacja poprzez wydarzenia i przekazywanie wiadomości

Charakterystyczne cechy

• mikroarchitektura• Czysty AS3• Zniechęca do uzywania Singleton i wszystkiego co

statyczne(sprzyja TDD oraz debugowaniu)• Zapomnij o bąbelkowaniu• Używa metadanych do dependency injection, przez co

uwalnia nas od tworzenia zbędnych zależności• Promuje luźne wiązanie • Preferuje kompozycję, nie dziedziczenie (czyli składanie

właściwości obiektu z małych klas ‘funkcyjnych’ )

MVCS

• Model – przetrzymuje wiedzę i manipuluje stanami aplikacji

• View – to wszystko to, co widzisz i słyszysz• Controller – tłumaczy akcje użytkownika na język

stanów aplikacji, nie odpowiada czy raczej nie powinien odpowiadać za logikę samych widoków.

• Service – łączy aplikację ze światem zewnetrzym, danymi wprowadzonymi prze użytkownika, zassanymi z XML, bazy danych czy zewnętrznego API

Jak to jest połączone, czyli jak Robotlegs załatwia sprawy

Implementacja MVCS w Robotlegs

Z czego Robotlegs jest zbudowany?

• Context – tu konfigurujemy aplikację : startup()• Actor – rozrzeżany przez nasze Modele i Serwisy• Mediator Map – wiąże widoki z Mediatorami• Mediator – łącznik pomiędzy widokiem a aplikacją• Eventmap - zarządza łaczęniami na linii event - słuchacz• CommandMap – łaczy Eventy z Commands• Commands – wprowadza zmiany w Modelach i

Serwisach• Injector – factory do Dependency Injection

Context

BootModels

BootServices

BootCommands

BootViewMediators

Actors – Model & Service

eventDispatcher jest zaszyty w klasie Actor, zatem dispatchujemy eventy z Modeli i Serwisów

dispatch(event)

Model – zapewnia API dla danych

Model NIE nasłuchuje eventów, on je wyłącznie

rozgłasza (dispatch).

Service – komunikacja ze światem poza aplikacją

Śmiało może też parsować dane z zewnętrznych źródeł.W serwisach NIE PRZETRZYMUJEMY DANYCH.

Dane trzymamy w Modelach.

Service NIE nasłuchuje eventów, on je wyłącznie

rozgłasza (dispatch).

Mediator – łącznik pomiędzy widokiem a resztą apliakcji, listonosz

Mediator zapewnia aplikacji API do widoków, aby trzymać ją zdala od widoków.

MediatorNasłuchuje eventów z widoku

Nasłuchuje eventów z frameworka.

MediatorRozgłasza eventy do frameworka.

MediatorWidoki NIE SĄ POWIĄZANE w żaden sposób z mediatorami (czy jakąkolwiek inną klasą frameworka).Widoki nie mają pojęcia o istnieniu aplikacji.

To Mediatory SĄ POWIĄZANE z widokami.

Mediatory mają dostęp bezpośredni do Serwisów i Modeli, ale (UWAGA) korzystanie z tego przywiązuje Mediator do któregoś z aktorów. Używać z ostrożnością.

Lepiej korzystać z CommandsCommands są egzekwowane w reakcji na dispatchowany Event.Są egzekwowane i zaraz po tym niszczone.1 Command = wyłącznie jedna czynność/działanie.

Commands

Commandy odwalają pracę na Actors - Models & ServicesCommands przechwytują dane z Eventów z którymi sa powiązane poprzez CommandMapCommands rozgłaszają też Eventy (dispatch)

Commands NIE odbierają/nasłuchują Eventów i nie wiwdzą o żadnych innych poza tym jednym z którym są powiązane (dostępny poprzez [Inject]).

Wiedza

• http://knowledge.robotlegs.org• https://

github.com/robotlegs/robotlegs-framework/wiki/Best-Practices

• https://github.com/robotlegs