nemrég beszéltem egy barátommal a felhasználói felület fejlesztéséről. Azóta is programozó, hogy a programozást misztikus művészetnek tekintették(amikor minket, akik megtettük, úgy tekintettek, mint a Szürke Gandalf a Balrog felé). Vagy talán csak így láttuk magunkat. Ettől függetlenül mindketten Java programozók voltunk abban az időben.
mindketten sajnáltuk, hogy ez egy kontextusváltás volt, hogy a legtöbb projektünket Java-ban kódoljuk, majd át kell váltanunk a JavaScript-re a front end számára.
az online beszélgetések alapján több olvasó felmelegíti a billentyűzetét, hogy szidjon, amiért panaszkodtam, hogy JavaScript-ben kell kódolnom. Tartsa a kulcsokat hűvös, mind a mi és munkatársaink tapasztalt, és szívesen írni, JavaScript és bármely keretrendszer ügyfeleink számára. De a JavaScript használata nem mindig a legjobb megközelítés.
ebben a bejegyzésben két keretrendszert mutatunk be, amelyek lehetővé teszik a felhasználói felület kódolását Java-ban: GWT és Vaadin.
mikor kell használni a Java-t a felhasználói felülethez?
a beszélgetés akkor jutott eszembe, amikor egy ügyféllel beszéltem — egy kis bolt, ahol csak néhány programozó és egy szoftver építész volt, akik szintén programoztak. Úgy döntöttek, hogy nem akarják fenntartani projektjeiket két külön nyelven. Cégük szabványosította a Java – t, és ugyanazokat az eszközöket és gondolkodásmódot akarták használni, hogy hatékony és modern felhasználói felületeket hozzanak létre webes alkalmazásaikhoz.
nagyobb csapatoknál észrevettem, hogy a csapat úgy tűnik, hogy elkülönül egymástól, egyesek inkább a front-Endre koncentrálnak, mások pedig leginkább a back-end vagy a szerver oldali kódon dolgoznak. Amikor a work get jóváhagyásra kerül a fejlesztéshez, gyakran látom, hogy ugyanazok a programozók veszik vagy kapják meg a JavaScript front-end munka nagy részét, mások pedig a back-endet.
nem azt mondom, hogy ez rossz dolog; valójában úgy tűnik, hogy éppen az ellenkezője. Úgy tűnik, hogy mindenki produktívabb a komfortzónájában, de mindenki tisztában van azzal is, amit mindenki más csinál, és beléphet ebbe a zónába, ha szükséges. A kisebb üzletek esetében ez nem lehetséges. Gyakran ugyanaz a programozó írja a kódot egy teljes projektre a felhasználói felületről a modellre.
szerencsére vannak választási lehetőségek, ha meg szeretné tartani a felhasználói felület ugyanazon a nyelven, mint a back-end, ha ez a nyelv a Java. Most beszéljünk néhányról.
GWT
a Google Web Toolkit vagy a GWT kiváló lehetőség.
sok sikert arattam a GWT-vel egy olyan projektben, amelyet körülbelül 8 évvel ezelőtt kezdtem el, és még mindig fenntartok. A GWT lehetővé tette számomra, hogy egy egyoldalas alkalmazás nézet logikáját teljesen szabványos Java kódban építsem fel. Jön egy Eclipse plugin. Nem azért használtam, mert a NetBeans-t használtam a fejlesztői környezetemhez, de mivel az Eclipse a legtöbb csapat szabványa, ez nagyon hasznos lehet.
képes voltam lebontani a widgetek logikáját (például egy egyéni szövegdobozt) osztályokra vagy segítő módszerekre, ugyanúgy, mint egy kiszolgálóoldali projekt üzleti logikáját. Az öröklés révén több olyan widgetet tudtam létrehozni, amelyek hasonló követelményekkel rendelkeztek. A változás egyetlen valódi koncepciójával kellett foglalkoznom, hogy a felhasználói felület sokkal eseményvezérelt, mint a legtöbb webszolgáltatás vagy más szerveroldali kód.
a GWT-nek két elsődleges hátránya van. Az egyik a fordítási idő. A GWT hozzáad egy fordítási lépést a folyamathoz, amely némi időt vesz igénybe. A Java-ban beépített GWT osztályokat JavaScript könyvtárakba kell fordítani. Számos panaszt láttam az ehhez szükséges idővel kapcsolatban.
a második az, hogy már jó ideje óta GWT látott jelentős frissítést. Az írás óta a 2.8.2 több mint egy évvel ezelőtt, 2017 októberében jelent meg. Három évvel korábban megjelent a 2.7.0, így négy évvel az írás időpontjától számítva. Látom a 3.0-val kapcsolatos hozzászólásokat és megjegyzéseket, köztük néhány két évvel ezelőtti kérdést, hogy a poszternek meg kell-e várnia a 3.0 megjelenését, mielőtt nagy változást hajtana végre (remélem, hogy a poszter még mindig nem vár), de nem találok ütemtervet arra vonatkozóan, hogy mikor lehet ez a kiadás.
bár nagy rajongója vagyok a keretrendszernek, és elég érettnek tartom, tudom, hogy a jövőbeli kiadások lehetőségének bizonytalansága néhány projektmenedzsert meglehetősen idegesít. Senki sem akarja, hogy egy olyan kerethez kössék, amely zsákutcába kerül.
a GWT egy olyan könyvtár, amelyet továbbra is használni fogok, és javasolni fogok más csapatoknak, hogy használják, ha megfelel az igényeiknek.
Vaadin
a Vaadin egy másik nagyszerű lehetőség.
eredetileg azt hittem, hogy a GWT az egyetlen választásom a felhasználói felületek szabványos Java kódba írására. De amikor beszéltem a fent említett kis üzlettel, azt mondták nekem, hogy úgy döntöttek, hogy a Vaadint használják projektjeikhez. Így, természetesen, meg kellett néznem. Le vagyok nyűgözve.
őszinte leszek, az írás óta még nem használtam a Vaadint projekt létrehozásához. De van néhány személyes projektem, amihez front-Endre kell, és ezt használni fogom. Ha a Vaadin teljesíti ígéreteit, tökéletes keret lesz ezeknek a projekteknek.
a Vaadin megígéri, hogy támogatja a JVM-ben futó nyelveket, mint például a Kotlin és a Scala. Remélem, hogy ez magában foglalja a Groovy-t is. Ha sok korábbi hozzászólásomat elolvassa, akkor tudni fogja, hogy rajongója vagyok ennek a nyelvnek, mert gyorsan létrehozhat könnyen karbantartható kódot. Ezek fontos követelmények számomra, különösen a karbantarthatóság. Semmi sem pusztítja el jobban a projektet az úton, mint hogy nem tudja könnyen fenntartani a már megírt kódot.
végső gondolatok
számos választási lehetősége van a webes alkalmazás architektúrája során, amikor a felhasználói felület technológiájáról van szó. Akár egy projektet, akár egy termelési környezetet tervez, annyi követelményt kell szem előtt tartania.
két követelmény, amelyet szem előtt kell tartania, a könnyű fejlesztés és a karbantarthatóság.
- egy olyan fejlesztői környezet, amelyben nehéz dolgozni, sok költségtúllépést eredményez, és nagyon megnehezíti az új programozók bevonását.
- egy nehezen karbantartható projekt frusztrációt okoz, és több pénzt pazarol a jövőben.
a csapat igényei és követelményei alapján a teljes Java megoldás, a felhasználói felülettől a modellig, nem csak lehetséges, hanem nagyszerű választás mind a gyors fejlesztés, mind a könnyű karbantartás érdekében.
hisz a jó kódban.