Bardzo często spotykam się z pytaniem, czy w APEX-ie można budować poważne aplikacje ? Powiem szczerze że częstość zadawania mi tego pytania zaczęła mnie zastanawiać do tego stopnia, że postanowiłem nieco temu bliżej się przyjrzeć : ).
Zacznijmy więc od samej technologii. APEX jest w pełni oparty o Oracle-a czyli nie możemy stworzyć aplikacji w APEX-ie, która będzie wykorzystywała inną bazę (tak przynajmniej argumentują moi oponenci). A ja się pytam: czy to jest źle ? Dla mnie jest to w pewnym stopniu zaleta. Technologia ściśle związana z konkretną bazą… a w tym przypadku z bazą Oracle to bardzo wydajna współpraca, możliwość wykorzystania każdego elementu bazy do ostatniej kropli. A baza Oracle ma naprawdę wiele do zaoferowania : )
Patrząc od strony środowiska serwerowego to APEX jest totalnie przenaszalny (Windows, Linux, MacOS, Solaris, wszelkiej maści Unixy).
APEX jest całkowicie oparty o język PL/SQL. Jeżeli do tej pory byłeś programistą Javy i obiektowość jest twoim przeznaczeniem to dyskusja może być trudna. Ale czy obiektowość jest niezbędna jeżeli technologia jest tak czy siak oparta o konkretny system zarządzania bazą danych i nie przenaszalna na inny ?.. Chmmm ja zdecydowanie wolę podejście strukturalne i zarazem natywne przy pracy z RELACYJNĄ bazą danych a szczególnie z Oracle.
Ile to APEX posiada warstw ?, APEX w najprostszej postaci może posiadać jedną wartswę… podkreślam w najprostszej ! My w poważnych instalacjach wykorzystujemy 3 wartwy, Serwer bazy danych, Apex Listener jako para-serwer oraz Apache jako Frontend. W zależności od potrzeb mamy tu dużą możliwość skalowalności i rozproszenia.
Interfejs użytkownika w APEX jest nazbyt tradycyjny. Wow.. co to znaczy ? A no tyle, że nie jest np. oparty o Flash-a lub cos w tym stylu. A ja na to… SUPER tak właśnie ma być, APEX to czysty HTML czyli nie ma żadnego problemu z obsługa na wszelkich przeglądarkach włącznie z mobilnymi a w szczególności z iPhone-m. HTML5, który nadchodzi wielkimi krokami połozy na łopatki technologie Flash i wszelkie podobne. Tak więc już zacznijcie zamykać tagi " br / " ; ) A dla niedowiarków chcących zobaczyć jak można estetycznie podejść do sprawy w APEX-ie podaje nasz serwis, który realizuje tematy graficzne dla Oracle APEX www.apex-designers.com.
Podsumowując sprawę technologii w APEX, ciężko mi znaleźć jakiś słaby punkt z tego co powyżej. Czy naprawdę potrzeba przenoszalności na inny system zarządzania bazą jest tak ważną kwestią ? Ja pracując przy wielu projektach nie spotkałem się z czymś takim, że ktoś kto dziś decyduje się na rozwiązanie Oracle zakłada, że za rok, dwa będzie musiał przenieść się na IBM DB2 lub MSSQL. Wręcz przeciwnie, współpracując z wieloma firmami, które pracowały np. 10-15 lat z Oracle nadal chcą kontynuować tą współpracę mimo, że system całkowicie im się już z amortyzował i mają swobodny wybór.
W pierwszej części tyczącej się technologii to wszystko, w następnej zajmę się dostępnością do wiedzy i popularnością w społeczności.
piątek, 6 stycznia 2012
Subskrybuj:
Komentarze do posta (Atom)
Ale aplikacji (czyli silnika generującego html po stronie serwera) nie oddzieli się od bazy. Zatem rozumiem że nie można rozdzielić serwera aplikacyjnego od serwera bazodanowego. Zgadza się? Uniemożliwia to np. przełączenie się w czasie developmentu na inną bazę w celu testowania aplikacji. Ponadto jeśli chodzi o pisanie kodu w plsql... Daleko mu do innych języków (z najprostszych rzeczy - operator trójargumentowy, nieczytelna składnia, brak możliwości wywołania funkcji nie pobierając jej wyniku, konieczność deklarowania pakietów i oddzielnie body do nich, problem ze zmianą typu jeśli zależą od niego inne, niższa wydajność). Na pewno jest jeszcze wiele przeciw (poważniejszych) z z których sami zdajecie sobie sprawę. Jednak do sporej części aplikacji www, są one mniej znaczące niż zalety.
OdpowiedzUsuń na zawszeNie zgadzam się :)
OdpowiedzUsuń na zawszeSchemat APEX jest rozdzielny od schematów aplikacji (workspace). Sama aplikacja może korzystać z kilku różnych schematów podpiętych do workspace, jednak tylko z jednego korzysta nie potrzebując nazw kwalifikowanych. Samo przełączenie schematu przebiega bezproblemowo. Oznacza to, że zmiana ze środowisk Prod na Test przebiega bez problemów.
Co do PL/SQL to kwestia mocno subiektywna. Znam inne języki programowania (ANSI C, C++, Delphi), i nie znam rzeczy, której nie da się przenieść z tamtych języków do PL/SQL.
Należy zaznaczyć, że sam PL/SQL nie jest językiem do zastosowań obliczeniowych i na pewno nie będzie tutaj przodował.
1. A czy da się do workspace podpiąć schemat z innej instancji bazy (np. z innego serwera)??
OdpowiedzUsuń na zawsze2. PL/SQL. Nie pisałem że czegoś nie da się zrobić w PL/SQL. W moich zastosowaniach da się. Ale jest to niewygodne, czasochłonne i w utrzymaniu reż nie ciekawe - np. kontrola wersji... Oczywiście PLSQL nie będzie przodował w niczym poza dostępem do danych, ale przecież aplikacje www (niekoniecznie dostępne w internecie) często mają sporą logikę pod spodem. Nie tylko wyświetlają dane i pozwalają je wprowadzać.
3. Tak sobie właśnie pomyślałem o instalacji aplikacji ASP.NET a instalacji aplikacji APEX (razem z resourceami). Nie jest zle, ale Apex tu przegrywa.
Co Ty na to Piotrze?
Pozdrawiam
Marcin
A ja na to :) :
OdpowiedzUsuń na zawszeAD1. Nie da się :) Tyle, że problem środowisk testowych w APEX/Oracle załatwia się inaczej. Wystarczy Database DiFF i zwykłe kopiowanie aplikacji.
AD2. Zgadzam się z czasem i wygodą. Są to jednak odczucia indywidualne. Wszystko zależy do czego jesteś przyzwyczajony.
Jednak Co do logiki to wydaje mi się, że mniejsza wydajność i tak jest niezauważalna na tle danych jakie trzeba obrobić. Tutaj Oracle / APEX wygrywa na całego.
AD3. Nie znam ASP.NET i nie rozumiem w czym problem. Instalacja Oracle to kilka kroków w wizardzie. Aktualizacja (we wszystkich Oracle jest już APEX) to dwa skrypty.
Co do instalacji aplikacji to także jest ona zawarta w jednym skrypcie. Nie wiem czy można łatwiej.
Dorzucę jeszcze, że ASP.NET nie jest tak multiplatformowe jak Oracle APEX. APEX będzie chodził wszędzie tam gdzie Oracle, a wspiera ona dużą ilość platform.
Pozdrawiam
Piotr
AD1. No właśnie. Nie da się. W innym niż apex środowisku zmieniasz connectstringi na inną bazę i masz załatwione. Nie wiem czy rozumiem na czym polega załatwianie środowisk testowych o jakich piszesz. Ale wygląda na trochę bardziej złożone czasowo niż podmiana connectstringów. Ponadto taka architektura nie pozwala na rozdzielenie aplikacji od bazy danych (czyli 2 serwery by nie obciążać jednego). Również nie pozwoli w prosty sposób naszej aplikacji APEXowej do sięgania do innych baz.
OdpowiedzUsuń na zawszeAD2. Zgadza się. Ale jeśli chodzi o dużą ilość danych - inne rozwiązania również sobie poradzą. Jeśli bardzo dużą - zapewne jeden serwer nie wystarczy, a jek się skaluje apex na wiele serwerów - nie wiem. Ale chyba nie bardzo. Sprostuj jeśli się mylę.
AD3. Problem banalny. W ASP.NET robisz projekt, podpinasz do niego wszystkie zasoby (js, img, css). Kompilujesz. Instalujesz wizardem 3 krokowym. U każdego klienta tak samo!!! Działa. W APEX jesli masz kilku klientów z rożnymi bazami i różnymi instalacjami to masz zabawę. Odpalenie skryptu wciągającego twoją aplikację. Znalezienie miejsca gdzie powinny być resource, wrzucenie ich... itd. Może nie ma tego dużo i przy kilki klientach nie ma sprawy. Przy kilkunastu - robi się różnica. Nie piszę tu o instalacji środowiska. Choć to też temat którego APEX nie koniecznie jest w stanie wygrać.
AD Dorzucenie. Z jednej strony jest OK że APEX działa tylko na Oracle (czyli jednej bazie) a z drugiej niefajnie że ASP.NET działa tylko na windowsie. No to jak? Fajna jest wieloplatformowość (baz/systemów) czy nie? Z mojej strony nie koniecznie. Nie zależy mi na tym by APEX działał na MSSQL, ale również nie potrzebuję jego działania na linuxie. Obsługa wielu baz jest problemem, podobnie jak obsługa przez serwis różnych systemów u różnych klientów.
Pozdrawiam
Marcin
Ad1. Może ogólnie napiszę jak się robi development w APEX.
OdpowiedzUsuń na zawszePrzy założeniu że mamy dwa środowiska (dwa fizyczne serwery) przejście z jednego na drugi z aplikacją to czyste kopiowanie samej aplikacji z jednego na drugi przy założeniu że struktura bazy jest taka sama. jeśli masz to na jednym serwerze to w zasadzie wystarczy podłączy schemat do aplikacji (5 sekund roboty).
AD3. Skalowanie jest proste. Ogólnie wszystko się sprowadza do tego jak skalować Oracle. A on skaluje się bardzo dobrze. Sam APEX może (bo nie musi) mieć dostęp do wszystkiego do czego dostęp ma Oracle więc z dostępem do danych nie ma tu żadnego problemu. (Andrzej napisał coś nawet z dostępem do MSSQL :) )
AD3. Poczekaj. APEX ma identyczną funkcjonalność. Robisz aplikację z zasobami i tworzysz gotową paczkę do instalacji, samo robiłem tego typu aplikacje i to działa.
Dla wielu osób wieloplatformowość o tyle ma znaczenie że nie chcą zmieniać serwera lub jego oprogramowania. Linux jak wiemy jest darmowy dokładamy do tego bazę Oracle XE (również darmową) i mamy kombajn dla większości małych i średnich firm w Polsce. Sam APEX przez to, że związany z jedną baza jest bardzo stabilny i nie sprawia kłopotu ze względu na platformę (system).
Pozdrawiam
Piotr
Obecnie nie mam czasu ale wieczorem dołączę się do dyskusji. Tak czy siak pisząc wpis miałem nadzieje na właśnie takie coś : )
OdpowiedzUsuń na zawszeProszę jedynie obu Panów o trzymanie się tematu wpisu : )
AD1. Ja mam kilka(naście) schematów. Na jednej instancji nie ma szans na środowisko testowe. Przeniesienia aplikacji - zrzucenie sql aplikacji i przekopiowanie zasobów. Jednak więcej roboty niż zmiana connectstringów. Tak czy inaczej bardziej chodziło mi o to, że jednak czegoś takiego jak rozwarstwienie aplikacji od bazy nie ma. Jednym ze scenariuszy dla którego byłoby to przydatne to właśnie testowanie aplikacji. Inny (poważniejszy) to faktyczne rozdzielenie u klienta. Np. klient daje ci dostęp do bazy i oddzielny serwer na aplikacje. Baza już obsługuje inne jego aplikacje. I zaczynasz się tłumaczyć czemu jednak musisz aplikację zainstalować na serwerze bazodanowym.
OdpowiedzUsuń na zawsze2. Mogę tu czegoś nie wiedzieć, ale poza db linkami, jakie jeszcze mechanizmy udostępnia oracle do łączenia między bazami? Z góry zaznaczam że dblinki nie bardzo współpracują np. z SDO_GEOMETRY. Jeśli nie ma innej opcji poza dblinkami - wynika że apex/oracle przegrywa z net/java na tym polu.
3. Faktycznie jest coś takiego. Chodzi o: Home ->Application Builder -> Application 109 -> Shared Components -> Cascading Style Sheets itp? Zamiast kopiowania ręcznego u klienta, mamy kopiowanie przez developera przed każdym buildem. Zawsze ciut lepiej dla serwisanta :-) Gorzej dla developera. Tym bardziej że trzeba wskazywać pliki pojedynczo!!! Chyba że jest inna metoda. A mechanizmowi temu jeszcze się przyjrzę dokładniej.
Wieloplatformowość. No właśnie. Jedni będą kręcili nosem że chcę im wcisnąć oracle (apex) inni że chcę im wcisnąć windows (net). Oczywiście jest jeszcze java/oracle/mysql.
XE + Linux - zgadza się - mocna platforma. Jednak doświadczenie pokazuje że łatwiej znaleźć kogoś do obsługi win niż lin :-(
Pozdrawiam
Marcin
Więc może kilka słów teraz odemnie. Pisząc wpis, tak jak w temacie chciałem zwrócić uwagę na to, iż wiele osób podchodzi do APEX-a jak do jakieś technologii "zabawkowej".
OdpowiedzUsuń na zawszePatrząc na samą technologię można zrealizować niemal wszystko co jest dostępne w technologiach konkurencyjnych (aplikację do internetu) a sposób realizacji jest często wyjątkowo prosty i wydaje mi się że pod względem właśnie sposobu realizaji jest bezkonkurencyjny.
Zgodzę się, że wiele rzeczy APEX ma do nadrobienie m.in zarządzanie wersją, choć też się jakoś da. Co do punktów jakie poruszaliście, to wydaje się że należało by kilka rzeczy uściślić.
Rozbicie na warstwy. APEX jako "element bazy danych" nie interpretuje nic poza nią. Zaleta jest taka, że pływa w danych i dostęp jest bardzo efektywny. Jasne, że czasem chciało by się zmienić na stronie connectstringa żeby sięgnąć do innej instancji.
Choć chyba głównie po to, żeby aplikacja była bardziej zbalansowana. No ale Oracle ma RAC-a, który elegancko współpracuje z APEX-em. Też są linki, które w pewnych elementach mogą wystarczyć (zgadzam się, że nie zawsze - np. obsługa LOB-ów).
Jeżeli chodzi o pracę zespołową przy projekcie to jej efektywność zależy od przygotowania i doświadczenia.
Nie ma problemu aby zbudować efektywne środowisko, developerskie, produkcyjne i jak kto woli jakieś regression do tego. Tutaj do przesuwania wersji należy zapoznać się z narzędziami exportu i importu aplikacji z lini poleceń (są w instalce apex-a). Mając to, plus kilka komend w shelu + API do data pump można całkiem fajnie to sobie poukładać.
Podsumowując tą debatę wydaje mi się, żę skręciliśmy tylko w jedną strone tzn. w elementy administracyjne i projektowe a zapomnieliśmy o tworzeniu poszczególnych elementów aplikacji, strona, formatka, zarządzanie użytkownikami itp itd.