در Ef Core معادلی برای WillCascadeOnDelete(False) وجود داره ؟
نظرات مطالب
بازنویسی سطح دوم کش برای Entity framework 6
جهت اطلاع
کتابخانهی مطلب جاری برای EF Core نیز بازنویسی شد. اطلاعات بیشتر
کتابخانهی مطلب جاری برای EF Core نیز بازنویسی شد. اطلاعات بیشتر
First it is important to recognize that the .NET Framework is not the same as .NET Core. The .NET Framework is effectively now in maintenance mode , and all innovation is occurring in the open source .NET Core now and into the future. So step one to remaining relevant is to understand .NET Core (and the closely related .NET Standard).
بازخوردهای دوره
استفاده از Async و Await در برنامههای ASP.NET MVC
با توجه به : محدودیت پردازش موازی اعمال در EF «پردازشهای Async در Entity framework 6»
راهکار موجود استفاده از چندین Context میباشد ایا شما این روش را توصیه میکنید یا پیشنهاد خاصی برای پردازش موازی و در نتیجه افزایش کارایی دارید؟
استفاده ار async در فیلتر سفارشی چگونه امکان دارد با توجه به این لینک ؟اگر بخواهم از چندین Context و قابلیت پردازش موازی در در فیلتر سفارشی استفاده کنم دچار مشکل میشوم
راهکار موجود استفاده از چندین Context میباشد ایا شما این روش را توصیه میکنید یا پیشنهاد خاصی برای پردازش موازی و در نتیجه افزایش کارایی دارید؟
استفاده ار async در فیلتر سفارشی چگونه امکان دارد با توجه به این لینک ؟اگر بخواهم از چندین Context و قابلیت پردازش موازی در در فیلتر سفارشی استفاده کنم دچار مشکل میشوم
در مطلب تکمیلی «یک دست سازی ی و ک در برنامههای Entity framework 6» روش دیگری برای اینکار معرفی شدهاست. در این حالت تمام کوئریهایی که توسط EF صادر میشوند و تمام پارامترهای آنها پیش از ارسال به بانک اطلاعاتی، تحت کنترل قرار میگیرند (هر دو حالت کوئریهای select و یا insert/update/delete توسط interceptorها در اختیار هستند و نه فقط حالت insert/update/delete مطلب قبلی).
نظرات مطالب
EF Code First #1
- «دریافت خروجی کامل NET Tips.»
- برای مثال خروجی کامل بحث Entity Framework در پوشهی Tags واقع شده: (^)
- بانک اطلاعاتی سایت هم برای دریافت موجود است؛ به همراه Viewer آن: (^)
- در پوشهی LearningPaths، خروجیهای اختصاصیتری تهیه شدهاند. برای مثال این خروجی اختصاصی و انتخابی EF Code First است: (^)
- برای مثال خروجی کامل بحث Entity Framework در پوشهی Tags واقع شده: (^)
- بانک اطلاعاتی سایت هم برای دریافت موجود است؛ به همراه Viewer آن: (^)
- در پوشهی LearningPaths، خروجیهای اختصاصیتری تهیه شدهاند. برای مثال این خروجی اختصاصی و انتخابی EF Code First است: (^)
نظرات مطالب
کوئری هایی با قابلیت استفاده ی مجدد
من یک دور بازخوردهای شما را خواندم اما متوجه موردی که برای شما ابهام ایجاد کرده نشدم.
آیا شما از Entity Framework استفاده میکنید؟ اگر پاسخ مثبت است، خود EF لایهی Repository را پیاده سازی کرده است، و این پیاده سازی یک IQueryable جهت انجام Queryهای متفاوت در اختیار شما قرار میدهد. شما میتوانید مستقیما از DbContext سمت لایهی سرویس استفاده کنید و دادهها را جهت استفاده برای استفاده کنندهی لایهی سرویس فراهم کنید.
لایهی سرویس باید دادهها را درون حافظه برگرداند، نه اینکه یک IQueryable برگرداند که استفاده کننده آن را اجرا کند.
از Repository در لایهی سرویس استفاده کنید.
نظرات مطالب
مروری بر چند تجربهی کاری با SQLite
سلام،
بله. تا این حد رو خوب جواب میده. البته مکانیزمهای کش کردن اطلاعات رو باید خودتون در نظر داشته باشید و پیاده سازی کنید.
ضمنا استفاده از SQL Server Compact Edition را هم مدنظر داشته باشید (اگر کار شما فقط ویندوزی است)؛ نسخهی جدید آن قرار است از Entity framework پشتیبانی کند و مشکلات استفاده چند کاربری را هم نخواهد داشت و برای ASP.NET بهینه سازی شده؛ هر چند برای SQLite هم اکنون پروایدر EF موجود است.
بله. تا این حد رو خوب جواب میده. البته مکانیزمهای کش کردن اطلاعات رو باید خودتون در نظر داشته باشید و پیاده سازی کنید.
ضمنا استفاده از SQL Server Compact Edition را هم مدنظر داشته باشید (اگر کار شما فقط ویندوزی است)؛ نسخهی جدید آن قرار است از Entity framework پشتیبانی کند و مشکلات استفاده چند کاربری را هم نخواهد داشت و برای ASP.NET بهینه سازی شده؛ هر چند برای SQLite هم اکنون پروایدر EF موجود است.
پاسخ به بازخوردهای پروژهها
عدم سازگاری با EF
- یک مثال جدید Entity framework که در آن lazy loading و dynamic proxies فعال است به مجموعه مثالهای PdfReport اضافه کردم: (^)
- همچنین برای اینکه dynamic proxies سبب بروز stack overflow exception نشود نحوه استخراج خواص تو در تو توسط پارامتر dumpLevel محدود شد. به این ترتیب وجود dynamic proxies سبب نخواهد شد تا کلاسهایی که به یکدیگر ارجاع دارند n میلیون بار توسط EF وهله سازی شوند!
این تغییرات فعلا در SVN موجود هستند.
- همچنین برای اینکه dynamic proxies سبب بروز stack overflow exception نشود نحوه استخراج خواص تو در تو توسط پارامتر dumpLevel محدود شد. به این ترتیب وجود dynamic proxies سبب نخواهد شد تا کلاسهایی که به یکدیگر ارجاع دارند n میلیون بار توسط EF وهله سازی شوند!
این تغییرات فعلا در SVN موجود هستند.