GoldenLine
Zaloguj się
Tomasz Zadora

Tomasz Zadora programuję

Temat: APLIKACJA, PROJEKT, MODUŁ

APLIKACJA:

Aplikacja działająca na danym serwerze (serwer w sensie fizycznym) lub serwerach jeżeli aplikacja jest aplikacją rozproszoną w tym sensie.

Dana aplikacja zawiera w sobie jeden i tylko jeden projekt.

Na danym serwerze może działać kilka aplikacji w których są zawarte te same projekty.

Na przykład - możemy mieć na serwerze kilka aplikacji zawierających ten sam projekt sklepu internetowego, każda aplikacja działa na innej domenie internetowej.

Każda aplikacja ma swój unikalny w obrębie serwera(rów) identyfikator.

PROJEKT
Projekt składa się z modułów które mogą być indywidualnie konfigurowalne dla danego projektu.

MODUŁ
Moduł składa się z określonych zasobów takich jak:
- relacje bazy danych
- logika (modele i kontrolery)
- inne zasoby związane z prezentacją

Zasoby można podzielić na dwa rodzaje:
- współdzielone przez wszystkie projekty
- indywidualnie konfigurowalne dla projektu (kopiowane do folderu projektu)

Zależności:
- włączenie modułu do projektu może wymagać obecności innego modułu w projekcie

Na przykład: jeżeli zostanie stworzony moduł ORM, można sobie wyobrazić inne moduły które będą go wymagały. Natomiast proste moduły i aplikacje mogą się np. bez ORM obejść.

Podobnie można sobie wyobrazić moduł systemu szablonów (dla tych którzy tego wymagają) etc.

Tego typu konstrukcja - aplikacja, projekt, moduł jest bardzo elastyczna i pozwalająca jednocześnie na tworzenie lekkich i wydajnych aplikacji.Tomasz Zadora edytował(a) ten post dnia 31.05.11 o godzinie 14:21
Link do wypowiedziLink
Wojciech Soczyński

Wojciech Soczyński Programista
eksplorator -
blog.wsoczynski.pl

Temat: APLIKACJA, PROJEKT, MODUŁ

Dobra koncepcja na początek. Ja bym się natomiast zastanowił nad jednym - skoro moduł może wymagać obecności innego modułu, to jak je "pożenić" żeby to było elastyczne ?

Ja w swoich projektach eksploruje ostatnio podejście wzorowane na SoA (Service Oriented Architecture) gdzie cała funkcjonalność na którą składa się np kilka modeli ukryta jest pod warstwą abstrakcji - usługą (wzorzec fasady).

Załóżmy, że mamy sobie moduł artykuły. Ma on w sobie modele dotyczące kategorii i artykułów, fasada:


class ArticlesFacade {



    function createArticle($data);

    function editArticle($data, $id);

    function deleteArticle($id);

    function articleList($from, $to);

//... inne metody

}


W momencie, kiedy inny moduł potrzebowałby korzystać z artykułów (np. moduł RSS), wystarczy, że skomunikuje się z usługa Artykułów (reprezentowaną przez ArticlesFacade) i wykona odpowiednią metodę.

Zalety takiego podejścia to:

1. minimum zależności między modułami
2. spójność
3. łatwa kontrola dostępu
4. możliwość łatwego rozproszenia aplikacji poprzez przeniesienie wybranych usług na osobne maszyny i komunikację przez webservice

Btw. przy takiej architekturze również kontroler w module korzysta z własnej usługi - zyskujemy realną niezależność modelu od frameworka.Wojciech Soczyński edytował(a) ten post dnia 31.05.11 o godzinie 14:46
Link do wypowiedziLink
Tomasz Zadora

Tomasz Zadora programuję

Temat: APLIKACJA, PROJEKT, MODUŁ

Odnośnie modułów chciałbym jeszcze dopisać, że myślałem przedewszystkim o wykorzystaniu przestrzeni nazw która byłaby odwzorowana na katalogi (i tym samym mielibyśmy ułatwioną kompatybilność z PSR-0 jeżeli chodzi o autoloader).

Podstawowa sprawa jeżeli chodzi o zależności: jeżeli jakiś moduł wymaga innego modułu to w tym momencie powinien "wiedzieć" jak z niego korzystać.

Chodzi o to żeby nie tworzyć jakichś nadmiarowych struktur w stylu: każdy moduł musi gdzieś udostępnieć listę interfejsów albo klas z których można korzystać, etc. Tego typu rzeczy powinny się znaleźć w dokumentacji modułu.

Rozwiązanie z fasadą które przedstawiłeś jest dobre (przypomina mi to trochę adaptery dla interfejsów) - i jak najbardziej można w takim stylu programować, nie chciałbym tylko tego "wymuszać".

Jeżeli chodzi o sprawy związane np. z konfliktami nazw etc. - tutaj wróćmy do początku postu, czyli przestrzeni nazw - każdy moduł to osobna przestrzeń nazw.

Plus chciałbym stworzyć repozytorium "oficjalnych" i "zaakceptowanych" modułów gdzie każdy programista mógłby *przynajmniej* rezerwować swoje przestrzenie nazw (nie musi wysyłać kodu modułu, bo może być np. komercyjny) - ułatwiło by to unikanie konfliktów.

Istniałby oczywiście jeden podstawowy moduł o nazwie np. "/DFM/Standard" który byłby zawsze obecny w każdmy projekcie - byłby bardzo "cienki" - byłyby to podstawowe klasy frameworka + bardzo podstawowa konfiguracja fizycznej maszyny, związana z konfiguracją maszyny (np. ścieżka absolutna do root-dira), oraz konfiguracją start-upu: osobny startup dla CLI, osobny dla requestu HTTP + oczywiście możliwość stworzenia swojego.

Moduły to dość szeroki temat który postaram się tutaj kontynuować (i liczę na Twoje i innych komentarze ;-) ) w miarę czasu (którego do jesieni będę miał mało).

Generalnie chciałbym dużo napisać o modułach w kontekście projektu "generatora" czyli środowiska gdzie tworzy się projekty - bo możemy sobie np. wyobrazić sytuację, że włączenie modułu do projektu to manipulacja bazy danych projektu w tym sensie że np. tworzą się nowe relacje etc.

Czyli każdy moduł powinien mieć pewien interfejs współpracujący z generatorem ale te rzeczy związane z generatorem nie musiałyby (i nie powinny) być już włączone do wynikowej aplikacji która będzie wygenerowana przez generator.Tomasz Zadora edytował(a) ten post dnia 31.05.11 o godzinie 15:08
Link do wypowiedziLink
Wojciech Soczyński

Wojciech Soczyński Programista
eksplorator -
blog.wsoczynski.pl

Temat: APLIKACJA, PROJEKT, MODUŁ

Ja myślę, że repozytorium modułów to dobry pomysł, natomiast rezerwacja przestrzeni nazw jest trochę bez sensu w tym kontekście, że można przecież używać aliasów.

Co do wymuszania rozwiązania, to moim zdaniem jest to dobra praktyka, ponieważ pozwala ustandaryzować development. Co więcej stosując taką fasadę, każdy z góry widzi jakie możliwości udostępnia jaki moduł i w ramach dokumentacji wystarczy dopisać phpDoc-a do każdej metody i voila.

Co do "setupu" to ja mam takie rozwiązanie, że do każdego modułu mam klasę, która jest odpowiedzialna za trzymanie konfiguracji oraz posiada swoją metodę "setup" dzięki której generuje część bazodanową etc. W twoim przypadku mogła by to być metoda, która jako argument bierze generator kodu o którym wspominałeś i instruuje go co ma zrobić...
Link do wypowiedziLink
Tomasz Zadora

Tomasz Zadora programuję

Temat: APLIKACJA, PROJEKT, MODUŁ

Jeśli chodzi o rezerwację całej przestrzeni nazw (np. /moja/przestrzen/costam) - plusem byłoby to, że:

- przestrzeń nazw oznacza zarazem katalogi (jak pisałem wyżej) i w tym momencie jak sobie zarezerwujesz, to masz pewność że inny moduł nie wejdzie "z butami" np. do twojego katalogu, łatwo też dzięki temu wszystko znaleźć -> wiesz gdzie są pliki modułu, gdzie on "siedzi".

Chodzi o to żeby dość łatwo było np. połączyć swój moduł sklepu internetowego z czyimś modułem np. forum albo komentarzy z minimalizacją ewentualnych konfliktów.

- podstawowy moduł byłby jednocześnie kontrolerem zależności - czyli załadowanie modułu zawsze powoduje dodanie do listy aktualnych modułów, można by oczywiście robić jakieś identyfikatory modułów ale po co skoro mamy przestrzeń nazw, lepiej to uprościć maksymalnie niż generować zbyt dużo właściwości

Przestrzeń nazw modułu była by jego przestrzenią "root" - czyli moduł moze mieć podstawową przestrzeń nazw np. '/sklep-mojadomena-pl', albo '/moja-firma' i jednocześnie może korzystać z tej struktury "niżej", czyli mieć dodatkowe przestrzenie: '/moja-firma/costam'.

Dlatego generalnie najlepsza byłaby rezerwacja "szczytowej" nazwy, tak żeby można było sobie tworzyć osobne moduły, np. rezerwuję sobie '/firma-x' i mam moduły:

'/firma-x/sklep', '/firma-x/cms', '/firma-x/kalkulator' etc.Tomasz Zadora edytował(a) ten post dnia 31.05.11 o godzinie 16:40
Link do wypowiedziLink

konto usunięte

Temat: APLIKACJA, PROJEKT, MODUŁ

A co w sytuacji gdy będzie kilka implementacji tego samego modułu?
Weźmy przykładowy RSS*, w momencie gdy rezerwujesz, każdy kto zrobi swoją implementację będzie musiał zajmować nową np. /rss1/, /rssMW/ itd.
Trochę bez sensu.

* akurat dla mnie, RSS nie jest modułem, a formatem odpowiedzi...
Link do wypowiedziLink
Tomasz Zadora

Tomasz Zadora programuję

Temat: APLIKACJA, PROJEKT, MODUŁ

To nie powinno być "/rss" - tylko "/moja-przestrzen/rss" :)

Czyli coś podobnego do umowy w javie - bazowe przestrzenie które rezerwujemy, nazywamy nazwą domeny internetowej której jesteśmy właścicielem.

W tym momencie ja np. mógłbym tworzyć oprogramowanie sklepu pod domeną "supersklep.pl" i wtedy zarezerwowałbym sobie przestrzeń nazw "/SupersklepPl" i jeżeli zrobiłbym jakiś moduł RSS to przestrzenią nazw tego modułu byłoby
"/SupersklepPl/RSS".

W tym momencie nawet jak powstanie 500 różnych modułów RSS to zgodnie z konwencją każdy powinien być w osobnej przestrzeni nie kolidującej z inną - np. "/MichalWachowskiPl/RSS", "/WSoczynskiPl/RSS" i tak dalej.Tomasz Zadora edytował(a) ten post dnia 31.05.11 o godzinie 17:37
Link do wypowiedziLink

konto usunięte

Temat: APLIKACJA, PROJEKT, MODUŁ

W takim wypadku ma to jak najbardziej sens.
Choć znając życie - ktoś wredny przyjdzie i zarezerwuje sobie z automatu wszystkie :)
Link do wypowiedziLink
Tomasz Zadora

Tomasz Zadora programuję

Temat: APLIKACJA, PROJEKT, MODUŁ

Eeee no nie ;-) To będzie tak zrobione, że to admin/admini będą akceptować oficjalne przestrzenie nazw, oficjalne sprawdzone moduły etc.

To wszystko jednak w pewnym sensie "grzecznościowo", bo jak ktoś będzie chciał to zawsze może sobie zrobić moduł w dowolnej przestrzeni nazw - bo np. uzna że nie będzie go nigdy publikować i nie będzie korzystać z innych modułów.

Tak samo jest w javie - jak masz domene supcio.pl powinieneś pakiety rozpoczynać od: pl.supcio, np. pakiet pl.supcio.rss - ale nikt Cię do tego nie zmusi tak samo jak nie zmusi Cię, żebyś na spotkanie np. z klientem przyszedł uczesany i trzeźwy ;-)Tomasz Zadora edytował(a) ten post dnia 31.05.11 o godzinie 18:05
Link do wypowiedziLink
Tomasz Zadora

Tomasz Zadora programuję

Temat: APLIKACJA, PROJEKT, MODUŁ

Aktualny opis Projektu/Aplikacji/Modułu znajduje się w dokumentacji online: http://inoframework.org/pl/doc.php?did=2Tomasz Zadora edytował(a) ten post dnia 01.06.12 o godzinie 15:04
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy





Wyślij zaproszenie do
Anuluj