مطمئنا خیلی جاها خوندین که استفاده از Repositroy و Unit of work اشتباه هست..چون خود DbContext حکم همین داستان رو داره.

این یک اشتباه رایج در مورد نحوه ی کار DbContext و الگوی Repository هست. مارتین فاولر در کتاب Patterns of Enterprise Application Architecture که در تعریف الگوی Repository میگه :


A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object
collection.

که مشخصا اشاره میکنه به اینکه Repository یک واسط بین Domain و Data Mapper هست که Domain همون مدلها و سرویسهاست و Data Mapper همون DbContext هست.
در واقع DbContext اطلاعات رو در حافظه ذخیره نمیکنه و برای اجرای هر عملیاتی به سراغ دیتابیس میره . اما Repository قراره داده هارو درون متغیرهای محلی ذخیره کنه که سرعت دسترسی به اونها بیشتر بشه. نقش Unit Of Work اینه که این حافظه ی موقت ایجاد شده رو زنده نگه داره و جلوی ازبین رفتنش رو بگیره تا بشه همیشه خیلی سریع به داده ها دسترسی داشت.

خروجی متدهای DbContext از نوع IQueryable هست. که در واقع یک کوئری هست و نه خود داده ها. یعنی داده ها قبل از اجرای متد وجود ندارن و در لحظه ای که خط داره اجرا میشه از دیتابیس جمع آوری میشن.
ولی در Repository از IList استفاده میشه. که نوع خاصی از آرایه هست که اطلاعات رو در حافظه نگه میداره. و همه ی کوئری های بعدی روی این حافظه انجام میشه .

استفاده از DbContext مثل دستگاه های آب سردکن لحظه ایه. یک مخزن آب دارن که وقتی شما شیر رو باز میکنید آب رو در مسیر سرد میکنه. که فشار زیادی به دستگاه میاره و مصرف بالایی هم داره. اما ریپوزیتوری مثل اینه که بطری های آب رو درون یخچال نگه داری و هر وقت لازم داشتی یکی رو باز کنی و بخوری.

دات نت محلی (NET Native)

وقتی با دات نت 1 تا 4.6 کار می کنید کدها بعد از کامپایل به زبان ماشین ترجمه نمی شوند بلکه به یک زبان میانه (Intermediate Language) تبدیل می شوند. وقتی برنامه را اجرا می کنید دات نت این زبان میانی را در لحظه به زبان ماشین تبدیل می کند که به این عمل ترجمه ی لحظه ای یا Just in time Compile گفته می شود. این عمل در بهینه سازی حجم فایلها و سرعت اجرا برنامه بسیار موثر است.

اما با ظهور گوشی های هوشمند و تبلت ها و با توجه به منابع محدود این دو استفاده از ترجمه ی لحظه ای روش مناسبی نیست و کارایی لازم را ندارد. در دات نت محلی یا Native با استفاده از عمل Ahead of time compile یا ترجمه ی پیاپیش کدها مستقیما به زبان ماشین تبدیل میشوند و زبان میانه حذف میشود .

کجاها می توانید از EF Core استفاده کنید ؟

https://github.com/codehaks/FileManagerDemo

پروژه ی نمونه ی کار با فایل و آپلود و دانلود در ASP MVC Core 2.0

آیا Stored Procedure از LINQ سریعتر است ؟

اخیرا در یک پروژه ی قدیمی از من خواسته شد سرعت تولید گزارشات را بالا ببرم.اجرای آن بیش از 5 دقیقه طول می کشید. مشکل اصلی این بود که بخش اصلی گزارش ها با SP برنامه نویسی شده بود . بعد از بررسی دقیق سورسها ساده ترین راهی که به نظرم رسید بازنویسی آن با LINQ درون #C بود. خروجی کار نتیجه ی جالب توجهی داشت. حالا گزارش در کمتر از 5 ثانیه تولید میشد. این یعنی سرعت کار بیش از 300 برابر شده بود.

جواب کوتاه سوال "بله" است. SQL دارای مکانیزم هایی است که به SP امکان میدهد همیشه چند برابر از LINQ یا Query های خارجی سریعتر عمل کند. اما سرعت همیشه ملاک برتری یک روش نیست. نوشتن SP نیاز به تخصص در T-SQL دارد. مهارتی میطلبد که خیلی از برنامه نویسان وب ندارند. خیلی راحت میتوانید یک SP بد بنویسید که از صد LINQ کندتر کار کند.

مسئله ی دیگر بروز رسانی و تغییر SP ها است. مدیریت کردن SP ها در درازمدت بسیار سخت تر از LINQ است. در بسیاری موارد زمان اجرای Query ها کسری از ثانیه است در نتیجه استفاده از SP چیز زیادی به سرعت سیستم اضافه نمیکند.

تنها زمانی باید به استفاده از SP فکر کرد که سرعت جمع آوری اطلاعات یک تنگنا یا اصطلاحا Buttleneck باشد.

افزونه تبدیل تاریخ میلادی به شمسی با کمک Extension Method ها در #C :

https://www.nuget.org/packages/Codehaks.PersianDateTime

برای استفاده از این افزونه ها کافیه پکیج Codehaks.PersianDateTime رو از طریق nuget نصب کنید. بعد هرجا نیاز به تبدیل تاریخ میلادی به شمسی داشتید ازش استفاده کنید :

DateTime.Now.ToPersianDate()
DateTime.Now.ToPersianDateTime()
DateTime.Now.ToFullPersianDate()
DateTime.Now.ToFullPersianDateTime()

این افزونه در ویو ها و کلاسهای سی شارپ قابل فراخوانیه و کار تبدیل تاریخ میلادی به شمسی رو راحت میکنه، ضمن اینکه خروجی از نوع string هست. سورس پروژه در آدرس زیر قابل مشاهده است :

https://github.com/codehaks/Codehaks.PersianDateTime

آمارهای مایکرسافت می گوید در حال حاضر بیش از نیم میلیون برنامه نویس از Net Core استفاده می کنند و استفاده از Core 2.0 پیشرفت چشم گیری داشته است.

طبق اعلام Scott Hunter مدیر پروژه ی Net Core پیش نمایس نسخه 2.1 این فریم ورک تا آخر این ماه عرضه میشود. او همچنین پیش بینی میکند نسخه ی اصلی2.1 تا تابستان آماده شود.

هنر بریدن ، چیدن و کوتاه کردن

وقتی تیمور لنگ شروع به کشور گشایی کرد هدفش فتح دنیا نبود، او فقط به قلعه ی بعدی فکر میکرد. عجیب آنکه سر آخر تا پشت دیوار چین پیش رفت . تنها چیزی که او را از ادامه ی پیروزی باز داشت مرگش بود.

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

سایت محصولات یکبار تولید نیست. ساده ترین سایت هم نیاز به بروز رسانی دارد. حتی اگر تکنولوژی تغییر نکند ، آمار بازدید زیاد نشود یا حادثه برای سرور رخ ندهد، خود کار فرما ایده های جدیدی خواهد داشت.

مهم نیست انتظار کارفرمای شما چیست. کار اول شما این است که از آن کم کنید. کارفرماها معمولا رویاهای بزرگی در ابعاد آمازون ، فیس بوک و یوتیوب دارند. به آنها یاد آوری کنید هدف اول باید فتح قلعه ی بعدی باشد. اینکه آیا در نهایت به دیوار چین میرسید یا نه به آینده بستگی دارد.

مقایسه زمان Build شدن ASP Core بین نسخه ی 2.0 و 2.1

بهبود روی پروژه های بزرگ (WebLarge) بسیار زیاد است. برای تست از Orchard CMS استفاده شده است.

مراحل توسعه و انتشار نرم افزار

وب اسمبلی استاندارد جدیدی است که امکان اجرای کد Nativeدر مرورگر را فراهم میکند. به زودی می توانید بجای جاوا اسکریپت با #C برای کلاینت برنامه نویسی کنید.