פיתוח מערכות N-Tier מבוססות מידע היא משימה מאוד מאתגרת. ישנם נושאים רבים שיש להביא בחשבון לפני קבלת החלטות לגבי העיצוב מערכת ה- N-Tier הכוללים בין השאר מעקב אחרי שינויים בסביבת ה- client, עבודה עם טראנזקציות, מקביליות ועוד. במאמר זה נסקור את גישות הפיתוח המקובלות כיום על מנת לפתח מערכת N-Tier בעזרת Entity Framework.

גישות הפיתוח לאפליקציות N-Tier

ישנן ארבע גישות פיתוח עיקריות כאשר מפתחים מערכת N-Tier ומשתמשים ב- Entity Framework כבסיס לשכבת הגישה לנתונים:

• Change Set pattern
• Simple Entity pattern
• DTO pattern
• Self-Tracking Entity pattern

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

Change Set

גישת הפיתוח של Change Set היא ליצור מבנה נתונים אשר ניתן לשינוע (serializable) ומכיל את כל היישויות והנתונים הדרושים ליחידת עבודה אחת (unit of work). מבנה הנתונים אמור להכיל בתוכו מימוש של מעקב אחרי כל השינויים על כל הנתונים שהוא מכיל. דוגמא מאוד טובה לגישה הזאת בעולם הדוט נט הוא אובייקט ה- DataSet. הבעיות העיקריות בגישה הזו הן יצירת אילוצים משמעותיים על צד הלקוח אשר אינם מאפשרים להפוך את המימוש ל- interoperable (בפועל הלקוח יהיה חייב להשתמש בדוט נט) והעובדה שנוצר tight coupling בין שני tiers. ישנו מימוש עבור Entity Framework שנותן יכולות של Change Set ונקרא EntityBag אבל הוא כרגע לא נתמך ב- Entity Framework 4.

Simple Entity

בדומה ל- Change Set גישת ה- Simple Entity מאפשרת reuse ליישויות מה- mid-tier, אבל בשונה מ- Change Set בגישה זו המפתח לא עוטף את היישויות תחת מבנה נתונים מסובך אלא שולח לצד הלקוח יישויות פשוטות (POCO). בגישה זו מאפשרים שינויים רק על מאפיינים של היישות וכל פעולת שינוי פשוטה (הכנסה, עדכון ומחיקה) נתמכת במתודות בצד ה- mid-tier. במידה ויש צורך בפעולות יותר מורכבות כמו לדוגמא שינוי יחס בין יישויות או שילוב של כמו עדכונים יחדיו יהיה צורך לבנות מתודות בצד ה- mid-tier שיבצעו את הפעולות הללו. היתרון בשימוש בגישה זו הוא הפשטות שבה. החסרון העיקרי שבה הוא שהיא מצריכה ריבוי של מתודות בצד ה- mid-tier עבור כל תרחיש מורכב. הדבר יכול לגרום לעומס על הרשת כאשר פונים ל- mid-tier. ב- Entity Framework 4 תוספת הפיטצ'ר של POCO מאפשר לממש את הגישה הזאת די בקלות.

DTO

הגישה ההפוכה לגישת ה- Change Set. בגישת פיתוח זו יש הפרדה מוחלטת בין צד הלקוח לבין ה- mid-tier כאשר משתמשים ביישויות שונות עבור ה- mid-tier ומשתמשים ביישויות אחרות על מנת לשנע נתונים לצד הלקוח בעזרת ה- Data Transfer Objects עצמם. היתרון המובהק לשימוש בגישה זו הוא שאין צימוד בין ה- tiers ולכן כל tier יכול להתפתח בצורה נפרדת על פי לוחות זמנים נפרדים. כמו כן, ניתן לשמור על המידע שעובר בין ה- tiers בפורמט יציב בלי להתייחס לשינויים שמתרחשים בכל אחד מה- tiers. החסרון העיקרי בגישה זו הוא הזמן הנדרש לפתח את כל סוגי היישויות והצורך למפות מידע בין ה- DTO לבין היישויות שנמצאות ב- mid-tier או בצד הלקוח. Entity Framework 4 מאפשר מימוש של הגישה בצורה נוחה ובעזרת כלים כמו תבניות T4 שמפתחים יכולים לבנות ואשר יכולות למכן את התהליך של יצירת ה- DTO.

Self-Tracking Entity

גישת ה- STE מאפשרת שילוב של היתרונות בין שימוש ב- DTO לבין השימוש ב- Change Set. בגישה זו המפתח שולח לצד הלקוח יישויות אשר מכילות מנגנון מעקב אחרי שינויים מובנה. המנגנון הנ"ל אמור גם לעקוב לא רק אחרי שינויים ביישות הבודדת אלא גם בגרף יישויות. חסרון אחד של גישה זו הוא שעל מנת לבצע מיזוג של שני גרפי יישויות יהיה צורך לבנות מנגנון מיזוג חכם מה שבדרך כלל יותר פשוט לבנייה בגישת ה- Change Set. חסרון נוסף הוא עצם מנגנון המעקב אחר שינויים שיכול לסבך קצת את הקוד של היישות. Entity Framework 4 מכיל בתוכו מימוש של גישת STE על ידי תבנית T4 שניתן להפעיל על המודלים של Entity Framework.