אז מה הjava stack המועדף עליי?
במהלך עבודתי כיועץ JAVA פרילנסר עצמאי, אני מתבקש לעיתים קרובות להמליץ על טכנולוגיות ג'אווה מתאימות לפרויקט מסויים. בג'אווה בניגוד לטכנולוגיות של מיקרוסופט כמו דוט נט, יש מגוון עצום של אפשרויות בבואינו לבחור סביבות עבודה. לכל שכבה באפליקציה יש אינספור פריימוורקים, ספריות וAPI, חלקם הגדול בקוד פתוח ואחרות מסחריות. כל ארכיטקט ויועץ בוחר בSTACK האהוב עליו בהתאם להעדפותיו האישיות וכמובן בהתחשב בדרישות הפרוייקט וביכולות המוצרים השונים. בפוסט זה אפרוס את ההעדפות האישיות שלי שמתאימות למרבית הפרוייקטים אם כי זה כמובן משתנה בהתאם לצרכי הלקוח.
תצורה כללית Best of bread – Non J2EE
J2EE היא טכנולוגיה טובה אבל במקרים רבים מדובר בover kill והיא עמוסה פיצ'רים ושכבות שלא נמצאות בשימוש ומכבידות על המערכת. השימוש בsession Beans למשל כשהרבה פעמים אין צורך בכך ובכלל הEJB Container המסורבל כאשר הפונקציונליות היחידה שבאמת צריך היא JPA שאפשר לקבל גם ללא EJB (באמצעות Hibernate למשל). בנוסף, בJ2EE יש נטייה להצמד לשרת של יצרן מסויים ודי מהר מתחילים להשתמש בפיצ'רים היחודיים לאותו מוצר. זה גורם לאפליקציה להיות Non Portable כשרוצים לעבור לשרת אחר. פעמים רבות נתקלתי בפרוייקטים שרצים מעל J2EE כשהשרת משמש ללא יותר מאשר Servlet Container. הפלטפורמה של JEE מסבך דברים פשוטים: WAR פשוט הופך לEAR מורכב, Deployment Descriptiors מיותרים בחלק מהגרסאות, ובגלל שהשרתים בדרך כלל תפורים מראש קשה להחליף מודול ספציפי במקרה הצורך (למשל לשדרג לגרסה חדשה יותר). לדעתי כדאי להמנע ככל שאפשר משימוש
Application Server – Apache Tomcat
שרת האפליקציות וServlet Container הנפוץ בעולם. היחיד שיכול אולי להתחרות בו הוא Jetty אבל התיעוד הרב, וותק רב השנים, האינטגרציה הטבעית עם שרת Apache כשרת WEB, והאמינות של ארגון Apache הופכים אותו לאופציה הטובה ביותר.
ORM Persistence – Hibernate JPA Annotations
למרות שעדיין יש ארגונים המפתחים בhibernate בתוצרה הישנה קרי, שימוש בXML על מנת להגדיר את המיפוי בין המחלקות לטבלאות, השימוש בJPA annotations מהווה יתרון מכמה סיבות: ראשית זה מאפשר מעבר לEJB במידה ורוצים בעתיד להעביר את האפליקציה לJEE. שנית, הקוד הרבה יותר קריא וברור כשמעל לכל Property בקוד מופיע הגדרות המיפוי שלו. כמו כן זה מוריד את הצורך לתחזק XML שבמקרים רבים הופך להיות ארוך ומסורבל.
Dependency Injection – SPRING
במקומות רבים מוותרים לגמרי על השימוש בDI ובSPRING בפרט אבל לדעתי זהו פיצ'ר חשוב שמייעל ומפשט את הקוד בצורה משמעותית. הבחירה שלי בSPRING ולא בפריימוורקים אחרים כגון Google Guise היא שSPRING הוא הרבה יותר מרק DI. במקרה הצורך אפשר למצוא מענה טוב לכמעט כל טכנולוגיית ג'אווה קיימת: JMS, JPA, Security, RMI, Web Service, מימוש טוב לAOP ועוד ועוד. היופי בSPRING הוא היותו מבוסס על POJO כך שתמיד קל להבין איך דברים עובדים והכי חשוב: אפשר לשלוט בכמות הSPRING שמשתמשים בו בקוד. החל משימוש מועט רק בDI וכלה באפליקציית SPRING מלאה כולל MVC ושאר הפיצ'רים שהפריימוורק הענק הזה מציע.
UI – Rich Client with Adobe Flex
זה אמנם לא ג'אווה ולא WEB קלאסי אבל כיום אין תחליף לפלקס וליכולות שהוא מציע באפליקציות שדורשות קליינט מורכב וברמה גבוהה. יש כמה בעיות בUI רגיל מבוסס HTML וAJAX: ראשית הקליינט לא אמין. Exception יכול לגרום לכל הדף לעוף מבלי יכולת שחזור, ניתוק זמני מהשרת גורם לעיתים קרובות לאיבוד מידע, בעיית תאימות בין דפדפנים, קושי לפתח אלמנטים גרפיים מורכבים, ועוד. שורש הבעייה בממשקי WEB נעוץ בעובדה שהממשק בסופו של דבר בנוי על HTML. הבעייה ששפה זו מלבד היותה מיושנת, יועדה במקור ליצירת מסמכים עשירים ולא לממשקי משתמש. אין גרפיקה ווקטורית, אין קומפוננטות UI נפוצות כמו Tree והקומפוננטות הקיימות מספקות פונקציונליות שמתאימה למסמך ולא לאפליקציה. קחו למשל את Table, על מנת שהוא ייראה כמו טבלה מודרנית עם אפשרות להזזת עמודות, מיונים, פילטרים וכו' צריך לכתוב קוד רב ובדרך כלל להשתמש בכלל באלמנטים אחרים כמו DIV ולא בTABLE של HTML. הפריימוורקים הרבים הקיימים מבוססים על קוד JavaScript שמבצע מניפולציות על אלמנטים בHTML ו"אונסים" אותם כך שייראו כמו UI נורמלי. הדבר היחיד שיכול לשנות את התמונה הוא HTML5 אבל יש עוד דרך ארוכה עד שנוכל להשתמש בתקן זה. ראשית צריך שהתקן יסגר ויתמך בכל הדפדפנים, אחר כך צריך שחברות יפתחו ספריות קומפוננטות מבוססות HTML5. הcanvas כנראה יספק בסיס מתאים אבל מישהו צריך לפתח ולפרסם פקדים שיהיה ניתן לעבוד איתם. כך שבנתיים מבחינת טכנולוגיות זמינות ובוגרות FLEX היא האופציה הטובה ביותר לפיתוח מהיר של ממשקים גרפיים עשירים.