NetBeans Platform (díl 2) – Výhody a nevýhody

Důvod, proč jsem zvolil desktop aplikaci vznikl z požadavku vytvořit aplikaci, která by komunikovala přes sériový port a ukládala čísla karet z různých čteček. Moc možností na výběr jsem neměl, jelikož přes webové rozhraní bych nebyl nic takového schopen aplikovat (samozřejmě nebudu zohledňovat aplety, které se mi dost příčí).

V první fázi jsem zvolil vlastní řešení (jako správný PHPčkář), přes Swing. Vše bylo v pořádku, do doby, kdy se aplikace začala rozrůstat. Implementace jednotlivých částí se prostě příliš svazovala mezi sebou a já začal mit v aplikaci chaos. Příčinou je jednak má nezkušenost s podobným druhem aplikací a jednak pouhá okrajová znalost konceptu pro distribuovanou Javu.

Poté jsem zajel na JAG, ve kterém se probírala RCP aplikace (NetBeans vs. Eclipse) a já si uvědomil, kde dělám chybu a jaké jsou výhody těchto řešení.

Asi bych měl znovu uvést, že se jedná o platformu, jinými slovy o „podvozek“, na kterém může běžet cokoli. Nejčastěji je ovšem známá kombinace: platforma + IDE = NetBeans IDE, Eclipse IDE. Dalo by se říci, že samotné vývojové prostředí je pouhý plugin dané platformy, i když je asi nejvýznamějším pluginem obou platforem.

Nyní již k samotným výhodám a nevýhodám tohoto řešení, do kterého zahrnuji kompletní řešení včetně použití dané platformy:

Z pohledu typu aplikace (desktop aplikace)

Výhody:
- možnost vytvořit přívětivé prostředí pro uživatele
- schopnost asynchroního volání bez zásahu nějakých zvláštních featur
- rychlá odezva mezi uživatelem a serverem
- prostředí umožňující přímou vazbu mezi uživatelem a OS (komunikace s periferiemi daného klientského PC)
- uvnitř desktop aplikace možnost používat i webovou aplikaci (vlastní web browser)

Nevýhody:
- distribuce (sice existují řešení jako JWS, ale s web aplikací se to srovnávat nedá)
- instalovana Java na klientském PC
- jisté systémové požadavky na běh aplikace (velikost RAM, atd)


Z pohledu architektury aplikace

Výhody
- swing (funguje kdekoli i s událostmi, na rozdíl od javascriptu u web aplikací)
- modulární systém (platforma stojí na tomto principu, který extrémně zpřehledňuje vývoj aplikace)
- skutečné OOP bez nutnosti statických view (HTML)
- Lookup (jedná se o hledání „služeb“ uvnitř kontextu NetBeans RCP)
- Services (služby, které lze registrovat a pomocí nich kominukovat mezi jednotlivými moduly, kteří o sobě vůbec nevědí, nemusí byt na sebe vázány)
- NetBeans API (při využívání tohoto API si navíc dokáži usnadnit práci a přímo ovlivňovat chování aplikace bez nutnosti přímého psaní swing komponent)
- podpora pluginů (pokud ve své aplikaci potřebuji nejakou funkčnost, kterou obsahuje plugin napsaný třetí stranou, mohu ho klidně využít a ušetřit si práci)
- celý koncept platformy, který je navržen tak, aby nejlépe odpovídal potřebám při psaní uživatelsky přívětivé aplikace

Nevýhody:
- náročná studie celého NetBeans API
- vzdálené volání EJB (spousta problémů při prvním setkání)
- v mnoha případech se jedná o kanón na vrabce

Asi by se dalo nalézt více kladů či záporů, ale v mém osobním pohledu, spatřuji tyto vlastnosti jako nejzásadnější.

V současné době se navíc musím vrátit k web aplikaci (osobně volím JSF), jelikož stojím před neřešitelným problémem: distribuce aplikace, s tím spojená i přímá aktualizace aplikace; a hardwarová náročnost aplikace, která mi neumožňuje distribuovat aplikaci mezi uživatele (velké fabriky holt nemají zájem tolik investovat do informatiky, kterou asi považují za nepotřebný subjekt).

I přes tuto velkou bariéru, mohu pokračovat na obou klientských verzích. Jak desktop, tak web, jelikož business logika (EJB kontejner) zůstává pro obě řešení stejná.