גם טלריק עוברים ל"Code only"

וקרא את התגובות שם...

אנשים בהיסטריה.
אגב, השתמשת ב ORM שלהם? אני מאמין שהוא טוב, אבל לאחרונה נראה לי שכל השוק עבר ל EF, לא?
בשנים עברו הייתי חובב של ORM's איזוטריים וחדשניים כמו MyGeneration, EntitySpaces, ואפילו Massive של רוב קונארי, והקודם שלו ששכחתי את שמו, אבל ראיתי שאני בודד במערכה, וכל מקום שאני מגיע אליו כולם משתמשים רק ב EF, אז ויתרתי.
תעדכן אותנו אם יש חדשות בתחום.
מסכים שהדזיינרים זה זוועה. רק קוד צריך להיות הדרך.
 
אכן,, אני משתמש בORM שלהם

מעלות:
1. הORM של טלריק [להלן DA] מהיר יותר וזה ניכר מאד באתחול הראשוני, זמן הטעינה של EF ארוך מאד!
2. האוספים הם IQueryable ולא DbSet, ולכן קל לעשות מוקינג. אמנם היתרון הזה אמור להתבטל בEF7 שתומך בהזרקת InMemory במקום הDb האמיתי.
3. פרופיילר מעולה שמנטר את השאילתות שיוצאות לDB.

חסרונות:
1. אין תמיכה באסינכרוניות. [אפשר לעשות Task.Run, אבל אתה עלול להתנגש בת'רד אחר שבדיוק סגר את הקונקשיין]
2. מיפוי CodeOnly איננו חלק ואוטומטי כמו בEF. תכל'ס, בסוף אני מוצא את עצמי ממפה את כל השדות ולא סומך על הדיפולטים.
3. לDA אין דבר מקביל לCollection.Local. זה משמעותי ביישומי Desktop כמו WPF או WinForms. הנה דוגמא פשוטה בEF:
myContext.Products.Load();myDataGrid.ItemsSource = myContext.Products.Local;
ואז, אם מוסיפים או מוחקים רשומה בDataGrid, זה מסתנכרן לקונטקסט.
לעומת זאת, בDA האוספים הם IQueryable, ובכלל אין להם Add וDelete, [מחיקה או הוספה של אובייקטים נעשית מול הקונטקסט], ולכן עלי ליצור ObserveableCollection ולסנכרן אותו מול הDB.


סתם, בשביל האינטלגנציה, שתי הספריות עובדות בצורה שונה. EF יוצר מאחורי הקלעים מחלקה יורשת מהמודל שלנו, ולכן אסור שהמודל יהיה sealed [בדיבוג רואים שהטייפ של המחלקה הוא Product_HGRRHH65674HGRHER].
לעומת זאת, DA איננו יורש מהמודל, אלא פורץ אותו ושותל בו מתודות.

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

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

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

אחרי 3 שנות עבודה ב EntitySpaces הייתי מומחה לכלי הנ"ל ברמה של היכרות אישית עם הכותבים שלו. אני בחרתי את הכלי, הייתי בהתחלה מפתח יחיד ואחר כך ר"צ במקום ההוא, והכל היה טוב. ואז עזבתי את המקום ההוא, וראיתי שכל העולם עובד ב EF ולי אין שמץ מושג בו. הייתי בצרות.
עד כמה הנפוצות והתמיכה שיש לכלי, העובדה שהוא מיינסטרים, צריכה להשפיע עלינו בבחירת כלים?
במילה תמיכה אני לא מתכוון רק לתמיכה טכנית פורמלית, אלא לנוכחות מסיבית בסטאק, עשרות קורסים בכל אתרי הקורסים, וכן הלאה. כדי לבחור בכלי חריג (לא מקובל, לא נפוץ), צריך כנראה להיות מספיק בעל ביטחון עצמי, ואולי גם ידע.
&nbsp
 

Royi Namir

New member
אל תהיה מקובע עם ידים על העיניים

EF הוא כלי נח , קל ועקודת הלמידה שלו היא יחסית גבוהה.
אבל הוא לא מתאים לכל אירגון.
תיכנס מחר לחברה שעובדת עם הרבה מאד TRAFFIC ותגיד לי אם הם עובדים עם EF.
אני לא צריך להגיד לך איפה EF מבחינת ביצועים לעומת אחרים :

https://github.com/StackExchange/da...ping-over-500-iterations---poco-serialization

http://blog.dontpaniclabs.com/post/2014/05/01/Speed-Comparison-Dapper-vs-Entity-Framework

עוד עניין זה הדינמאיות.

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


בקיצור אני לא בא להגן על אף טכנולוגיה.

אבל להגיד שכל העולם ב EF - ממש לא מדוייק.

מזכיר לי שכל העולם עבד ב WCF בזמנו לגבי HTTP
ופתאום כולם ב WEBAPI. או ב NODE
 
לא

עברתי לטלריק משתי סיבות:
1. היתה לי בעיה מסוימת עם EF. עיין כאן. [URL]http://www.tapuz.co.il/Forums2008/ViewMsg.aspx?ForumId=831&MessageId=175462129[/URL] [את הפתרון לבאג מצאתי בדיעבד: קונפיגורציה בקוד ולא בconfig]
2. לEF יש תלות בגירסת .net, ואז כתבתי ל.net 4 או 3.5

ולא, זה לא מפריע לי, כי אין לי הרבה תלות בORM. פעולות CURD פשוטות, עובדות בצורה די דומה, ואם מישהו ירצה להחליף ORM זה לא מסובך, במיוחד אם עובדים CodeOnly.

לעניות דעתי, סוגיית הביצועים שroyi העלה, איננה חסרון בEF. הרי אף מוצר איננו מבוסס על הברקה גאונית במיוחד, וכולם עושים הרבה קוד מלוכלך ועוד הרבה reflection. ולכן, המשוואה פשוטה: ביצועים מהירים = פחות פיצ'רים ותכונות.
 
למעלה