Wprowadzenie do implementacji architektur plug-in w PHP

Wprowadzenie do implementacji architektur plug-in w PHP Damian Tylczyński

„Gdybym wiedział co robię, to przecież nie była by praca badawcza„ - Albert Einstein

Funkcjonalność System monolityczny

„smaller parts (modules) that can be independently created and then used in different systems to drive multiple functionalities” - Wikipedia, Modular design

Plug-in Niezmienna postać, Stabilne API zmienna funkcjonalność na żądanie System architektury plug-in Miejsce na dalszy rozwój Usługi systemu

„LINUX is a monolithic style system. This is a giant step back into the 1970s. That is like taking an existing, working C program and rewriting it in BASIC. To me, writing a monolithic system in 1991 is a truly poor idea„ - Andy Tanenbaum

Spoiler: Darwin, Linux, Windows NT nie są mikro-jądrami

XULRunner

Plug-in powinien skupić się na wykonaniu pojedynczego zadania

Nie ArticlesPlugin tylko: ● PagePlugin – wyświetlanie i edycja, ● CategoriesPlugin – kategoryzacja, ● TagPlugin – tagi, ● CommentsPlugin – komentarze, ● ScorePlugin – ocenianie,

Nie UsersPlugin tylko: ● AuthPlugin – ACL i autoryzacja, ● LoginPlugin – logowanie, ● RegisterPlugin – rejestracja, ● UserDataPlugin – dane użytkownika,

Dostęp do bazy danych? Sesje? Także plug-in

(mikro) jądro Udostępnienie fundamentalnego środowiska działania plug-in

Jądro i zdarzenia Konfiguracja Rejestracja Uruchomienie środowiska i konfiguracja pluginów aplikacji

Cykl życia pluginu: Instalacja, → Uruchomienie, → Działanie, Aktualizacja → Zatrzymanie, Usunięcie.

Zarządzanie pluginami Tak, to też plugin

Zależności Udostępnianie „narzędzi” Pliki multimedialne Instalacja Plug-in to nie tylko „jakaś” funkcja do wywołania Reagowanie Aktualizacja Nadpisywanie

Abstrakcja System M C V bazy danych szablonów Obsługa Wywołanie Odpowiedź żądania akcji HTTP HTTP Zarządzanie Jądro plug-in Plug-iny

Plug-in musi mieć możliwość komunikacji z innymi częściami systemu (i z innymi pluginami)

Luźne wiązania

Pośrednik

Programowanie zdarzeniowe

Wysłanie Odebranie

Bąbelkowanie

Zatrzymywanie bąbelkowania

I funkcje domyślne też

getContext() Obiekt kontekstu naszym pośrednikiem (wielozadaniowym)

Wstrzykiwanie zależności umożliwia rozpropagowywanie obiektu kontekstu

Każdy plug-in musi posiadać dostęp do własnego obiektu kontekstu Każda klasa. Każda usługa.

Usługi?

Usługa to zestaw funkcji posiadających zunifikowane API, implementujące rozwiązanie pewnego problemu (uff...)

Dlaczego nie wszędzie zdarzenia? Na zdarzenie nie musi reagować żadna funkcja

Plugin != Usługa Plugin > Usługa

LogsService – logowanie w aplikacji. Pluginy? LogsTxtPlugin LogsNullPlugin Zunifikowany interfejs? log( $msg ) warn( $msg ) err( $msg )

Kontekst musi udostępniać usługi (zachowywać się jak kontener zależności)

Narzędzia Programowanie zdarzeniowe. Wzorzec filtra. Wzorzec dekoratora. Wzorzec strategii. Obiekty proxy. Kontener wstrzykiwania zależności.

Stabilność Dziel i rządź GTD programowania Zalety Zrównoleglenie prac Mniej zależności Bezpieczeństwo

Dziękuję za uwagę

Wprowadzenie do implementacji architektur plug-in w PHP

by PHPCon Poland on Jun 05, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 26

Statistics

Wprowadzenie do implementacji architektur plug-in w PHP — Presentation Transcript