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

[cd123]

שלום,

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

תודה רבה,

 

[Avi300]

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

בנוסף, במידה ובהמשך התוכן ייקרא על ידי ajax, json יותר חסכוני מבחינת תעבורה.

 

[Aharono]

מצטרף לכל מילה של אבי, רק מה שאני לא מצליח להבין, למה לשמור את המידע כקובץ ולא בdb בצורה מסודרת? בשביל מקרים כאלו בדיוק db נועד...

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

 

[ורד69]

מצטרף לכל מילה של אבי, רק מה שאני לא מצליח להבין, למה לשמור את המידע כקובץ ולא בdb בצורה מסודרת? בשביל מקרים כאלו בדיוק db נועד...

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

מתעניינת בשילוב .net עם mongodb, אשמח לפירוט

 

[cd123]

מצטרף לכל מילה של אבי, רק מה שאני לא מצליח להבין, למה לשמור את המידע כקובץ ולא בdb בצורה מסודרת? בשביל מקרים כאלו בדיוק db נועד...

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

אם אני מבינה ממך אז mongoDB הוא מסמך שישמור לי מספר גדול של אובייקטים בפורמט של json במסמך אחד, נכון?

 

[Aharono]

Mongodb הוא Non Sql db (דהיינו בסיס נתונים שאינו מבוסס על SQL, בשונה מ: MS-SQL, Mysql ודומיהם).

מבנה ה db מתחלק ל collections (מקביל לטבלאות) שכל collection זהו בעצם אוסף של documents (מקביל ל row) שכל דוקיומנט, זהו בעצם אובייקט json.

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

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

ברמה הטכנית, שליפת המידע נעשית בעזרת אובייקטים של json (בדוט נט עטפו את זה יפה דווקא בעזרת generics ו predicates). לדוגמה, נניח שיש:

    public class User
    {
        public User()
        {

        }

        public int Id { get; set; }

        public string Name { get; set; }

        public string Email { get; set; }

        public DateTime DateOfBirth { get; set; }
   }

שליפת משתמש העונה לשם "Aharono" תיעשה כך:

            MongoClient dbClient = new MongoClient("mongodb://localhost:27017");

            IMongoDatabase db = dbClient.GetDatabase("<DbName>");
      
            IMongoCollection<User> userCollections = db.GetCollection<User>("User");

            User user = await userCollections.Find(User => User.Name == "Aharono").SingleAsync();

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

שליפת מידע של כל ה collection נעשית באופן דומה וגם העדכון....

מס' לינקים מעניינים למתעניינים:

וידאו כללי שמסביר על מונגו (מתנצל, זה יוטיוב): https://www.youtube.com/watch?v=pWbMrx5rVBE
ספציפי לסי שארפ: https://docs.mongodb.com/ecosystem/drivers/csharp/

ולינק שהם עצמם מפנים אליו שכדאי להסתכל עליו: https://blog.oz-code.com/how-to-mongodb-in-c-part-1/


זה הבסיס, ואידך זיל גמור... בהצלחה

 

[Avi300]

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

 

[s976]

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

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

 

[מ.ש.]

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

סתם שאלה.
מה ההבדל בין זה לבין EF?
או שזה פשוט (סוג של) EF שהוא Code First?

 

[Aharono]

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

כמו שכתבתי קודם, למונגו אין בכלל סכימה של db, שהרי כל document יכול לקבל אובייקט שהוא, ממילא כל המנגנון של CodeFirst הוא רק ל sql dbs (וכמו שכתבתי קודם לכן).

אמנם ה Driver API של מונגו בהחלט עושה שימוש דומה לEF ב property בעזרת reflection על מנת לדעת את השם של הproperty ולבקש את השדה הנצרך.

מקווה שעזרתי