سرعت کدوم تکنولوژی بیشتر است ؟ ( Entity freamwork یا Ado.net )

[hosseinrasouli]

خیلی از مهندسین میگن که linq to entity freamwork به دلیل اینکه کوئریها را به sql تبدلیل کرده و بعد اجرا می کند نهایتا از ado.net کندتر است .
ولی بعضی از مهندسین هم میگن که چون linq کوئری های مناسبتری نسبت به ado.net تولید می کند سرعت linq to entity سریعتر است و برای پروژه های بزرگ با ساتار داده ایی پیچیده linq t entity بسیار مناسب تر از ado.net است.

مهندسیناگه دیدگاهی نسبت به این موضوع دارند بگویند تا ما هم از این سر درگمی در بیاییم.

[mahdad sepah]

من خودم ترجیح میدم از linq استفاده کنم اصلا برام مهم نیست سرعت اش که به نظرم سرعتش بد نیست

[mehdi.mousavi]

سلام.
مایکروسافت فناوری های متفاوتی رو برای دسترسی به داده ها طی سالهای گذشته ارائه کرد، از DAO به RDO و سپس ADO و در نهایت ADO.NET... وقتی ADO.NET معرفی شد، بنظر رسید که مایکروسافت به تکنولوژی مورد نظرش رسیده، بنابراین فناوری جدیدی برای دسترسی به داده ها ارائه نکرد و فقط اقدام به گسترش ADO.NET کرد. Entity Framework فقط توانایی های ADO.NET رو بالاتر می بره و مکانیزمهای جدیدی برای دسترسی به داده ها و پردازش Result Set ها، در اختیار توسعه گر قرار میده. اگر با DataSet ها کار کرده باشید، می دونید که استفاده از DataSet ها در یک Domain Model کابوس بود و عموما موفقیتی در این زمینه حاصل نمیشد. اگر هم موفقیتی وجود داشت، Maintenance کد نوشته شده واقعا دشوار بود. از طرفی، نیاز به مکانیزم هایی بود که امکان جداسازی Model از Database رو به ما بده، تا ارتباط کدها و بانک، Loosely Coupled بشه، بدین ترتیب ما قادر خواهیم بود تا فارغ از ساختار بانک، business object های خودمون رو داشته باشیم.

خوشبختانه اضافه شدن این امکانات، امکانات موجود رو از ما نگرفت. اگر به هر دلیلی نیاز دارید تا داده ها رو توسط DataReader بگیرید (در EF)، می تونید از EntityClient استفاده کنید. EF کلاسی به اسم EntityDataReader داره که از همون DbDataReader و SqlDataReader ای که در ADO.NET استفاده می کردید، Derive شده. بنابراین جاهاییکه نیاز به Materialize کردن Object ها ندارید (یعنی تبدیل Result Set ها به Business Object های خودتون) می تونید از EntityClient API ها در EF برای استفاده از داده های خام سود ببرید. همچنین، دست شما در استفاده از Stored Procedure ها در EF کاملا بازه، SP هایی که بصورت جداگانه می تونن Call بشن، یا بعنوان بخشی از فرآیند Update/Insert/Delete شدن یک رکورد از Entity ی مورد نظر... بنابراین، به نظر من مقایسه سرعت ADO.NET و EF صحیح نیست، اگر چه شما می تونید براحتی در EF شرائطی رو پیش بیارید که Query های غیر کارآمد تولید بشه، اما این ضعف EF نیست.

در نهایت، توصیه من EF هستش (البته فقط نسخه 4.1 و نه نسخه های قبلی، چون در نسخه های قبلی برخز از کارهای ساده با پیچیدگی های زیادی همراه بود)، بشرطیکه Entity Framework رو خوب بشناسید و به Query های تولید شده اون دقت کنید. اگر Query تولید شد مورد نظر شما نبود، اونوقت می تونید به دیگر روشهای موجود در EF روی بیارید و همون کاری رو که می خواستید توسط ADO.NET انجام بدید، توسط امکاناتی که EF در اختیارتون قرار میده انجام بدید.

موفق باشید.

[firoozi90]

اینکه کاملا مشخصه entity framework سرعتش بیشتره.با این تکنولوژی خط کداتون خیلی کمتر میشه و قطعا مرتبه زمانی بهینه هست. و شک نکنید و حتما برید دنبال entity و لذت برنامه نویسی با پایگاه داده رو کاملا حس کنید.

[mehdi.mousavi]

اینکه کاملا مشخصه entity framework سرعتش بیشتره.با این تکنولوژی خط کداتون خیلی کمتر میشه و قطعا مرتبه زمانی بهینه هست. و شک نکنید و حتما برید دنبال entity و لذت برنامه نویسی با پایگاه داده رو کاملا حس کنید.

سلام.


منظور دوستان "سرعت پیاده سازی" نبود، "سرعت اجرای کدها" بود.
به صرف کمتر شدن تعداد خطوط کد که نمیتونیم بگیم سرعت اجرا افزایش پیدا کرده. اگر واقعیت رو بخواهیم در نظر بگیریم، اندکی افت سرعت خواهیم داشت (بخاطر Mapping هایی که باید انجام بشه و لایه هایی که اضافه شده اند)، اما این افت سرعت اونقدر ناچیزه که میشه ازش صرف نظر کرد.

موفق باشید.

[davoodrm666_666]

همونطور که دوستان اشاره کردند EF تکنولوژی بهینه شده Ado.net هستش که یکی از قابلیت هاش linq to entity می باشد از نظر کارایی مسلما مقداری سرعتش از Ado.net پایین تره اما از نظر نوشتن کوئری های تمیز 100% نسبت به نوشتن کوئری به صورت دستی از کارایی بالاتری برخورداره.

[rahmatr]

اگر واقعیت رو بخواهیم در نظر بگیریم، اندکی افت سرعت خواهیم داشت (بخاطر Mapping هایی که باید انجام بشه و لایه هایی که اضافه شده اند)، اما این افت سرعت اونقدر ناچیزه که میشه ازش صرف نظر کرد.

با توجه به مطلب زیر، افت سرعت قابل توجه است :
http://blogs.msdn.com/b/adonet/archive/2012/02/14/sneak-preview-entity-framework-5-0-performance-improvements.aspx
http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-68-19-metablogapi/6724.ExecutionTimeResults_5F00_thumb_5F00_347404AB .png

کسانی که سرعت برایشان خیلی خیلی اهمیت دارد می توانند از orm هایی مانند SqlMapper (https://github.com/SamSaffron/dapper-dot-net/blob/master/Dapper/SqlMapper.cs) استفاده کنند که به Ado.net خیلی نزدیک است.

[mehdi.mousavi]

با توجه به مطلب زیر، افت سرعت قابل توجه است

Compiled Query ها رو نگاه کنید، تفاوتش با ADO.NET ناچیزه. ضمن اینکه در مطلب مزبور، صحبتی از فعال بودن Tracking /NoTracking، Entity ها به میون نیومده که اگر این مساله رو هم در نظر بگیریم (و اگر در این اندازه گیری ها در نظر گرفته نشده باشه)، سرعت LINQ to Entities بازهم افت پیدا خواهد کرد. اما به نظر من این دلیل خوبی برای عدم استفاده از EF نیست. عرض کردم، اگر EF رو خوب بشناسید، تفاوت سرعت محسوسی با ADO.NET تجربه نخواهید کرد.

البته این نکته رو هم در نظر بگیرید که 6 برابر شدن سرعت EF5 نسبت به نسخ قبلی، فقط وقتی رخ میده که همون LINQ Query ی قبلی، مجددا اجرا بشه. در حالیکه در سناریوهای عادی، اینطور که ادعا شده، کارایی برنامه 67% بهبود پیدا میکنه، اما این باز هم (به اعتقاد من) بستگی به سناریویی داره که در اون اندازه گیری رو انجام میدیم.

در هر حال، ممنون بابت معرفی لینک فوق الذکر...

موفق باشید.

[angel5980]

برای پروژه هایی مثل پروژه های حسابداری که گزارش گیری زیاد و محاسبات زیاد دارن آیا میشه از EF استفاده کرد ؟ واقعا گیج شدم که چه کنم !

[shervin57]

من همیشه از کلاس های Repository و ADO.NET (http://ADO.NET) و Stored Procedureها برای مدیریت داده ها استفاده میکنم. اما اکثرا از Entity Framework استفاده میکنن ،در پیاده سازی وب سایت ها یی با ترافیک بالا که دسترسی به منابع محدود و اشتراکی زیاد است آیا باز هم نیازی به استفاده از ORM ها هست؟

[sky_in_iran]

اما این تکنولوژی مشکلاتیم داره به عنوان مثال برای اتصال به sql اگر جدول فیلد کلیدی به غیر int داشته باشه مثلا nvarchar به مشکل میخوره یا اینکه اگر از identity استفاده کنی مشکلاتی پیش میاد بسیار در web گشتم حتی msdn اما راهی برای حل این مشکلات ندیدم

[aryanss]

لینک خوبی بود
من تازه کارم و بیشتر برای راحتی از linq to sql استفاده میکنم اما اینجور که به نظر میاد برای پروژه های بزرگ با پایگاه داده میلیونی باید به ado رجوع کرد
فکر میکردم ef سرعتم بهینه کرده باشه که انگار اینطور نیست
فقط نمیدونم چرا الان که هر روز پایگاهها بزرگتر میشن چرا دنبال سرعت بالاتر نیستن ؟ حتی سریعتر از ADO