התמדה אובייקט ו- Java

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

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

שום אובייקט אינו אי

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

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

לשאילתות או לנווט?

באחסון אובייקטים בדיסק, אנו עומדים בפני הבחירה באיתור של אובייקטים קשורים בכדי לאפשר גישה טובה יותר לניווט, או לאחסון אובייקטים באוספים דמויי טבלה המאגדים אובייקטים לפי סוג כדי להקל על גישה מבוססת-פרדיקט (שאילתות), או שניהם . המיקום המשותף של אובייקטים באחסון מתמשך הוא תחום שבו מסדי נתונים יחסיים ומכווני עצמים נבדלים זה מזה. הבחירה בשפת השאילתה היא תחום נוסף של שיקול. שפת שאילתות מובנית (SQL) והרחבות שלה סיפקו למערכות יחסיות מנגנון גישה מבוסס פרדיקט. שפת שאילתת האובייקטים (OQL) היא גרסת אובייקט של SQL, המתוקננת על ידי ODMG, אך התמיכה בשפה זו דלה כרגע. שיטות פולימורפיות מציעות אלגנטיות חסרת תקדים בבניית שאילתה סמנטית לאוסף אובייקטים. לדוגמה,דמיין התנהגות פולימורפית עבורacccountנקרא isInGoodStanding. זה עשוי להחזיר את האמת הבוליאנית לכל חשבונות במצב תקין, ושקר אחרת. עכשיו דמיין את האלגנטיות של שאילתת אוסף החשבונות, היכן inGoodStandingשהיא מיושמת באופן שונה על בסיס כללים עסקיים, לכל החשבונות במצב תקין. זה עשוי להיראות כמו:

setOfGoodCustomers = setOfAccounts.query(account.inGoodStanding());

בעוד שכמה ממסדי הנתונים של האובייקטים הקיימים מסוגלים לעבד סגנון שאילתה כזה ב- C ++ וב- Smalltalk, קשה להם לעשות זאת עבור אוספים גדולים יותר (נניח 500+ ג'יגה) וביטויים של שאילתות מורכבות יותר. כמה מחברות מסדי הנתונים היחסיות, כמו אורקל ואינפורמיקס, יציעו בקרוב תחביר אחר מבוסס SQL כדי להשיג את אותה התוצאה.

התמדה וסוג

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

קנוניקליזציה ועצמאות שפה

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

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

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

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

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

התמדה של Java מקורי באמצעות סידור

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

// כתיבת "foo" לזרם (למשל, קובץ)

// שלב 1. צור זרם פלט

// כלומר, צור דלי לקבלת הבתים

FileOutputStream out = FileOutputStream חדש ("fooFile");

// שלב 2. צור ObjectOutputStream

// כלומר, צרו צינור והכניסו את הראש לדלי

ObjectOutputStream os = ObjectOutputStream חדש (out)

// שלב 3. כתוב לזרם מחרוזת ואובייקט

// כלומר תנו לזרם לזרום לדלי

os.writeObject ("foo");

os.writeObject (Foo חדש);

// שלב 4. שטוף את הנתונים ליעדם

os.flush ();

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

// קריאת אובייקט מזרם

// שלב 1. צור זרם קלט

FileInputStream in = FileInputStream חדש ("fooFile");

// שלב 2. צור זרם קלט אובייקט

ObjectInputStream ins = ObjectInputStream חדש (ב);

// שלב 3. הכרתי מה אתה קורא

מחרוזת fooString = (מחרוזת) ins.readObject ();

Foo foo = (Foo) s.readObject ();

סידור ואבטחת אובייקטים

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

התמדה עם שלמות עסקאות: הכנסת JDBC

מעוצב על פי SQL CLI של X / Open (ממשק רמת לקוח) והפשטות ODBC של מיקרוסופט, קישוריות מסדי נתונים של Java (JDBC) שואפת לספק מנגנון קישוריות למסד נתונים שאינו תלוי במערכת ניהול מסדי הנתונים הבסיסית (DBMS). כדי להיות תואם ל- JDBC, מנהלי התקנים צריך לתמוך לפחות ב- ANSI SQL-2 API ברמת הכניסה, שמעניק לספקי כלים ויישומים של צד שלישי מספיק גמישות לגישה למסד נתונים.

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

הנה תיאור ממשקי JDBC החשובים ביותר:

  • java.sql.Driver.Manager מטפל בטעינת מנהלי התקנים ומספק תמיכה בחיבורי בסיסי נתונים חדשים.

  • java.sql.Connection מייצג חיבור למסד נתונים מסוים.

  • java.sql.Statement משמש כמכולה לביצוע משפט SQL בחיבור נתון.

  • java.sql.ResultSet שולט בגישה לערכת התוצאות.

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

מאגרי מידע של אובייקטים והתמדה ב- Java

מספר פרויקטים מתמשכים בענף מציעים התמדה של Java ברמת האובייקט. עם זאת, נכון לכתיבת שורות אלה, PSE (מנוע אחסון מתמיד) של Object Design ו- PSE Pro הם רק חבילות בסיסי הנתונים מבוססות Java, מונחות האובייקטים, הזמינות (לפחות, שאני מכיר). עיין בסעיף משאבים למידע נוסף על PSE ו- PSE Pro.

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

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

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