דפוסי עיצוב מאפשרים ליישומי J2EE טובים יותר

מאז הקמתה, J2EE (Java 2 Platform, Enterprise Edition) פשטה את בניית האפליקציות הארגוניות בג'אווה. עם זאת, ככל ש- J2EE מאומץ באופן נרחב יותר, מפתחים מבינים את הצורך בגישות מוגדרות המפשטות את בניית היישומים והן סטנדרטיות. אתה יכול להתחיל להשיג מטרה זו על ידי סטנדרטיזציה של הרובד האדריכלי של היישום שלך .

השכבה האדריכלית בדרך כלל עוטפת את המורכבות הטכנית של היישום ללא תלות בהיגיון העסקי, ובכך מספקת צימוד רופף בין הפונקציונליות העסקית לבין התשתית הטכנית הבסיסית. במאמר זה, אני מסביר שיטה מתפתחת לבניית ארכיטקטורת היישומים לפרויקטים של J2EE - כזו המשתמשת בדפוסי עיצוב כדי לספק את הסטנדרטיזציה והפשטות שארכיטקטורה טובה דורשת.

ארכיטקטורת יישומים ו- J2EE

J2EE היא טכנולוגיית תשתית נהדרת. הוא מספק תקן אחיד למשימות הרמה הנמוכה יותר של ערימת הטכנולוגיה, כגון תקשורת בסיס נתונים או הפצת יישומים. J2EE לא מובילה מפתחים לבנות יישומים מצליחים. יוצרי J2EE, שהסתכלו מטה אל ערימת הטכנולוגיה, תהו: "כיצד נוכל לתקנן את ה- APIs האלה?" הם היו צריכים להסתכל על מפתחי האפליקציות ולשאול: "איך אוכל לתת למפתחים את אבני הבניין שהם צריכים כדי להתמקד ביישום העסקי שלהם?"

כשמתחילים פרויקט J2EE חדש, כמה מחברי הצוות שואלים לעתים קרובות: "אם J2EE הוא אדריכלות, למה אנחנו צריכים יותר?" מפתחים רבים טענו כי תפיסה מוטעית בימיו הראשונים של J2EE, אך מפתחי J2EE מנוסים מבינים כי J2EE אינו מצליח לספק את ארכיטקטורת היישומים הנחוצה בכדי לספק יישומים באיכות גבוהה באופן עקבי. מפתחים אלה משתמשים לעתים קרובות בדפוסי עיצוב כדי למלא את הפער הזה.

תבניות עיצוב

בתכנות, דפוסי העיצוב מאפשרים לך למנף את החוויה הקולקטיבית של קהילת המפתחים על ידי שיתוף בעיות ופתרונות המועילים לכולם. דפוס עיצוב חייב ללכוד את הגדרת הבעיה וההקשר שלה, פתרון אפשרי ואת השלכות הפתרון.

למטרות ארכיטקטורת יישומי J2EE, דפוסי העיצוב מתחלקים לשתי קטגוריות: דפוסי פיתוח תוכנה כלליים ודפוסים המזהים אתגרים ספציפיים של J2EE. דפוסי תכנון ספציפיים ל- J2EE מזהים את מערך הבעיות הידוע המינימלי שעליו לפתור ארכיטקטורת יישומים מוצקה. הקבוצה לשעבר, זו של דפוסי פיתוח תוכנה שאינם ספציפיים ל- J2EE, מוכיחה עצמה באותה מידה - לא בזיהוי בעיות, אלא בהנחיית בניית אדריכלות.

בואו נבחן כל אזור בפירוט רב יותר.

דפוסי עיצוב J2EE

דפוסי העיצוב של J2EE התפתחו בשנים האחרונות כאשר קהילת ג'אווה צברה ניסיון J2EE. דפוסי תכנון אלה מזהים בעיות פוטנציאליות בהן נתקלים בשימוש בטכנולוגיות השונות שצוינו J2EE ועוזרים למפתחים לבנות את דרישות ארכיטקטורת היישומים. דוגמת העיצוב הפופולרית של Front Controller, למשל, הופכת קוד סרווט לא מובנה לבקר שמזכיר את פיתוח ה- GUI המעודן (ממשק משתמש גרפי).

דפוסי העיצוב של J2EE מזהים את בעיות התחום הסבירות ביותר להופיע בפרויקטים J2EE שלך. ואכן, אם הבעיות היו נדירות, דפוסי העיצוב לא היו מתפתחים כדי לענות עליהן. עם זאת בחשבון, תוכל להפיק תועלת מטיפול בכל בעיה בתחום בארכיטקטורה שלך. כדי לפתור את כולם, צור רשימת ביקורת שתאמת את הארכיטקטורה שלך להשלמה. תהליך זה מנוגד לתהליך של דפוסי העיצוב של פיתוח תוכנה שאדון בהמשך, מכיוון שאתה צריך ליישם את הדפוסים רק מתי ובמקרה.

אז איפה מוצאים דפוסי עיצוב J2EE? סאן מיקרוסיסטמס מציעה שני ספרים המכילים דפוסי J2EE רבים:

  • תכנון יישומי הארגון של קבוצת J2EE BluePrint עם פלטפורמת Java 2 (מהדורת Enterprise), ניקולס קאסם ואח '. (אדיסון-ווסלי, 2000; ISBN: 0201702770)
  • דפוסי הליבה J2EE של קבוצת השירותים המקצועיים של Sun : שיטות עבודה מומלצות ואסטרטגיות עיצוב, Deepak Alur, John Crupi, and Dan Malks (Prentice Hall, 2001; ISBN: 0130648841)

(ראה משאבים לקישורים לשני הספרים.)

מעבר למשאבים של Sun, פרסומים אחרים מציעים מידע על תבניות עיצוב J2EE, כולל מגזינים שונים בתעשיית Java או אתרי אינטרנט (כגון JavaWorld ), כמו גם ספרים רבים. (ראה משאבים לקישורים לחלק מהאתרים הללו, כולל עמוד האינדקס המקומי של דפוסי העיצוב של JavaWorld .)

דפוסי עיצוב פיתוח תוכנה

שימו לב גם לדפוסי העיצוב של פיתוח תוכנה, המפוצלים לדפוסי עיצוב כלליים מונחי עצמים (OO) ולדפוסי עיצוב ספציפיים ל- Java. דפוס המפעל, למשל, מייצג דפוס עוצמתי של OO ליצירת עצמים ליצירת אופציות כדי לאפשר שימוש חוזר ולעמוד בדרישות המערכת המשתנות. מצדם, דפוסי העיצוב בשפת Java מהווים ספציפי לשפות Java. חלקן ייחודיות לג'אווה ובדרך כלל אינן פורמליות (למשל, חריגים ופרימיטיביים), ואילו אחרות הן דפוסי OO המעודנות להחלה על ג'אווה. הספר המפורסם של כנופיית ארבע, דפוסי העיצוב מאת אריק גמא ואח ', מפרט מספר רב של דפוסי פיתוח תוכנה כלליים שימושיים לכל המתכנתים.

אל תבטל דפוסים אלה פשוט משום שהם אינם ספציפיים ל- J2EE. נהפוך הוא, דפוסים כאלה יכולים להוכיח עוצמה באותה מידה, אם לא יותר מכך, מדפוסי עיצוב J2EE, מכיוון ש:

  • בעוד שדפוסי העיצוב של J2EE חדשים ומתפתחים (מכיוון J2EE חדש ומתפתח), הדפוסים האחרים נהנים מהגיל, מכיוון שלענף היה יותר זמן לבדוק אותם ולשכלל אותם.
  • לעתים קרובות הם משמשים בסיס שממנו נובעים דפוסי העיצוב של J2EE.
  • הם בונים את הבסיס שעליו מיושמים הפתרונות הספציפיים ל- J2EE. בניית בסיס זה נכונה משפיעה באופן נרחב על חסינותה והרחבתה של הארכיטקטורה. אם לא נבנה כהלכה, הבסיס ימזער את התועלת של הארכיטקטורה ללא קשר למספר בעיות J2EE שהיא פותרת.

אל תעשה רשימת ביקורת שתכסה את דפוסי פיתוח התוכנה שהארכיטקטורה שלך דורשת, כמו שאתה עושה עם דפוסי J2EE. במקום זאת, השתמשו בדפוסים כאלה במידת הצורך בהתבסס על האתגרים הספציפיים של הפרויקט שלכם. מפתחים רבים מאמינים בטעות כי המוצרים שלהם ישתפרו אם ישתמשו בדפוסים רבים יותר - או אם ישתמשו בכולם! אולם זה לא המקרה. השתמש בשיקול דעת ובעדינות כאשר אתה מחליט אילו דפוסים להשתמש וכיצד להשתמש בהם יחד.

דפוסי עיצוב: איפה הקוד?

זכור כי דפוסי העיצוב אינם מגיעים עם היישום המדויק, או קוד המקור בו תשתמש. היצע דפוסי העיצוב נע בין תיאורים טקסטואליים דלילים לתיעוד עשיר ועד לקוד לדוגמה כלשהו. האתגר מגיע ביישום הרעיונות החזקים של הדפוסים. יש ליישם רעיונות אלה על הסביבה בה ישמשו; הסביבה מגדירה את היישום הנכון.

כאנלוגיה, שקול דפוס עיצוב לבניית יסוד הבית. דפוס התכנון מזהה את הבעיה, את ההקשר ואת הפיתרון האפשרי לבניית התשתית - מידע בעל ערך רב לעובד הבניין בשטח. על העובד עדיין לבנות את הבסיס. האם אותו עובד בניין לא היה מרוויח יותר מהקבלת הבסיס (בדומה למפתח התוכנה שניתן לו היישום)? אולי יסוד זה יהיה רק ​​לוח בטון שהבית יכול להיות בנוי עליו. הבעיה: על הבסיס להשתלב בבית עצמו ובאדמה בה יושב הבית. כיצד יכול בסיס כזה שנבנה מראש להכיל את כל תכניות רצפת הבית האפשריות (מלבן, ריבוע וצורות מוזרות אחרות) ואת כל הנופים האפשריים (על ראש גבעה,באמצע יער וכן הלאה)?

חזרה לעולם התוכנה, היתכנות השימוש בדפוסי עיצוב שנבנו מראש תלויה בשני גורמים:

  • היישום, לא דפוסי עיצוב בודדים, מייצג פיתרון. הפתרון יכול לשלב מספר דפוסי עיצוב, ובכך לדעת כיצד דפוסי העיצוב האישיים משחקים יחד.
  • על הפיתרון להיות מותאם, אשר עונה על השאלה האחרונה מהאנלוגיה של התשתית הבנויה מראש: על התשתית להיות מסוגלת להסתגל לשטח ולתכניות הקומה. כפי שאתה יכול לדמיין, יידרש אומן מיומן ביותר כדי לבנות את התשתית המותאמת להבדיל מהיסוד הסטנדרטי.

דפוסי עיצוב נפוצים

הטבלה שלהלן מפרטת כמה דפוסי עיצוב נפוצים הן ממקורות J2EE והן מדפוסי OO רחבים יותר.

דפוסי עיצוב נפוצים
דפוסי עיצוב J2EE דפוסי פיתוח תוכנה
חזית מושב קְלָף בּוֹדֵד
אספן אובייקט ערך לְגַשֵׁר
דפוס איתור שירות אב טיפוס
נציג עסקי מפעל מופשט
ישות מורכבת משקל זבוב
מטפל ברשימות ערך מתווך
איתור שירות אִסטרָטֶגִיָה
ישות מורכבת מְעַצֵב
אובייקט ערך מדינה
שירות לעובד איטרטור
אובייקט גישה לנתונים שרשרת אחריות
מיירט מסנן בקר תצוגת דגם II
צפה בעוזר מַזכֶּרֶת
תצוגה מורכבת בּוֹנֶה
תצוגת שולח שיטת המפעל

בואו נסתכל על שתי דוגמאות לתבניות עיצוב J2EE: חזית המושב ודפוסי אובייקט ערך. שניהם מדגימים כיצד דפוסי עיצוב J2EE מתמקדים בבעיות המיוחדות לסביבת J2EE, בניגוד לדפוסי עיצוב פיתוח תוכנה החלים בדרך כלל על כל מאמץ בפיתוח יישומים.

דוגמה: דפוס J2EE של חזית המושב

דפוס חזית המושב התפתח מחוויות עם Enterprise JavaBeans (EJBs). מערכות שנבנו על יישומי ה- EJB של הישות החדשה (שמתקשרים עם מסד נתונים) האטו לזחילה. בדיקות ביצועים גילו בעיות שנבעו ממספר שיחות רשת שבוצעו בעת תקשורת עם EJB של הישות, שהוסיפו תקורה לביסוס חיבור הרשת, סדרת הנתונים לשליחה וקבלה ואפקטים אחרים.

בתגובה, דפוס חזית ההפעלה שיפר את הביצועים על ידי ריכוז של מספר להיטי הרשת בשיחה אחת. Session Facade מעסיק EJB מושב חסר מדינה כדי לתווך בין שיחת הלקוח לבין האינטראקציה הנדרשת של ישות EJB. קיימים דפוסים נוספים לשיפור ביצועי הגישה למסד הנתונים, כולל דפוסי Reader Reader ו- Data Access Object.

דוגמה: תבנית J2EE של אובייקט הערך

תבנית ה- Value Object J2EE שואפת גם לשפר את ביצועי מערכות המשתמשות ב- EJB ברשת. אותן שיחות רשת המניבות תקורה מהדוגמה הקודמת מאחזרות שדות נתונים בודדים. לדוגמה, ייתכן שיש לך PersonEJB ישות עם שיטות כגון getFirstName(), getMiddleName(), ו getLastName(). באמצעות דפוס העיצוב Value Object, באפשרותך להפחית שיחות רשת מרובות כאלה לשיחה אחת בשיטה בישות ה- EJB, כגון getPersonValueObject(), המחזירה את הנתונים בבת אחת. אובייקט ערך זה מכיל את הנתונים שהיישות EJB מייצגת וניתן לגשת אליהם לפי הצורך מבלי לחייב את התקורה של שיחת הרשת.

דוגמה: תבנית ה- OO במשקל זבוב

לדוגמא לדפוס עיצוב OO ישים באופן נרחב, שקול את הדפוס Flyweight, המשפר את ביצועי היישום באמצעות שימוש חוזר באובייקטים. תוכנת OO מייצרת תקורה - מחזורי CPU מבוזבזים, איסוף אשפה והקצאת זיכרון - כאשר היא יוצרת ומשמידה אובייקט. אם המערכת תוכל לעשות שימוש חוזר בחפצים אלה, תוכל להימנע מהתקורה. האובייקטים לעתים קרובות אינם ניתנים לשימוש חוזר, אולם מכיוון שהם מכילים מידע (המכונה מצב ) הספציפי למשתמש הנוכחי של האובייקט. דפוס משקל הזבוב מספק גישות להעברת מצב זה למקום אחר כך שניתן יהיה לעשות שימוש חוזר בשאר האובייקט.

חברו את כולם: דוגמה להתמדה

עכשיו שאתה יודע את היסודות, אתה יכול להתחיל ליישם דפוסי עיצוב בשיטות הפיתוח שלך. אבל איך בעצם משתמשים בדפוסים? התחל בזיהוי תחום או בעיה טכנית הדורשת פיתרון. התמדה - פיתרון חוסר התאמה עתיק-יומין בין בסיסי-נתונים - מהווה דוגמה טובה לרוב היישומים הארגוניים. בואו נראה את השלבים הנדרשים לתכנון ובניית שכבת ההתמדה של ארכיטקטורת היישומים.

על פי הגישה האדריכלית והעיצוב המסורתית של OO, צור מקרי שימוש המתארים את צרכי ההתמדה שלך. מקרי שימוש אפשריים כוללים:

  1. התמדה של אובייקטים צריכה להיות שקופה מבחינת המפתחים.
  2. יש להגדיר את מנגנוני ההתמדה - EJBs של ישויות, אובייקטים לגישה נתונים וכן הלאה - ברמה האדריכלית.
  3. הארכיטקטורה שלנו צריכה להשתמש בטכנולוגיות J2EE אך לתמצת תלות ב- J2EE. אנו אמורים להיות מסוגלים לשנות ספקי שרת יישומי J2EE, גרסאות J2EE, או להחליף את J2EE לחלוטין מבלי לדרוש שיפוץ יישום שלם.
  4. שכבת ההתמדה המתקבלת צריכה להיות לשימוש חוזר בכל פרויקטים. זה אמור להיות חלק מארכיטקטורת היישומים המתמשכת שלנו.

לאחר שזיהיתם את הבעיה, תוכלו להחליט אילו דפוסים חלים. זכור כי עבור דפוסי J2EE, עליך לקבוע אילו דפוסים חלים באזור הבעיה ולטפל בהם. לצורך התמדה, דפוסי העיצוב הרלוונטיים של J2EE הם (ראה ספרי דפוסי העיצוב J2EE של Sun במשאבים):

  • אובייקט ערך
  • קורא מהיר ליין
  • אובייקט גישה לנתונים
  • חזית מושב
  • ישות מורכבת
  • מטפל ברשימות ערך

מכיוון שתעסיק EJBs, כלול את הדפוסים של נציג עסקים ושירותי איתור כדי לטפל בגישה ל- EJB.

בנוסף, פיתרון מקרי השימוש השני והשלישי מחייב דפוסי עיצוב פיתוח תוכנה מסורתיים. כיצד ניתן לתמצת תלות ויש לך מנגנוני התמדה הניתנים להגדרה? כמה דפוסי פיתוח תוכנה רלוונטיים כוללים:

  • בית חרושת
  • מתווך
  • אִסטרָטֶגִיָה