ראשי > פיתוח, שפת SQL > איך לבנות Data Access Layer כמו שצריך

איך לבנות Data Access Layer כמו שצריך

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

בחברה אחת שכזו נעשית חשיבה כיצד נכון בשבילם לכתוב את ה-DAL.

האפשרויות הן:

  1. כתיבת משפטי SQL בתוך הקוד. לרוב נבנה הטקסט של המשפט והוא נשלח לביצוע ל-DB.
  2. קריאה ל- Stored Procedures מתוך הקוד והעברת פרמטרים אליהם ומהם.
  3. שימוש ב-ORM או Object Relational Mapping כמו Hibernate או Entity Framework.

אופציה מספר 1 (SQL בתוך הקוד) היא הגרועה שבהם וזאת מכמה סיבות ואלו העיקריות שבהן:

  1. משפטי ה-SQL שבקוד אינם נבדקים בזמן קומפילציה ועלולים "להתעופף" בזמן ריצה אם התחביר שגוי.
  2. שינויים בסכימה (הוספת/ביטול עמודות, שינוי טיפוס נתונים, שינוי בשמות טבלאות וכו') גוררים שינויים בקוד. קשה למצוא את כל המקומות שיש לשנותם. ה-deploy בסביבת היצור חייב יהיה לשנות את הקוד שמעל ה-DB.
  3. השאילתות שנוצרות בקוד הן לרוב – שאילתות דינאמיות עם כל המשמעויות המתבקשות של בעיות ביצועים.

לאופציה מספר 2 (Stored procedures)  יש גם כן מגרעות (אבל פחות מאשר לאופציה מס' 1):

  1. קריאה לפרוצדורות היא סוג של יציאה מעולם האובייקטים לעולם רלציוני – מה ששובר את עקרונות עיצוב מונחה עצמים.
  2. במערכת בינונית ומעלה אפשר למצוא מאות ואפילו אלפי פרוצדורות. אי אפשר למצוא את הידיים ואת הרגליים בהם והרבה פעמים קורה שמפתח כתב stored procedure ולא ידע שמישהו אחר כתב את אותה פרוצדורה לפניו – רק עם שם אחר.
  3. הרבה פעמים הלוגיקה העסקית "מתפזרת" לתוך פרוצדורה ואז היא מצוייה גם בשכבת BLL וגם בשכבת ה-DAL.
  4. לא כל כך נוח לתכנת כל פעולת SQL בשני שלבים – פיתוח קריאה לפרוצדורה בשפה עילית ופיתוח הפרוצדורה בשפת ה-DB (כמו PL/SQL או T-SQL).

לאופציה מספר 3 (ORM) יש גם מגרעות:

  1. קוד ה-SQL שמחולל ע"י ORM עלול להיות לא יעיל בעליל. ככל שרמה הסיבוכיות עולה – הסיכוי שה-SQL שנוצר יהיה איטי גובר.
  2. עבודה עם ORM דורשת לימוד מעמיק של היכולות והמגבלות.
  3. קשה לנסח שאילתות מורכבות בממשק כמו LINQ או HQL. מה שהולך בקלות ב-SQL, הולך קשה ב-LINQ.

מה עושים?

לדעתי – יש לנסות לקחת את הטוב משתי האופציות 2 ו-3. כלומר – כן ליישם ORM – אבל לשלב אותו עם Stored procedure אותם יש לכתוב בשביל משימות שה-ORM מתקשה ליישם בצורה אופטימלית.

עיבוד טרנזקציות? נוח מאד ב-ORM. שאילתות מורכבות? לך על Stored Procedures וחבר אותם ל-ORM.

אשמח לשמוע על רעיונות נוספים.

Advertisements
  1. אין תגובות.
  1. No trackbacks yet.

כתיבת תגובה

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

הלוגו של WordPress.com

אתה מגיב באמצעות חשבון WordPress.com שלך. לצאת מהמערכת / לשנות )

תמונת Twitter

אתה מגיב באמצעות חשבון Twitter שלך. לצאת מהמערכת / לשנות )

תמונת Facebook

אתה מגיב באמצעות חשבון Facebook שלך. לצאת מהמערכת / לשנות )

תמונת גוגל פלוס

אתה מגיב באמצעות חשבון Google+ שלך. לצאת מהמערכת / לשנות )

מתחבר ל-%s

%d בלוגרים אהבו את זה: