גישה לבסיס נתונים

[sharpsharp]

שלום,

שפת תיכנות C#. תבנית עיצוב MVP. כולל גישה לבסיס נתונים.

יש לי את השכבות הבאות:

Model

- View

Presenter

BLL

DAL

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

ישנם שתי שכבות BLL -Business Logic Layer ו DAL - Data Access Layer.

בו ניקח למשל דוגמא:

יש לי בסיס נתונים הכולל טבלת Person המכיל נתונים כמו (שם פרטי, שם משפחה, ת.ז, תאריך לידה וכו')

כעת אני מעוניין לגשת לבסיס הנתונים:

בשכבת ה DALאני יוצר מחלקה בשם PersonProvider שממשת את הממשק IPersonProvider , מחלקה זו אחראית על התחברות ישירה לבסיס הנתונים ומבצעת כל מה שניתן לבצע, כמו הוספה של Person לבסיס נתונים, לשלוף Person המתאים לקריטריונים, לשלוף רשימה של Person שעונים על קריטריון מסויים וכו'.

כיוון שב DAL אני מתעסק עם Person אני חייב נגישות אל האובייקט הזה.

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

אז את המחלקה Person שממשת את הממשק IPerson שמתי בשכבת ה BLL בפרוייקט Entities.

בשכבת ה BLL יש לי מחלקות נוספות (בפרוייקט אחר מה Entities) כמו למשל PersonBLL שמחזיק מצביע לממשק IPersonProvider.

ברגע שצריך להביא אויבקט Person כמו למשל ישנה בקשה "הבא את Person עם ת.ז 1111". מתבצעת פניה ל PersonBLL.

getPersonByID - והוא פונה getPersonByID שנמצא PersonProvider . שניגש לבסיס הנתונים מוציא את המידע המתאים. יוצר אובייקט מסוג Person מחזיק ל BLL עד לבקשה הראשונה למשל באפליקציה.

למה בכלל חילקתי את זה בצורה הזו:

1. המטרה שלי ליצור שכבות על מנת ליצור חלוקת עבודה. שכל אחד יממש חלק.

- תיכנות הגישה לבסיס הנתונים (ה DAL יפותח ע"י מתכנת אחד)

- ה GUI יפותח ע"י מתכנת אחר.

- וה Core יתוכנת ע"י מתכנת אחר (הלויגקה של הGUI).

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

2. בגלל הצורך ביצירת אובייקטים גם ב DAL (אחרי קריאה מבסיס הנתונים) וגם בשאר חלקי תיכנות האפליקציה יש צורך באותם אובייקטים כמו Person. אז יש צורך שב BLL יהיה פרוייקט Entities שמכיל את כל האובייקטים שיווצרו ע"י בסיס הנתונים. כך ה DAL יצור אובייקט Person (ולכן חייב ה DAL להחזיק מצביע ל BLL מה שנראה לי מוזר ואולי לא נכון) וגם בשאר חלקי תיכנות האפליקציה יהיה אובייקט Person (כייון שהם מצביעים ל BLL).

3. ה BLL מחזיק בממשק IPersonProvider ולא במחלקה .PersonProvider וזאת כדי שאם יוחלט לשנות יום אחד את בסיס הנתונים למשל ל Oracle או סתם לפנות לקובץ שמכיל את הנתונים כל מה שיש לעשות זה ללכת לממש את IPersonProvider וזהו.

הבעיה היא שזה נראה לי אולי לא טוב שה DAL צריך להכיר את אובייקטים שהמערכת משתמשת, ולהצביע ל BLL.

אשמח להצעות... ולחוות דעת

[nitzanj]

אם ה-DAL מכיר את ה-BL וה-BL מכיר את ה-DAL אז אתה בבעיה כמובן. אף אחד לא ממש אמור להכיר את מי ש'מעליו'.

מבחינת התכנון שלך כל המערכת צריכה להכיר Person- במצב כזה אפשר פשוט לשים את Person בפרוייקט נפרד (הכוונה שלי לפרוייקט של VS).

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

בין אם זה לפרמטרים גלובאליים שכולם צריכים להכיר, או באמת למבני נתונים כאלה ואחרים (כמו ה-Person שלך).

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

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

[sharpsharp]

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

הבנתי ש MVP זוהי ארכיטקטורה מומלצת.

העניין הוא שיש לי צורך לפנות לבסיס נתונים לקבצים ולכן יש לי את הצורך ב DAL ו BLL וכדומנ.\\ה

בו למשל ניקח דוגמא

למשל יש לך טבלת Person בבסיס הנתונים ואתה רוצה לגשת אליה ויש צורךה להציג את נתוני המשתמש ב GUI.

(בא נאמר שהמשתמש רושם ת.ז של Person שהוא רוצה) לוחץ על כפתור ב GUI. ומבקש את פרטי ה Person והם מוצגים לו ב GUI

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

תוך שימוש ב MVP , DAL BLL Service, וכולה... (בכל מה שאתה משתמש)

אל תשכח לאמר לי היכן אתה מייצר את מחלקת Person ווהיכן היא יושבת באיזו שכבה. ואיך אתה מתייחס אליה בים השכבות כי לבסוף אתה צריך גם להציד את Person בGUi

[Woland]

הצעה שלי , בדומה למה ש NJMAN אמר לך , תייצר solution עבור כל אחת מהשכבות וגם solution עבור מה שנקרא base object (במקרה שלך persons ), כל שכבה צריכה להכיר רק את השכבה שמתחתיה וכולם צריכים להכיר את base objects . אם אתה רוצה לשלוף person תשלח id מה gui תשלוף מה db ותייצר את האוביקט ב dal , אם אתה רוצה להוסיף person אתה יכול ליצור את האובייקט ב gui ולשלוח אותו כלפי מטה.

[sharpsharp]

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

כיוון שיש צורך לממש את כל האובייקטים מראש.

מה שלא טוב,

בא נחשוב שיש מישהו אחד שיושב וכותב את ה DAL.

ומישהו שני שכותב את הלוגיקה

והאחרון שכותב את ה GUI.

זה לא ילך בצורה הזו.

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

והיכן למקם את האובייקטים.

אני רוצה שתיהיה תמיכה גם ב webservices חוץ מפניה לבסיס נתונים, וקבצי XML.

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

תודה

[nitzanj]

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

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

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

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

אני לא יודע בדיוק איך אתה מתכוון לעשות את זה, אבל בגדול (הכל זה במונחים של ויז'ואל סטודיו):

נניח יש לך Solution אחד לכל המערכת. בפנים יש לך Project שאחראי ל-DAL. בתוך הפרוייקט יש כל מיני מחלקות (קבצי CS מן הסתם). באותון אופן יש לך את הפרוייקט BL שלך, והפרוייקט GUI שלך. כל אחד זה פרוייקט נפרד לגמרי. כל פרוייקט מקבל project reference למי שהוא צריך להכיר (BL מכיר את ה-DAL וכו').

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

עכשיו אתה פשוט מוסיף את הפרוייקט הזה כ-project reference לכל השכבות שצריכות להכיר את הדברים הכלליים האלה. והפרוייקט common עצמו לא מכיל reference לשום דבר אחר, הוא 'עצמאי' נקרא לזה.

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

[sharpsharp]

אוקיי אז בא נאמר שאני הולך על הארכיטקטורה הבאה (כמו שהצעת):

שכבת DAL

שכבת BLL

ו שימוש ב MVP.

יש לי בסיס נתונים שמכיל 20 טבלאות. ויש לי StoredProcedure שדרכם מבקשים את המידע מהטבלאות.

למשל אם יש לי טבלת Person אני כותב StoredPreocedre שמקבל ID ומחזירה את הבנאדם שמתאים ל ID.

או למשל כל מי שגר בעיר תל אביב (אז יש StoredProcedure שמבצעת ומחזירה את כל האנשים שמתל אביב) ,

הרעיון שעומד מאחורי גישה ל StordProcedure הוא סוג של אבטחה, אני לא ניגש לטבלאות ישירות.ולא כותב בקוד שלי (בקבצי cs בפרוייקט) קוד של SQL. - למשל לשם מניעת SQLInjection.

1. מה אתה אומר על ההחלטה הזו?

חשבתי בנוסף ליצור מחלקה עבור כל טבלה או לפחות עבור כל נושא בנפרד. הכוונה למשל אם יש לי טבלת Person אני יוצר ב DAL מחלקה בשם PersonProvider שניגשת ישירות ל SQL (StoredProcedure) ומחזירה את נתונים. למשל שתי הפונקציות שציינתי למעלה ישבו ישבו באותו המחלקה. ב PersonProvider .

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

2. מה אתה אומר על הגישה הזו.?

3. הבנתי שאפשר גם להשתמש ב Linq to SQL האם זה עדיף על פני ADO.NET? מהניסיון שלך או של אחרים?

כעת לשכבת ה BLL.

בשכבה זו ישבו כל מחלקות ה Model (מה MVP). ואצור עבור כל DALProvider שהגדרתי למעלה Service למשל עבור PersonProvider אצור PersonService. שמטרתו ליצור אבסטרקציה מעל שכבת ה DAL. לשם יכולת החלפה של המימוש של ה Provider (אם למשל החלטתי לעבור לבסיס נתונים שונה) וכמובן כדי ליצור שכבה כללית שאם למשל יש נתונים של Person שאני צריך להביא ממקור אחר (למשל WebService או מקובץ XML) אז למשל ה PersonServiceיחזיק גם את IPersonProvider וגם נניח IPersonWebServiceProvider או IPersonXMLProvider ואז יש לי פה שכבה שמאגדת את כל הגישות למקורות שונים עבור Person. גם חשבתי לשים את ה Repository שארצה להגדיר ב Service עצמו. כך אני עושה עבור שאר הטבלאות באותו אופן כך שיש לי Service ים שונים שאני ניגש אליהם.

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

4. מה דעתך על זה? ואם יש לך הצעה? לגבי הארכיטקטורה כאן.

[sharpsharp]

?

[nitzanj]

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

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

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

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

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

בוא נניח שיש לנו פונקציה getChildrenForPerson - את המימוש שלה תכתוב פעם אחת, בין אם זה ב-PersonBL או ChildrenBL. לדעתי זה עניין שרירותי, פה או שם, לא ממש משנה. אם זה מתאים לך, אתה יכול לשים מתודה כזו בשניהם, כשאחת קוראת לשניה (כלומר יש מימוש ב-BL מסוים, וה-BL שלא באמת מממש בעצם קורא ל-BL הזה).

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

אישית אני לא מת על זה, אבל זה משהו שעושים.

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

[sharpsharp]

תודה על התשובות.

עוד שאלות.

1. האם שכבת ה service זה נחשב כ API שאני נותן להתממשקות עם ה BLL שלי לתוכנות חיצוניות. או/ו נחשב כשכבה שאני יוצר בשבילי כדי לאגד מספק ממשקים שמשיגים לי מידע של Person?

2. האם כדאי שאני אצור service כללי שמאגד בתוכו את כל הגישות לכל הממשקים. כך שבמקום שיהיה לי service ל Person ו service ל Childern וכך עבור כל טבלה או פרוצדוה. אעשה אחת שמאגדת הכל ורק אצטרך לפנות ל service הכללי? (ממש להראות ב service את כל המתודות)

או שה service יחזיק את כל השאר כמו למשל הוא יחזיק את PersonService, ChildrenService וכו.. ופניה ל Service הכללי תחזיר את אחד ה Service ים. למשל

Service.PersonService.getPersonById(id) ? או דרך אחרת.

[nigger84]

כשאתה אומר שכבת service, למה אתה מתכוון? wcf services?

לגבי ado.net או linq to sql:

אני יכול להגיד לך שבפרוייקטים שהקמנו אצלנו עבדנו ב- ado.net והוא עובד מעולה וגם קל לעבוד איתו. הבעיה העיקרית שלו היא כשאתה רוצה להעביר את ה data tables לאובייקטים. אם אתה מתכוון לעבוד עם data tables אז אין לך בעיה. (זה אגב פיתרון שכבר לא ממליצים עליו היום).

אם אתה רוצה לעבוד עם אובייקטים, ולעבוד ado.net אז יש לך כמה בעיות:

1. בכל שליפה של נתונים מה- DB אתה צריך להמיר את ה data tables ל- objects.

2. יהיה לך מאוד מסובך עד בלתי אפשרי לשמור שינויים של אובייקטים חזרה ל- DB בגלל שאין לך מנגנונים של ניהול שינויים(track changes)

יש לכל זה כמה פתרונות. העיקריים שבהם: nhibernate, ado.net entity framework.

אלו שתי טכנולוגיות שמאפשרות לעבוד עם אובייקטים מול DB טבלאי.

אם זה מעניין אותך אני יכול לפרט קצת על כל אחת.

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

לגבי שאר הדברים שהציעו לך למעלה,

אני גם מסכים שאתה צריך ליצור פרוייקט אחד שייקרא: Common.Entities

ובו יישבו היישויות. את הפרוייקט הזה כל שאר הפרוייקטים ייצטרכו להכיר.

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

ה- DAL אסור שיכיר את ה- BL .

[sharpsharp]

תודה nigger84 על התשובה.

1. כשאתה מתכוון שכיום לא עובדים עם data tables האם אתה מתכוון שלא מוציאים משם ישירות מידע ומכניסים לשם תוך גישה בשאר התוכנית ל data tabels?

אבל כן משתמשים ב dataTables ב DAL אבל מחוצה לו מתרגמים את ה data tables לאובייקטים? אין מנוס מלהשתמש ב data tables בתוך ה DAL.

לכך התכוונת?

2. כשאני מתכוון ל service אני יכול להתכוון לשני דברים שונים:

א. שכבת ה service שמאגדת את הגישות ל DAL וזה יושב בתוך ה BLL.

ב. שכבה שכן ניגשת ל wcf services ואז צריך ליצור שכבת אבסטרקציה.

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

נניח שיש לי בסיס נתונים הכולל טבלת Person המכיל נתונים כמו (שם פרטי, שם משפחה, ת.ז, תאריך לידה וכו')

בשכבת ה DAL אני יוצר מחלקה בשם PersonProvider שממשת את הממשק IPersonProvider , מחלקה זו אחראית על התחברות ישירה לבסיס הנתונים ומבצעת כל מה שניתן לבצע, כמו הוספה של Person לבסיס נתונים, לשלוף Person המתאים לקריטריונים, לשלוף רשימה של Person שעונים על קריטריון מסויים וכו'.

ואז אני מחזיר אובייקט Person.

באפשרות הראשונה: בשכבת ה BLL אני PersonService שיחיזק IPersonProvider (וזאת על מנת שאם ארצה לשנות את בסיס הנתונים אני אממש את IPersonProvider וזהו)

ומה Presenter אני אגש ל PersonService על מנת לקבל את המידע המתאים.

3. אולי השם service לא מתאים פה? אולי כדאי שם אחר?

4. במקרה שבו נאמר שאני צריך לקחת מידע משלים משני מקורות שונים למשל מבסיס נתונים ומ XML אז אני יכול ליצור PersonXmlProvider ו PersonDBProvider ואז להחזיק PersonProvider שיחזיק את שניהם ? מה אתה אומר על זה או שאולי כדאי בעיצוב קצת שונה?

5. באפשרות השניה: זה ליצור מחלקה PersonBLL (אולי יש לך שם יותר טוב ?) שמחזיקה IPersonProvider. ואז ליצור PersonService שמחזיק PersonBLL וחוץ מזה הוא יחיזיק גם מצביעים ל wcf services שקושרים ל Person נניח המחלקה PersonWcfProvider מחזירה Person מ wcf services כלשהו שאני מתממשק אליו. או שאולי כדאי שאני אצור את ה PersonWcfProvider ובכלל PersonBLL יחיזיק אותו?

מה אתה אומר?

אשמח מאוד אם תוכל לכתוב לי בכללי איזה מחלקה הייתה יוצר בכל שכבה (עבור הדוגמא שנתתי לעיל עם טבלת Person) ומי מחזיק את מי. בשכבת ה DAL, בשכבת ה BLL, אם הייתה צריך לגשת ל wcf services איזו מחלקה הייתה מוסיף ומי היה מחזיק אותה? תוך שאני צריך לממש חלק מהלוגיקה ב BLL. ואם תוכל להתייחס שיש לי מידע משלים משני מקורות שונים כמו XML ובסיס נתונים כמו שנתתי לעיל.

6. אשמח אם תפרט קצת על nhibernate, ado.net entity framework. ומה היתרונות והחסרונות של עבודה עם כל אחד? והכי חשוב מי מומלץ מביניהם?

תודה

[nigger84]

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

ממה שאני מבין כרגע, אתה לא סגור אם אתה צריך בכלל שכבת services (אני מדבר על wcf services).

אתה צריך לשאול את עצמך:

1. האם זאת הולכת להיות ארכיטקטורה של n-tier או לא. n-tier בסיסי אומר שיש לך שרת DB, שרת שחושף wcf services ו- client כלשהו שצורך את ה wcf services.

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

2. האם אין בעיה שה- client ידבר ישירות מול ה- DB ?אם אין בעיה כזאת אז אין לך צורך ב wcf.(במערכות רציניות לא עושים כאלה דברים, זה יוצר בעיות אבטחה בכך שה- clients צריכים לעבוד ישירות מול ה- DB)

3. עלות/תועלת - מערכות n-tier כמובן יקרות יותר, דורשות יותר זמן פיתוח, יותר שרתים ותצטרך להתמודד עם כמה בעיות שנדבר עליהם במידה ואתה צריך את זה.

ה- wcf הוא השכבה העליונה ביותר במודל ה BL שלך. התפקיד היחיד שלו הוא לענות לקריאות מה- clients ללכת ל- BL המתאים, לבצע מה שצריך ולהחזיר תוצאה ל- client. או כמו שאומרים אצלינו, wcf זה הצנרת

[sharpsharp]

אז הנה אני מגדיר את הצורך:

1. שרת בסיס נתונים שאני פונה אליו (זה לא משנה אם הוא יושב על שרת אחר. אני פשוט מתחבר אליו בשורת ה connection string אני שם את ה path אליו) אז אפשר לאמר שבסיס הנתונים יושב מקומית אצלי

2. י ש לי בנוסף קבצי txt ו XML שיש מידע שיושב שם שאני צריך להביא (כמו בבסיס הנתונים).

3. רוצה ליצור שכבת DAL. BLL ושאר התוכנית אני רוצה ששאר המתכנתים יקבלו API ל בסיס נתונים ויכלו לקבל את מידע שהם רוצים.

4. יש צורך לכתוב את זה בצורה שמי שיושב על בסיס הנתונים וכותב את ה DAL יוכל לעשות זאת במקביל לשאר המתכנתים שיושבים על שאר התוכנית.

5. אני משתמש ב MVP. מה שזה אומר שאלו שיושבים וכותבים את ה presenter צריכים את יכולת לפנות לבסיס הנתונים ולקבל את המידע שהם רוצים.

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

תודה

[nigger84]

אוקיי,

לפי מה שתיארת כנראה שאין לך צורך בשכבת services.

ה- ui יפנה ישירות ל- BL שיבצעו פעולות מול ה- DAL.

אני רגיל לקונבנציה הזאת:

אתה מגדיר Person שהוא entity שבו יש לך רק properties של person. (את person כל המערכת צריכה להכיר. לכן הוא יישב בפרוייקט משותף לכל המערכת)

אתה מגדיר PersonDataAccessor שיודע לבצע גישות ל- DB ולהחזיר person או לעדכן אותו.

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

השם controller לקוח מה MVC. זה מה שאני מכיר.

לגבי ה- DataTables:

כשאנחנו בחנו האם לעבוד עם data sets או עם entites קראנו במאמרים של MS שברוב המקרים מומלץ לעבוד עם entites ולא עם DS. אלא אם כן אתה מפתח מערכת מאוד קטנה. חפש בגוגל על הנושא ותמצא מאמרים.

אם אתה עובד עם ado.net יש לך 2 אופציות - לעבוד עם data sets בכל המערכת.זאת האופציה הקלה כי ה- data sets מנהלים את השינויים שלהם בעצמם.

אופציה שניה וקצת יותר מסובכת - להמיר את ה data sets לאובייקטים. וכמו שאמרתי פה יהיו לך בעיות רציניות להתמודד איתם, כי כשיגיע לך אובייקט של person לתוך ה- dal ותצטרך לעדכן אותו לא תוכל לדעת אם הוא כבר קיים בתוך ה- DB או שצריך למחוק אותו וכו'.

אנחנו עבדנו בשיטה של להמיר את ה- data set, ותאמין לי, זה לא תענוג גדול.

האופציה השניה כמו שאמרתי nhibernate או entity framework.

אלו שתי טכנולוגיות שעושות את ההמרה מה- DB ל- לאובייקטים בצורה אוטומטית (אחרי שאתה יוצר מיפויים בין האובייקטים לבין הטבלאות).

אני לא מכיר את ההבדלים לעומק כיוון שלא עבדתי איתם עדיין.

nhibernate זה פרוייקט open source שאם אני לא טועה הגיע בכלל מ java ואח"כ לקחו אותו גם ל- .net.

אולי מישהו פה יוכל לפרט עליו קצת יותר.

entity framework אני קצת יותר מכיר. זה טכנולוגיה של Microsoft. קצת מזכיר את ה typed data sets. אתה גורר טבלאות לתוך editor בתוך ה- visual studio רק שבמקום data sets נוצרים לך אובייקטים שמייצגים את הטבלאות. מאוד מזכיר linq to sql אבל יש לו יותר יכולות. מה גם ש Llinq to sql אני חושב שדי עוצר במקום ו- ef הולך להתפתח בגרסאות הבאות.

אם אתה הולך לפתח ב- vs 2010 אז זה ef בגרסא השנייה שלו. הם הכניסו שם הרבה שיפורים.

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

עריכה:

לגבי הפיתוח במקביל. כמו שאמרו פה, לא יעזור איך תפתח את זה, תמיד יהיו לך נקודות השקה בין המפתחים ובעיקר בהתחלה. מישהו יצטרך ליצור stubs ואת ה entities. אופציה שניה שאולי שווה לשקול היא שכל מפתח ייקח חלק לוגי במערכת ויפתח אותו קצה לקצה. לדוגמא מפתח אחד ייקח את person ויפתח את ה DAL שלו, את ה BL שלו, ואת ה UI שלו. ככה גם כל מפתח עושה הכל, מפתח ניסיון בכל הטכנולוגיות, וגם לא משתעמם אחרי שפיתח 30 classים של DAL

עריכה 2:

אם אתה רוצה לקרוא על ה EF יש פה מאמרים ו videos טובים להתחלה:

http://msdn.microsoft.com/en-us/data/aa937723

מקווה שעזרתי.