Jak budować całkowicie modułowe aplikacje internetowe [zamknięte]

W nadchodzących miesiącach rozpoczniemy projekt, w którym bierzemy system, który zbudowaliśmy dla klienta (v1) i odbudowujemy go od zera. Naszym celem w wersji v2 jest uczynienie go modułowym, aby ten konkretny klient miał swój własny zestaw modułów, których używają, a następnie inny klient może użyć innego zestawu modułów w ogóle. Sztuczka polega na tym, że Firma A może mieć szereg modułów kas i użytkowników, które zmieniają sposób działania tego systemu. Firma B może trzymać się standardowej procedury realizacji transakcji, ale dostosować sposób przeglądania produktów.

Jakie są dobre podejścia do architektury aplikacji, gdy Corebudujesz aplikację od zera, którą chcesz udostępnić wszystkim klientom, zachowując jednocześnie elastyczność w zakresie modyfikacji wszystkiego, co jest przeznaczone specjalnie dla klienta?

Widziałem haczyki CodeIgniter i nie sądzę, że to dobre rozwiązanie, ponieważ moglibyśmy skończyć z 250 hakami i wciąż nie jest wystarczająco elastyczny. Jakie są inne rozwiązania? Idealnie nie musielibyśmy rysować linii na piasku.

Aby osiągnąć wysoce zorganizowaną i oddzieloną modułowość, możesz postępować zgodnie z hierarchicznym wzorem architektonicznym MVC , czasami znanym jako Prezentacja - abstrakcja - kontrola (chociaż nie są to dokładnie ten sam wzór). Kohana , Alloy , Fluency i FuelPHP wspierają HMVC natywnie ^*, a podejście Kohany do HMVC zostało omówione w artykule Skalowanie aplikacji internetowych za pomocą HMVC i Optymalizacja aplikacji internetowych HMVC pod kątem wydajności , Sam de Freyssinet .

Niestety CodeIgniter nie obsługuje natywnie HMVC. Zbudowałem własne biblioteki, aby zapewnić obsługę HMVC w CodeIgniter, czerpiąc inspirację z koduigniter-modular-extensions-hmvc wiredesignz . Jest bardzo miłe wprowadzenie do artykułu HMVC na nettus +, który omawia CodeIgniter i rozszerzenie wiredesignz. Poniższy obraz i cytat pochodzą z tego samouczka:

Każda triada działa niezależnie od siebie. Triada może zażądać dostępu do innej triady za pośrednictwem swoich kontrolerów. Oba te punkty umożliwiają w razie potrzeby dystrybucję aplikacji w wielu lokalizacjach. Ponadto warstwowanie triad MVC pozwala na bardziej dogłębne i niezawodne opracowywanie aplikacji. Prowadzi to do kilku korzyści, które prowadzą nas do następnego punktu.

Wreszcie, jesteś na dobrej drodze z hakami, nawet jeśli zastosujesz architekturę HMVC, będą pewne problemy, które nadal będziesz musiał rozwiązać z hakami, w zależności od twojej implementacji i poziomu automatyzacji, którego szukasz . Dobrym zastosowaniem haków byłby pre_controllerhak, który zapewniłby na przykład wszystkie zależności dla zainstalowanych modułów.

_{* Mogą istnieć inne, o których nie wiem.}

Nie jestem facetem od PHP, ale po stronie skryptu java, jeśli chcesz mieć wiele modułów, które chciałbyś zachować jak najbardziej niezależny, jest na to kilka systemów, takich jak RequireJS , które mają skrypt java moduły deklarujące zależności od innych modułów, a środowisko zapewnia, że ​​zostaną załadowane w razie potrzeby.

Różne dostępne struktury różnią się pod względem sposobu deklarowania zależności, ilości obsługi zależności wykonywanej jako etap kompilacji na serwerze, ładowania strony lub dynamicznie na żądanie oraz tego, ile trzeba zmienić sposób pisania java- scenariusz.

Te frameworki nie stosują się tak często (a może wcale), jeśli frameworki po stronie serwera to obsługują lub generują skrypt java dla Ciebie, ale możesz chcieć, aby skrypt java był niezależny od frameworka po stronie serwera.

Jeśli nie masz zbyt dużo skryptu Java, ale potrzebujesz pewnej modułowości, zawsze możesz trzymać się anonimowych funkcji wywoływania, które obsługują zależności, najpierw zamawiając znaczniki skryptu z zależnościami i odwołując się do siebie, rejestrując się w jednym obiekcie w globalna przestrzeń nazw. To przynajmniej czyni je prawie modułowymi i nie kosztuje wiele do wdrożenia.

Oto kilka instrukcji dotyczących projektowania modułowego: https://class.coursera.org/saas/lecture/preview/9

także to: „ SOA można postrzegać w kontinuum, od starszych koncepcji przetwarzania rozproszonego i programowania modułowego , poprzez SOA, aż po obecne praktyki mashupów, SaaS , ...”

Sama organizacja kodu HMVC niekoniecznie prowadzi do modułowości.