יישום הלוגיקה העיצובית

פילוסופיות גישת יישום

גישת מפל מים

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

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

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

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

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

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

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

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

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

פיתוח זריז

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

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

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

פיתוח מצטבר

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

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

תוכנית בקרת זרימה

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

קוד מארגן

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

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

יצירת הפרויקט

שכבות

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

שכבות מול שכבות

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

איור 8-1: ארגון תלת-שכבתי בסיסי

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

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

שכבות פיזיות

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

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

הוספת דפוסים לשכבות

שלוש השכבות הבסיסיות מספקות סקירה ברמה גבוהה. בואו נוסיף כמה דפוסים מבניים כדי ליצור ארכיטקטורה ארגונית חזקה. התוצאה מוצגת באיור 8-2.

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

זרימת החלטות

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

ישנן שתי גישות לארגון השירותים שלך:

• מכוונת פעולה
• מונע על ידי המדינה

גישה מכוונת פעולה

על ידי ארגון שירותים המבוססים על פעולות משתמש, אתה מיישם לוגיקה של אפליקציה על ידי הצעת שירותים, שכל אחד מהם מטפל בבקשה ספציפית משכבת המצגת. זה ידוע גם בתור תבנית הסקריפט של העסקה. גישה זו פופולרית מכיוון שהיא פשוטה ונראית טבעית מאוד. דוגמאות לשיטות העוקבות אחר גישה זו הן BookStoreService.AddNewOrder(Order order) ו-BookStoreService.CancelOrder(int orderId).

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

גישה מונעת על ידי המדינה

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

פרויקטים של מבנה נתונים

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

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

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

בחירת מנוע אחסון נתונים

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

• תקליט
• קובץ app.config
• קבצי xml
• קבצי טקסט רגיל
• מאגר מידע
• תור להודעות

לכל חנות מאפיינים ייחודיים משלה וניתן להתאים אותה לדרישות ספציפיות.

עיצוב זרימת הנתונים

זרימת נתונים באמצעות ADO.NET

על ידי הטמעת שירותים ממוקדי נתונים בשכבת הלוגיקה של האפליקציה, תעצב את זרימת הנתונים שלך באמצעות ADO.NET. ספריית כיתה NET Framework מספקת ממשק תכנות יישומים נרחב (API) לעיבוד נתונים בקוד מנוהל. המכונה ADO.NET, ניתן למצוא את ה-API במרחב השמות System.Data. הפרדה מלאה בין ספקי נתונים ומאגרי נתונים היא תכונת עיצוב חשובה של ADO.NET. מחלקות כמו DataSet, DataTable ו-DataRow נועדו לאחסן נתונים אך לא שומרים על ידיעה מהיכן הגיעו הנתונים. הם נחשבים לאגנוסטיים של מקור נתונים. קבוצה נפרדת של מחלקות, כגון SqlConnection, SqlDataAdapter ו-SqlCommand, דואגת להתחבר למקור נתונים, לאחזר נתונים ולאכלוס של DataSet, DataTable ו-DataRow. מחלקות אלו ממוקמות במרחבי משנה כמו System.Data.Sql, System.Data.OleDB, System.Data.Oracle וכן הלאה. בהתאם לאיזה מקור נתונים אתה רוצה להתחבר, אתה יכול להשתמש במחלקות במרחב השמות הנכון, ובהתאם להיקף המוצר שבו אתה משתמש, תגלה שמחלקות אלו מציעות פחות או יותר פונקציונליות.

מכיוון ש-DataSet אינו מחובר למקור הנתונים, ניתן להשתמש בו בצורה מוצלחת למדי לניהול זרימת הנתונים באפליקציה. איור 8-5 מציג את זרימת הנתונים בעת ביצוע פעולה זו.

בואו נסתכל על הפרויקט הזה ונדמיין שמישהו נכנס לחנות הספרים שלכם והזמין שלושה ספרים. שכבת המצגת ניהלה את מצב עגלת הקניות. הלקוח מוכן לבצע את ההזמנה וסיפק את כל הנתונים הדרושים. הוא בוחר לשלוח הזמנה. דף האינטרנט הופך את כל הנתונים ל-DataSet המכיל שני DataTables, אחד להזמנה ואחד להזמנה; מוסיף DataRow עבור ההזמנה; ומוסיף שלוש DataRows עבור שורות ההזמנה. לאחר מכן, דף האינטרנט מציג את הנתונים האלה בחזרה למשתמש פעם נוספת, מחייב בקרות נתונים מול מערך הנתונים ושואל האם אתה בטוח? המשתמש מאשר את הבקשה והיא מוגשת לרובד הלוגי של האפליקציה. שכבת הלוגיקה של היישום בודקת את מערך הנתונים כדי לראות אם לכל השדות הנדרשים יש ערך ומבצעת בדיקה כדי לראות אם למשתמש יש יותר מ-1000 US$. 00 על שטרות עומדים. אם הכל ילך כשורה, ה-DataSet מועבר לשכבת הגישה לנתונים, שמתחברת למסד הנתונים ויוצרת הצהרות הוספה ממידע ה-DataSet.

שימוש ב-DataSet בצורה זו היא דרך מהירה ויעילה לבנות אפליקציה ולהשתמש בכוחה של ספריית ה-Framework Class והיכולת של ASP.NET לאגד נתונים לפקדים שונים כגון GridView מול DataSet. במקום להשתמש באובייקטים פשוטים של DataSet, אתה יכול להשתמש באובייקטים מסוג DataSet ולשפר את חוויית הקידוד על ידי הטמעת קוד בשכבת המצגת כמו גם בשכבת הלוגיקה של היישום. היתרון של גישה זו הוא גם החיסרון של הגישה. שינויים קטנים במודל הנתונים אינם מובילים בהכרח לכך ששיטות רבות יצטרכו לשנות את החתימות שלהן. אז מבחינת תחזוקה, זה עובד ממש טוב. אם אתה זוכר ששכבת המצגת היא לא בהכרח ממשק משתמש, היא יכולה להיות גם שירות אינטרנט. ואם אתה משנה את ההגדרה של מערך הנתונים, אולי בגלל שאתה משנה שם שדה במסד הנתונים, אתה משנה את החוזה ששירות האינטרנט נרשם אליו. כפי שאתה יכול לדמיין, זה יכול להוביל לכמה בעיות משמעותיות. תרחיש זה עובד היטב אם שכבת המצגת היא רק ממשק משתמש, אך עבור ממשקים למערכות או רכיבים חיצוניים, תרצה להסתיר את הפעולה הפנימית של היישום שלך ולהפוך את הנתונים למשהו אחר מאשר שיבוט ישיר של מודל הנתונים שלך תרצה ליצור אובייקטי העברת נתונים (DTOs).

זרימת נתונים באמצעות מיפוי יחסי אובייקט

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

איור 8-6 מציג זרימת נתונים דומה לתמונה 8-5, אלא שעכשיו הוספת את שכבת המיפוי היחסי של אובייקטים והחלפת את אובייקטי ה-DataSet בנשאי נתונים שונים.

עכשיו בצע את אותו הדבר צעד אחר צעד כמו קודם; דמיינו שמישהו התחבר לחנות הספרים שלכם והזמין שלושה ספרים. שכבת המצגת ניהלה את מצב עגלת הקניות. הלקוח מוכן לבצע את ההזמנה וסיפק את כל הנתונים הדרושים. הוא בוחר לשלוח הזמנה. דף האינטרנט הופך את כל הנתונים ל-DTO, מחזיק נתונים עבור הזמנה אחת ועם שלוש שורות הזמנה, יוצר את האובייקטים לפי הצורך. דף האינטרנט מציג את הנתונים הללו למשתמש שוב, איגוד נתונים שולט כנגד ה-DTO באמצעות ObjectDataSource ב-ASP.NET 2.0 ושואל האם אתה בטוח? המשתמש מאשר את הבחירה וה-DTO מוגש לשכבה הלוגית של האפליקציה. שכבת הלוגיקה של היישום הופכת את ה-DTO לאובייקט עסקי מסוג Order עם מאפיין שיכיל שלושה אובייקטים OrderLine. שיטת ההזמנה. Validate() נקרא כדי לאמת את ההזמנה ולוודא שלכל השדות הנדרשים יש ערך, ונעשה בדיקה כדי לזהות אם למשתמש יש יותר מ-R$ 1,000.00 בתלושים ממתינים. לשם כך, ההזמנה תקרא Order.Customer.GetOutstandingBills(). אם הכל בסדר, שיטת Order.Save() נקראת. הבקשה תעבור בשכבת המיפוי היחסי של אובייקטים, כאשר הבקשה ושורות הבקשה ממופים ל-DataTable ב-DataSet, וה-DataSet מועבר לשכבת הגישה לנתונים, שמתחברת למסד הנתונים ומייצרת הצהרות insert מ- המידע במערך הנתונים. ישנן, כמובן, דרכים רבות שבהן מיפוי יחסי אובייקט יכול להתרחש, אך לא כולן יכללו טרנספורמציה ל-DataSet. חלקם ייצרו את הצהרת ה-insert ישירות אך עדיין ישתמשו בשכבת הגישה לנתונים כדי לבצע משפט זה.

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

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

שירותים מבוססי סכמה

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

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