آیا استفاده از EntityFrameWork برای پروژه های بزرگ واقعا مشکل ساز میشه؟

[valentine093]

باسلام خدمت اساتید محترممنبه صورت جداگانه از چند برنامه نویس حرفه ای شنیدم که گفتن EF برایپروژه های بزرگ جواب نمیده.حتی آخرین ورژنش.حالا میخواستم نظر شما اساتید رو بدونم.ازاینترنت هم جواب های ضد و نقیض پیدا کردم.اگه واقعا مناسب نیست پس مشکل Ado.Net برای پروژه های بزرگ رو چجوری میشه حل کرد
ممنون میشم اساتید راهنمایی کنن.

[Moien Tajik]

بستگی به کد نویسی خودتون هم داره .
شما میتونید بجای EF از Dapper استفاده کنید که در مقایسه با EF سرعت بیشتری داره ، اما دقت شما در Dapper تقریبا SP مینویسید و این خودش باعث دیرتر توسعه دادن برنامتون میشه .
میتونید Benchmark های هرکدوم رو ببینید و مقایسشون کنید که از کدوم استفاده کنید : https://www.exceptionnotfound.net/dapper-vs-entity-framework-vs-ado-net-performance-benchmarking/

[alireza_s_84]

باسلام خدمت اساتید محترممنبه صورت جداگانه از چند برنامه نویس حرفه ای شنیدم که گفتن EF برایپروژه های بزرگ جواب نمیده.حتی آخرین ورژنش.حالا میخواستم نظر شما اساتید رو بدونم.ازاینترنت هم جواب های ضد و نقیض پیدا کردم.اگه واقعا مناسب نیست پس مشکل Ado.Net برای پروژه های بزرگ رو چجوری میشه حل کرد
ممنون میشم اساتید راهنمایی کنن.


اتفاقا برعکس عدم استفاده از EF هم موجب اتلاف زمان و هم احتمال بروز خطا به دلیل "عدم نوشتن کوئری های بهینه" رو افزایش میده.
ببینید باید اول منظور از پروژه بزرگ رو معین بکنیم. مثلا به چی میگن پروژه بزرگ؟؟؟
پروژه ای که 380 جدول با متوسط 45 میلیون رکورد و متوسط افزودن 200 هزار رکورد در روز رو من با EF پیاده سازی کردم و الان هم نزدیک به دو سال داره کار میکنه و حتی یک مورد خطا هم گزارش نشده. در حالیکه تا قبل از EF و به دلیل علاقه خاصی که SPها داشتم و همیشه از مکانیزمی شبیه به Dapper و البته نزدیک به EF استفاده میکردم دچار مشکلات زیادی میشدم که واقعا هم اجتناب ناپذیر هستند.
از لحاظ سرعت اجرای کوئری طبیعی هست که ORM ها سرعتشون پایینتر هست چون به عنوان یک لایه بالای لایه اصلی داده عمل میکنن و دسترسی به لایه زیرین خود مستلزم زمان هست ولی باید همه فاکتورها رو در نظر گرفت.
در کل اگر نرخ واکشی و سرعت بالای اطلاعات (برای مثال سیستمهای بلادرنگ) مدنظر باشه خب طبیعی هست که سرعت هیچ ORM برای اینکار مناسب نیست ولی اگر سیستمهای معمول (حتی پروژه ای که من ذکر کردم) مدنظر باشه مطمئنا شما نه فقط دچار مشکل نمیشید که برعکس سبب جلوگیری از بسیاری از مشکلات هم میشه.
راه حل بعدی برای پروژه های خیلی خیلی خیلی بزرگی که تو ذهن شماست اینه:
پروژه رو با EF پیاده سازی و اجرا کنید. بعد که به انتهای کار رسیدین تمام کوئری های تولید شده توسط EF رو بصورت SP ذخیره و لایه دسترسی به داده رو با کلاس مورد نظرتون عوض کنید. این مورد هم خودم تجربه کردم و کلا زمان مورد نیاز برای تعویض لایه داده فقط 2 هفته زمان برد.
ایراد بزرگ EF:
در عملیات Update و Delete شما ابتدا باید رکورد رو پیدا و سپس "حذف یا آپدیت" کنید یعنی دوتا "دستور العمل" پر هزینه رو باید اجرا کنید در حالیکه میشه مستقیما اینکار رو با یک کوئری انجام داد که به سبب ماهیت EF باید خودتون دست به کار بشید و این عملیات رو انجام بدین.
نکته: تمامی دستورات Insert, Upadate, Delete رو میشه بصورت SP توی خود دیتابیس و توسط EF ذخیره کرد و تنها کوئری های Select رو نمیشه به SP تبدیل کرد.
نکته: شما میتونید SP و EF رو باهم ادغام کنید چون EF پشتیبانی کاملی از SPها داره.
یادآوری: SP منظور همون Stored Procedure هست.