در ادامه پست قبلی به معرفی ابزاری برای Navigate/Browse کردن بین کد های C# می پردازیم

ابزار SourceBrowser ابزارییست برای راحت سازی Navigate کردن بین کد های C# که یک Solution سی شارپی یا VB.Net ایی را میگیرد و فایل های استاتیک Html ایی تولید می کند که حاوی کد های سلوشن شماست و قابل Navigate کردن بین کد هاست
اگر هنوز متوجه طرز کار آن نشده اید بهتر است سایت های زیر را که خروجی و حاصل این ابزار است را مشاهده کنید :

1- https://referencesource.microsoft.com (.NET Framework source online)
2- http://source.roslyn.io (Roslyn source online)
3- https://source.dot.net (.NET Core source online)
4- https://aspnetsource.azurewebsites.net (unofficial ASP.NET Core 1.0 source)

این ابزار بیشتر برای کسانی مفید است که کتابخانه یا فریمورک سی شارپی دارند و قصد دارند سورس کد خود را جهت راحتی بیشتر در Browse کردن در اختیار عموم قرار دهند

لینک ریپازیتوری و توضیحات بیشتر :
https://github.com/KirillOsenkov/SourceBrowser
_______________
@IranAspMvc

الگوی Repository و Unit Of Work روی EF؛ خوب یا بد؟!
http://bit.ly/2D9Bk3k

🔰 الگوی Repository پیشنهاد می کنه لایه ی واسطی بین لایه بیزینس/منطق برنامه و لایه دسترسی به دیتابیس ایجاد بشه و کد های لازم برای انجام عملیات روی دیتابیس داخل اون نوشته بشه. این لایه نحوه دسترسی به پایگاه داده را از لایه های بالایی پنهان می کنه و لایه های بالایی برای اجرای دستورات و یا فراخوانی داده ها باید از طریق این لایه درخواست های خودشون رو مطرح کنند.
درنتیجه برای جداسازی و ایزوله کردن نحوه دسترسی به داده، اون ها رو داخل Repository می میگذارند و لایه های بالایی بدون درگیر شدن با جزئیات نحوه دسترسی به داده ها، فقط متد های ریپازیتوری رو فراخوانی می کنند
در این الگو برای هر یک از Domain Model (کلاس های معادل جداولمون) نیاز هست تا یک کلاس Repository جدا ساخته شود و این مخزن مسئولیت ساخت کوئری های مرتبط را به عهده خواهد گرفت.

🔰 الگوی Unit Of Work هم یکی از الگوی های رایج هست و هدفش اینه که، چندین عملیات در قالب یک درخواست و یک Transaction روی دیتابیس اعمال بشه؛ نه اینکه به ازای هر تغییر و هر بار افزودن و حذف داده ها، بلافاصله و تک به تک، داده ها را به سمت پایگاه داده ارسال کنیم. چرا که این امر هم موجب کاهش کارایی و مصرف منابع خواهد شد و هم ممکن است در حین ثبت داده ها ناگهان خطایی رخ دهد و باقی تغییرات در پایگاه داده منعکس نشوند و این یعنی تراکنش‌های ناموفق یا پاره ای (partially-executed) که نهایتا به یکپارچگی و صحت داده‌ها صدمه می‌زند.

جالبه بدونین Entity Framework یک پیاده سازی کامل از این 2 الگو هست چرا که هم جزئیات و فرایند اجرا کوئری و عملیات دیتابیسی را داخل DbSet های Context متمرکز کرده (مانند Repositoy)
و هم توسط مکانیزم ChangeTracker، تمام عملیات لازم (افزودن، اپدیت اشیای ویرایش شده و یا حذف شده و...) رو توسط متد SaveChanges به صورت یک جا روی دیتابیس اعمال میکنه (مانند UOW)
حتی در داکیومنت خود ماکروسافت نیز، کلاس DbContext رو اینگونه معرفی میکنه:

A DbContext instance represents a combination of the Unit Of Work and Repository patterns ...

حال اینکه بعضی ها اصرار دارند روی EF (که خود پیاده سازی کاملی از Repository و UnitOfWork هست) یک بار دیگه این 2 الگو رو پیاده سازی کنند، یک باور اشتباه هست، چرا که درک صحیح و کاملی از این الگو ها و EF ندارند.

🔰 ولی چرا استفاده از الگوی Repository و Unit Of Work روی EF روش مناسبی نیست؟

1️⃣ انتزاع روی انتزاع اضافه کاریه!
همون طور که قبلا گفتیم EF پیاده سازی کاملی از این دو الگو هست و افزودن این 2 الگو روی آن، "دوباره کاری" ایی هست و اصلاحا بهش میگن انتزاعی روی انتزاع دیگر (Abstraction of an Abstraction) که تازه باعث میشه یه سری از قابلیت های EF رو از دست بدیم چرا که پیاده سازی ما به کاملی و یکپارچگی خود EF نیست! و عملا قابلیت های "خاص و ویژه" EF رو از دست میدیم.

2️⃣ جایگزین کردن ORM همیشه معقول نیست!
یکی دیگه از دلایلی که برنامه نویسان برای استفاده از Repository میارند اینه که ما میتونیم براحتی ORM پروژه رو تغییر بدیم.
وقتی شما از یک اینترفیس IRepository تو کل پروژتون استفاده میکنین باعث میشه بتونین کلاس پیاده سازی کننده این اینترفیس رو با یک کلاس دیگه (که همین اینترفیس IRepository رو پیاده سازی کرده) جایگزین کنین؛ مثلا یک بار میشه اون رو توسط EF پیاده سازی کنین و بار دیگه توسط یک ORM دیگه (مثلNHibernate) و چون هر دو اینها یک اینترفیس مشترک (IRepository) رو پیاده سازی کرده اند می توان بدون تغییر در کد ها، براحتی یکی را جایگزین دیگری کرد. (البته در واقع این مزیت نه به لطف Repository، بلکه به لطف استفاده از Interface به جای یک کلاس مشخص به دست میاد)
نکته مهم اینه که این مزیت زمانی مفیده که احتمال میدین ORM پروژه تغییر کنه، در غیر این صورت الکی خودتون رو به دردسر انداختین.
به شخصه توی ده ها پروژه ای که انجام دادم هیچ موقع ندیدم ORM یه پروژه عوض بشه، ولی همیشه دردسر این روش رو داریم به جون میخریم و نهایتا چیزی به جز پیچیده تر شدن کد ها و کمتر شدن خوانایی اونها و کند شدن سرعت توسعه، چیز خاصی نصیبمون نمیشه.

ادامه در پست بعد 👇
@IranAspMvc

http://bit.ly/2D9Bk3k
3️⃣ محرومیت از قابلیت های ویژه EF
متاسفانه همین مزیت بالا یک عیب هم محسوب میشه؛ چرا که پنهان سازی EF پشت یک اینترفیس با خواص و متد های محدود، شما رو از دستیابی به تمامی قابلیت های یک ORM مثل EF محروم میکنه و فقط میتونین از متد های اون اینترفیس (IRepository) استفاده کنین. (مثلا SelectAll و SelectById و...) ولی دیگه نمیتونین از متد ها و قابلیت های خاص EF مثل Entry یا ChangeTracker یا استفاده کنین.
در واقع واسه این که بتونیم یه ORM رو با یه ORM دیگه جایگزین کنیم، حتما باید توی اینترفیس IRepository مون از ویژگی های مشتریک این دو استفاده کنیم، تا قابل جایگزین کردن باشن و گرنه اگر از ویژگی های خاص یه ORM داخلش استفاده کنیم، چون ORM دوم، این ویژگی های خاص رو نداره، پس عملا نیمتونه این اینترفیس رو پیاده سازی کنه و این یعنی از دست دادن یک سری ویژگی خاص و مهم یک ORM!
نکته دیگری که هست اینه که تعویض ORM پروژه (حتی با رعایت الگو های Repository و UnitOfWork) عملا امکان پذیر نیست و انجامش بیش از اون چیزی که فکر میکنین مشکل ساز میشه چرا که هر ORM پیازه سازی خاص خودش رو برای دستورات Linq داره، یعنی ممکنه یه کوئری Linq ثابت، توی 2تا ORM، دو جواب متفاوت برگردونه!
حتی بعضی متد های خاصی توی یه ORM هست که اصلا توی دیگری وجود نداره، حتی معادلی هم نداره.
نکته: البته که خود EF طوری پیاده سازی شده که با تغییر Provider مربوطه میشه دیتابیس پروژه رو عوض کرد ولی مشابه مشکلات بالا، درعمل، تعویض Database پروژه هم با چالش هایی همراهه و براحتی امکان پذیر نیست.

4️⃣ دقیقا چه فایده ای داره؟!
در گذشته که ORM های قدرتمند امروزی وجود نداشت، برای انجام عملیات روی دیتابیس باید کدهای زیادی نوشته می شد (از جمله : باز کردن کانکشن – نوشتن کوئری مورد نیاز – اجر روی دیتابیس – گرفتن خروجی کوئری - بستن کانکشن - و...)
پس به جای اینکه توی کد لایه های بالا، تمامی کد های ارتباط با دیتابیس رو بنویسیم میومدیم و از Repository استفاده میکردیم (همون DAL قدیم)
ولی الان توی EF همه این ها داخل متد Add یک DbSet محصور شدن و عملا صدا زدن متد Add برابری میکنه با اون 10 خط کدی قبلا که برای ارتباط با دیتابیس و انجام عملیات باید مینوشتیم
شاید این سوال هم براتون پیش اومده باشه که چرا باید داخل Repository متد Add ایی بنویسم که کار خاصی نمیکنه و فقط داره متد Add خود DbSet های EF رو صدا میزنه؟! پس دقیقا چه فایده ای داره؟! چرا اصلا از Add خود EF DbSet استفاده نکنیم؟!

5️⃣ محدودیت بی فایده!
فرض کنید میخواهید ریپازیتوری ایی بنویسید که برنامه نویس لایه های بالاتر رو محدود به استفاده از متد های مشخصی بکنید (که خودتون در ریپازیتوری تعریف کردین)
بنابراین مجبورید به ازای هر حالت خاص یک متد مشخص بنویسید مثل FindStudentByEmail، FindStudentById، FindStudentByName و...
بدین صورت برنامه نویس لایه های بالاتر محدود به استفاده از (فقط) همین متد ها میشه و دیگه نمیتونه Student رو بر اساس فیلتر دیگری (مثلاPhone) واکشی کنه
این محدودید خودش ممکنه به یک معضل تبدیل بشه، چرا که یا برنامه نویس نمیتونه اون واکشی خاصی که میخواد رو انجام بده یا شما مجبورید به ازای تمام حالات متد های مختلفی برای اون بنویسید که این یعنی افزاین حجم کدها به مرور، کاهش خوانایی و سادگی پروژه و همچنین کاهش سرعت توسعه
حال اگر ریپازیتوری نبود، برنامه نویس میتونست خودش از dbContext.Students استفاده کنه هر طور که مایل هست اطلاعات رو واکشی کنه یا عملیاتی رو انجام بده.

❇️ خب پس دیدیم که Repository و UnitOfWork روی EF، آنچنان چنگی هم به دل نمیزنه
ولی... شخصا پیشنهاد میکنم ازش استفاده بکنین حتما! (به شرط اینکه درست پیاده سازی بشه)
حالا اینکه" چرا و چگونه"، در پست بعدی وقتی مزیت هاشو دیدم می فهمید

@IranAspMvc

❇️ توی پست های قبلی دیدیم که منطقا استفاده از Repository و Unit Of Work روی Entity Framework اشتباهه ولی عملا میتونه مفید باشه به شرطی که :

1️⃣ صرفا به دید یک Abstraction بهش نگاه کنیم
مثلا فرض کنید تا الان استراتژی حذف شما به صورت Physical (حذف واقعی از دیتابیس) بوده و اکنون میخواین اون رو به حذف Logical (حذف منطقی توسط IsDelete) تغییر بدین. در این صورت باید تمام جا هایی که مستقیما از متد Remove خود DbSet استفاده میکردین رو تغییر بدین و این تغییر در یک پروژه بزرگ دردسر زیادی رو به همراه داره، در صورتی که استفاده از یک Abstraction کار رو بسیار ساده میکرد
درواقع به جای اینکه مستقیما با DbContext و DbSet ها سرو کار داشته باشیم بهتره یک لایه انتزاعی (Abstraction) روی اون ایجاد کنیم و همه جا از اون Abstraction استفاده کنیم، یعنی به جای اینکه در همه جای پروژه متد Remove خود EF رو صدا بزنیم، اون رو داخل کلاس Repository نامی بنویسیم و همه جا متد Delete ریپازیتوری رو فراخوانی کنیم. این باعث میشه اگه یه روزی لازم شد متد Delete ریپازیتوری رو سفارشی کنیم و تغییر بدیم، اون تغییر تو کل پروژه اعمال بشه، چرا که تو کل پروژه از متد Delete ریپازیتوری استفاده کردیم.
به همین ترتیب اگر نیاز به سفارشی سازی متد های دیگر (مثلا Add یا Update) دارید (مثلا اعمال اعتبارسنجی خاص به هنگام افزودن و ویرایش یا لاگ گرفتن تغییرات به هنگام ویرایش و... ) فقط کافیه متد های اون رو داخل Repository تغییر بدین و نه اینکه مجبور باشین تو کل پروژه کد هاتون رو تغییر بدین.

2️⃣ قابلیت های ویژه EF رو از بین نبریم
اگر به صورت معمول از Repository و Unit Of Work استفاده کنیم (یعنی اکثر همین مثال هایی که در وب موجود هست) باعت میشه قابلیت های ویژه EF رو از دست بدیم و نتونیم از اون ها استفاده کنیم
درواقع وقتی EF DbContext رو پشت Unit Of Work و DbSet های اون رو پشت Repository مخفی میکنیم، عملا میتونیم "صرفا" از متد هایی که داخل اون Repository تعریف کردیم استفاده کنیم (یعنی فقط از متد های Add/Delete/Update/Select)
چرا که داخل ریپازیتوری مون، متد یا خاصیتی برای استفاده از قابلیت های ویژه EF مثل ChangeTracker , Entry و ... تعریف نکردیم
پس باید طوری از Repository استفاده کنیم که اکثر قابلیت های EF رو قابل استفاده بگذاریم و بلااستفاده کردن ویژگی خاص اش رو به حداقل برسونیم
مثلا داخل Repository، دسترسی به خود DbSet رو فراهم کنیم
یا مثلا داخل Unit Of Work، دسترسی به شی Database، ChangeTracker و Property های مهم DbContext و نیز متد های مهم اون از جمله Entry و ... رو فراهم کنیم
بدین ترتیب هم از Abstraction استفاده کردیم و هم قابلیت های ویژه EF رو مخفی و بلااستفاده نکردیم.

3️⃣ از Repository جنریک استفاده کنیم
اصل DRY یا همون Dont Repeat Yourself تاکید میکنه به جای اینکه کد های مشابهی رو چندین بار در جا های مختلف پروژه تکرار کنین، یک بار یه جا تعریفش کنین و بقیه جا ها صرفا اون رو فراخونیش کنین
اگر از Generic Repository استفاده نکنین مجبورین به ازای هر کلاسی که به مدل پروژ اضافه میکنید یک ریپازیتوری مختص آن نیز بسازید که دقیقا همان کد های CRUD در آن تکرار شده و این علاوه بر تکرار کد ها (نقض DRY) یعنی کند تر شدن سرعت توسعه.
در صورتی که میتونین به جای اون از Generic Repository استفاده کنید تا الکی کد های تکراری تولید نکنین منتها متد های اون رو virtual تعریف کنین که هرموقع به سفارشی سازی نیاز داشتین با override کردن متد های کلاس Generic Repository در کلاس های مشتق شده از اون، کار سفارشی سازی رو انجام بدین.
بدین ترتیب هم از تکرار کد ها جلوگیری کردیم و هم امکان سفارشی سازی متد ها رو داریم
البته بعضیا میگن جنریک پروژه رو کند میکنه، باید خدمتتون بگم این حرفا رو کلا از ذهنتون بریزید دور؛ تاثیرش خیلی خیلی ناچیزه و در برابر مزیت اش اصلا منطقی نیست ازش استفاده نکنیم.

http://bit.ly/2PKUF1w

پس دیدیم که چرا استفاده از Repository و Unit Of Work روی EF به صورت "معمول (مثال های رایج)" اشتباهه و فهمیدیم بهترین حالت پیاده سازی Repository چیه، انشالا در پست های آینده، یه نمونه پروژه همراه با پیاده سازی اصولی این 2 الگو، آماده و در دسترس تون قرار میدم

@IranAspMvc

به عنوان نکته نهایی هم بهتره به سوال زیر جواب بدیم

لایه Service چیه و چه تفاوتی با Repository داره؟
اصولا Repository برای این نیست که منطق برنامه (Business Logic) رو پیاده سازی کنه. در واقع Repository صرفا لایه "سترسی به دیتابیس" هست که و نه بیشتر؛ و این لایه سرویس هست که باید منطق برنامه (Business Logic) رو پیاده سازی کنه، درنتیجه میدونه چه موقع به چه Repository هایی فرمان های CRUD رو بده تا منطق برنامه پیاده سازی بشه.
اصولش اینه که به جای اینکه منطق برنامه اتون رو داخل کنترولر و اکشن تون بنویسین؛ اون ها رو داخل لایه سرویس پیاده سازی کنین و داخل اکشن فقط متد های لازم رو از سرویس فراخوانی کنین، بدین ترتیب هم باعث میشه منطق شما از لایه Presentation جداسازی و ایزوله بشه و هم کد های اکشن هاتون به شدت کاهش پیدا میکنه و ساده میشه

@IranAspMvc

❇️ باور های غلط و رایجی در مورد Unit Of Work وجود داره که بعضا افراد رو به اشتباه میندازه
پس بهتره ببینیم اصولا کارش چیه و دقیقتر بررسیش کنیم

در واقع کار اصلی Unit of Work اینه که لیست تمامی object (رکورد) هایی که :
1-اضافه شده اند (Insert)
2-تغییر کرده اند(Update)
3-حذف شده اند(Delete)
رو در خودش نگه داره و اصطلاحا اونها رو "Track" (ردیابی) کنه
و سپس در یک تراکنش به دیتابیس (یک درخواست به دیتابیس در قالب یک Transaction) همه موارد بالا رو روی دیتابیس اعمال کنه.
و این دقیقا همون کاریه که در Entity Framework (به اختصار EF) در DbContext توسط مکانیسم ChangeTracker اتفاق میافته
اصل Unit Of Work اینه و خود EF به صورت کامل اون رو پیاده کرده و پیاده سازی یک Unit Of Work دیگه روی اون "یک کار اضافی" هست
ولی کاری که به صورت معمول انجام میشه و البته مفید هم هست اینه که یک Abstraction (یک لایه انتزاعی) روی DbContext ایجاد میکنیم و به جای اینکه مستقیما با DbContext سر وکار داشته باشیم، با اون Abstraction سرو کار داریم.
این باعث میشه اگه یه روزی لازم بود تغییری رو روی DbContext اعمال کنیم، چون در همه جای پروژه از اون Abstraction (که معادل DbContext هست) استفاده میکنیم، تغییراتمون تو کل پروژه اعمال بشه. *در واقع فقط فایده اش همینه.
به همین صورت استفاده از Repository هم روی EF اشتباه هست (چرا که EF خودش پیاده سازی کاملی از Repository و Unit Of Work) هست. ولی در اینجا هم استفاده از یک Abstraction روی DbSet ها (همون ریپازیتوری های داخل EF DbContext) یک کار مفید هست و باعث میشه اگه یه روزی خواستیم تغییری روی مثلا متد Add یک ریپازیتوری اعمال کنیم، چون در همه جا از اون Abstraction استفاده شده، تغییرمون توی کل پروژه اعمال بشه.
در کل اگه به "معنای اصلی" Repository و Unit Of Work بخوایم اون رو برای EF پیاده کنیم کار اشتباهی هست چرا که EF پیاده سازی کاملی از این دو هست
ولی کاری که مفید هست و پیشنهاد میشه استفاده از Repository و Unit Of Work به صورت یک Abstraction روی DbContext و DbSet ها در EF هست
اون چیزی که پیشنهاد میشه توی هر درخواست وب (Scope)، یک DbContext داشته باشیم (و نه چندین dbContext) اصطلاحا بهش میگن
الگوی "Context Per Request" یا "Session Per Request"
که اینکار نه توسط Unit Of Work و یا حتی خود EF بلکه توسط سیستم تزریق وابستگی و در اصل توسط IOC Container ها اتفاق میافته
درواقع IOC Container هست که میدونه باید برای هر درخواست (یا اصولا Scope)، فقط و فقط یک DbContext ساخته بشه (به جای اینکه چندین DbContext ایجاد بشه!)
اگه بخوایم دقیق تر بحث درخواست و Scope رو باز کنیم باید بگیم که Scope یک "محدوده" هست که وقتی ایجاد میشه، اشیایی که درون اون ایجاد میشوند داخل همون Scope (محدوده) قابل استفاده هستند و در واقع "زنده" هستند و پس از پایان اون محدوده (Scope)، تمام اشیایی که در اون Scope ایجاد شده اند نیز "میمیرند" (در واقع Dispose میشوند و از بین میروند)
البته تمامی این حرف ها "فقط" برای اشیایی صادق است که Lifetime (بازه عمر) آنها به صورت Scope تنظیم شده باشند.
حال جالبه بدونین که IOC Container میاد و در ابتدای یک درخواست وب (Request)، یک Scope ایجاد میکنه و در پایان اون درخواست وب، اون Scope رو از بین میبره (در نتیجه تمام اشیایی آن Scope هم از بین میروند)
در این حالت وقتی ما DbContext رو به صورت Scope (درواقع با Lifetime یا همون بازه عمر برابر با Scope) تعریف میکنیم، اتفاقی که میافته اینه که IOC Container در ابتدای هر درخواست، یک Scope ایجاد میکنه و درنتیجه DbContext ما هم (که قبلا به صورت Scope تنظیم شده است)، فقط و فقط یک نسخه از آن داخل Scope مربوطه (که اول درخواست ساخته شده) ایجاد میشه؛ در نتیجه طی اون Scope ما هر چندبار هم که DbContext رو فراخوانی کنیم، توسط سیستم تزریق وابستگی، "فقط و فقط" همون یک نسخه اولیه به ما ارجاع(پاس) داده میشه و در این حالت الگوی Context Per Request تحقق میابد
در پایان درخواست وب هم، چون Scope مربوطه ازبین میره، تمامی اشیای داخل آن(ایجاد شده توسط آن Scope) نیز از بین میروند از جمله همین DbContext ما و درواقع در پایان درخواست، DbContext ما هم Dispose میشه

اگه میخواین بیشتر با الگوی Unit Of Work اشنا بشین مقاله زیر رو مسعود بهرامی عزیز بخونین
http://refactor.ir/2017/05/11/unit-of-work/

اگه دوست داشین میتونین تعریف خود مارتین فاولر رو هم در مورد Unit Of Work بخونین
https://martinfowler.com/eaaCatalog/unitOfWork.html

@IranAspMvc

توضیحات کامل در مورد الگو های Repository و Unit Of Work و استفاده از اونها به همراه Entity Framework + مزایا و معایب

https://news.1rj.ru/str/IranAspMvc/586
https://news.1rj.ru/str/IranAspMvc/587
https://news.1rj.ru/str/IranAspMvc/588
https://news.1rj.ru/str/IranAspMvc/589
https://news.1rj.ru/str/IranAspMvc/590

*پیشنهاد میکنم همشو بخونین و بعد تصمیم بگیرین
@IranAspMvc

❇️از اپدیت ها و انتشار های مهم چند روز گذشته میشه به موارد زیر اشاره کرد:

1️⃣ منتشر شدند NET Core 2.1.6. و NET SDK 2.1.500
تغییرات این نسخه بیشتر در جهت رفع باگ های گذارش شده و پایداری بیشتر بوده و نکته خاصی درش دیده نمیشه
.NET Core November 2018 Update - November 13, 2018
https://github.com/dotnet/core/blob/master/release-notes/2.1/2.1.6/2.1.6.md

2️⃣ منتشر شد Visual Studio 2017 version 15.9.2
]چند روز پس از انتشار نسخه 15.9.0 که بهبود های قابل توجهی از لحاظ افزایش سرعت و همچنین رفع باگ های قبلی داشت، نسخه 15.9.1 و 15.9.2 در جهت رفع باگ های گذارش شده این ورژن منتشر شد
Visual Studio 2017 version 15.9 Release Notes
https://docs.microsoft.com/en-us/visualstudio/releasenotes/vs2017-relnotes?1592#-visual-studio-2017-version-1592

3️⃣ معرفی شد NET Standard 2.1
حدود یک سال از معرفی NET Standard 2.0 میگذره و قراره در نسخه جدید یعنی NET Standard 2.1، بیش از 3 هزار API جدید اضافه بشه. نکته مهم اینه که این ورژن حتی در نسخه Net Framework 4.8 هم پیاده سازی و پشتیبانی نخواهد شد.
این ورژن توسط نسخه های Net Core 3.0 و ورژن های بعدی Xamarin, Mono و Unity قراره پیاده سازی و پشتیبانی بشه
Announcing .NET Standard 2.1
https://blogs.msdn.microsoft.com/dotnet/2018/11/05/announcing-net-standard-2-1/


❇️ در حال حاظر داغترین موضوعات در زمینه اپدیت های و انتشار های مهم حوزه دات نت (که به شخصه هم دنبالشون میکنم) موارد زیر هستند:
1️⃣ .NET Core 3.0
2️⃣ C# 8.0
3️⃣ Visual Studio 2019

@IranAspMvc

علاوه بر تغییر آیکون Vistal Studio 2019 نسبت به 2017، تغییرات ظاهری دیگه ای هم انجام شده که ظاهر ویژوال استادیو رو جذاب تر کرده.

در لینک زیر میتونین تغییرات UI/UX ایی بیشتری رو مشاهده کنین :

https://blogs.msdn.microsoft.com/visualstudio/2018/11/12/a-preview-of-ux-and-ui-changes-in-visual-studio-2019/
_____
@IranAspMvc

وبینار یک روزه API نویسی اصولی و حرفه ای در ASPNET Core

برخی سرفصل ها :
- پیکربندی و استفاده از Swagger در ASPNET Core
- تست نویسی و داکیومنت نویسی حرفه ای (Testing & Documenting)
- اعتبار سنجی خودکار (Validation)
- مدیریت استثنا ها (Exception Handeling)
- نسخه گذاری اصولی (Versioning)
- رعایت Best Practice های API نویسی
- رعایت اصول امینیتی (Security)
- پیاده سازی یک معماری حرفه ای و اصولی برای API نویسی
- و...

برگزار کننده : کامیونیتی دات نت تاک (DotNetTalk)

زمان : پنج شنبه 8 آذرماه - ساعت 09:00 الی 17:00

کد تخفیف 20 درصدی مخصوص اعضای کانال :
iranaspmvc20
فقط برای 15 نفر ثبت نام کننده اول

*بروزرسانی
اینم آخریش
کد تخفیف ۳۰ درصدی:
dotnettalk30

لینک ثبت نام :
https://evnd.co/Zr32J
________________
@IranAspMvc

سلام دوستان
استقبال از این وبینار بسیار زیاد و بیش از حد تصورمون بود و کد تخفیف قبلی (در کمتر از 2 ساعت) تموم شد!
واسه همین جا داره یه تشکر ویژه بکنم بابت حمایت و استقبال شما عزیزان که هم به ما انرژی و امید میده و هم باعث میشه ما با قدرت و کیفیت بیشتری ادامه بدیم
خلاصه خواستم تشکر کنم که دیدم که تشکری بهتر از یه کد تخفیف دیگه :)

کد تخفیف جدید (20 درصد تخفیف برای 20 ثبت نام کننده اول)
aspcore_webapi
واسه دوستاتون بفرستین تا این یکی هم تموم نشده :دی

*بروزرسانی
اینم آخریش
کد تخفیف ۳۰ درصدی:
dotnettalk30

@IranAspMvc

توی وبینار "API نویسی اصولی و حرفه ای در ASPNET Core" چه چیزایی یاد میگیریم؟
بشنویم از زبان مدرس که میگه هدف این رویداد اینه که شما به "خدایگان API" تبدیل بشین که اگه نشدین، حداقل به مربته "پیامبری API" تبدیل میشن!

زمان : پنج شنبه 8 آذرماه - ساعت 09:00 الی 17:00
برگزار کننده : کامیونیتی دات نت تاک (DotNetTalk)
کد تخفیف 30 درصدی : dotnettalk30

لینک ثبت نام :
https://evnd.co/Zr32J
______________
@IranAspMvc

امکانات جدید C# 8.0 با بوی هوش مصنوعی!

نسخه major بعدی C# 7.3 که C# 8.0 خواهد طبق برنامه‌ریزی به همراز .Net Core 3.0 ریلیز خواهد شد و امکان آزمایش آن در Visual Studio 2019 Preview وجود خواهد داشت.
امکانات جذابی که به این زبان اضافه شده در لینک زیر شرح داده‌شده که به عنوان خلاصه می‌توان به امکانات زیر اشاره کرد:

- Nullable Reference Types

string? s = null;

- Async Streams

await foreach (var result in GetResultsAsync()) 
{ 
    if (result > 20) yield return result; 
}

- Ranges and Indices

Index i1 = 3; // number 3 from beginning 
Index i2 = ^4; // number 4 from end 
int[] a = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 }; 
Console.WriteLine($"{a[i1]}, {a[i2]}"); // "3, 6"
var slice = a[i1..i2]; // { 3, 4, 5 }

- Recursive Patterns

if (p is Student { Graduated: false, Name: string name })

- Target-Typed New Expressions

Point[] ps = { new (1, 4), new (3,-2), new (9, 5) }; // all Points

وقتی نام تایپ قابل استنتاج است نیازی نیست نام کلاس هنگام new کردن مشخص شود!


به نظر می‌رسد با توجه به تمرکز جدید مایکروسافت روی هوش مصنوعی، امکاناتی که در این نسخه به زبان اضافه شده، بیشتر با هدف ساده‌سازی کار برای برنامه‌نویسان Data Science است. همانطور که می‌بینید ویژگی‌هایی از زبان Python که موجب جذابیت این زبان برای متخصصان Data Science بوده در این لیست دیده می‌شوند.

برای آشنایی کامل‌تر این امکانات می‌توانید لینک زیر را که توسط Mads Torgersen نوشته شده‌است را مطالعه کنید.

https://blogs.msdn.microsoft.com/dotnet/2018/11/12/building-c-8-0/

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

http://ow.ly/36cL30mMFJK

#مهران_داودی (http://ow.ly/GwIl309lFEm)

کانال تلگرام:
@SoftwarePhilosophy

___

Microsoft Connect(); 2018
لیست ویدئو های کنفرانس #Connect مایکروسافت

https://channel9.msdn.com/Events/Connect/Microsoft-Connect--2018

https://www.microsoft.com/en-us/connectevent/

@IranAspMvc

نگارش نهایی NET Core 2.2 و ASP NET Core 2.2 و EF Core 2.2 منتشر شد (همین دیروز)

🔰توی پست های بعدی به بررسی تغییرات و بهبود های هر کدوم میپردازیم
لینک دانلود
https://dotnet.microsoft.com/download/dotnet-core/2.2

معرفی NET Core 2.2
https://blogs.msdn.microsoft.com/dotnet/2018/12/04/announcing-net-core-2-2/
معرفی ASP NET Core 2.2
https://blogs.msdn.microsoft.com/webdev/2018/12/04/asp-net-core-2-2-available-today/
معرفی Entity Framework Core 2.2
https://blogs.msdn.microsoft.com/dotnet/2018/12/04/announcing-entity-framework-core-2-2/

@IranAspMvc

❇️ بررسی تغییرات و بهبود های مهم NET Core 2.2

1️⃣ کامپایل چندگانه (Tiered Compilation)
این قابلیت باعث میشه کامپایلر JIT، کد ها رو به چند روش کامپایل کنه و هر کدوم که سریع تر بود رو اجرا کنه و در نتیجه Performance بهتری داشته باشیم.
این قابلیت توی NET Core 2.1 به صورت اختیاری اومد و توی NET Core 2.2 پیش نمایش 2 به صورت پیشفرض فعال بود، ولی از اونجایی که هنوز این تکنولوژی کامل و پایدار نشده، ماکروسافت ترجیح داد اون رو توی ورژن نهایی NET Core 2.2 مثل سابق به صورت اختیاری بذاره و تصمیم داره توی NET Core 3.0 اون رو به صورت پیشفرض فعال کنه

2️⃣ مشاهده رخداد های در حال اجرای برنامه (Runtime Events)
اینکه ما بتونیم رخداد های Runtime برنامه مون رو ببینیم خیلی مفیده، مثلا میتونیم ببینیم در کامپایلر JIT و Garbage Collector و یا ThreadPool چه اتفاقی میافته و این سرویس ها چطور رفتار میکنن
این قابلیت توی ویندوز توسط ETW که مخفف Event Tracing Window هست قابل انجامه ولی اگر برنامه شما داخل یک محیط با دسترسی محدود مثل هاست یا مثلا روی Linux و Mac اجرا بشه دیگه قابل انجام نیست
اما توی NET Core 2.2 میتونین این قابلیت رو توسط کلاس EventListener فعال کنین و اتفاقات Runtime برنامه تون رو Trace کنین
نمونه کد استفاده :
https://bit.ly/2Swq9WY

3️⃣ پشتیبانی از AccessToken در SqlConnection
هم اکنون، پروایدر ADO NET برای SQL Server و SqlClient از AccessToken تولید شده توسط Active Directory، پشتیبانی میکنه

4️⃣ تزریق کد به برنامه (Injecting code prior to Main)
توسط قابلیت Startup hooks می توان کد هایی که به متد Main یک برنامه در حال اجرا، بدون نیاز به Recompile کردن آن، تزریق کرد و رفتار برنامه را تغییر داد.
به عنوان مثال از این قابلیت میتوان برای سفارشی سازی رفتار برنامه و یا Trace کردن آن استفاده کرد
توضیحات بیشتر در مورد Startup hook
https://bit.ly/2SxsgK9

5️⃣ پشتیبانی از Windows ARM32
پشتیبانی از Linux ARM32 که قبلا توی NET Core 2.1 اضافه شد هم اکنون پشتیبانی از Windows ARM32 هم توی NET Core 2.2 اضافه شده و به عنوان بخشی از انتشار Windows Server 2019 هم پشتیانی از ARM32 به نسخه Nanoserver اضافه شده.
ولی پشتبیانی از Windows ARM32 به دلیل مشکلات دیر هنگامی که توی انتشار NET Core 2.2 پیش امده فعلا قابل ارائه نیست و انشالا قراره توی نسخه 2.2.1 در ماه ژانویه 2019 اضافه بشه
________________
@IranAspMvc

❇️ بررسی تغییرات و بهبود های مهم ASP NET Core 2.2

پیش نیاز استفاده از این نسخه، 2017 Visual Studio ورژن 15.9 به بالا هست (البته ممکنه توی ورژن های پایین تر هم کار کنه ولی پیشنهاد میشه 15.9 به بالا نصب کنید)
نسخه پیش نمایش Visual Studio 2019 هم دیروز در دسترس قرار گرفت اگه دوست داشتین میتونین امتحان کنین (ما هم در پست های آتی بهش خواهیم پرداخت)

نسخه 2.2 شامل بهبود های Performanc ایی و بیشتر تغییراتش مربوط به ورژن های پیش نمایش قبلی 2.2 هستند
از جمله :
1️⃣ یکپارچگی بهتر با کتابخانه های Open API مثل Swagger
https://bit.ly/2Sp2GXE

2️⃣ افزایش 20درصدی پرفرمنس مسیریابی توسط قابلیت Endpoint Routing
https://bit.ly/2SvHHT8

3️⃣ تولید راحتتر لینک های مسیریابی توسط کلاس LinkGenerator
http://bit.ly/2Sw96nT و https://bit.ly/2SwYzJd

4️⃣ ارائه API های جدید Health Checks برای مانیتور کردن سلامتی برنامه
http://bit.ly/2SvdT94

5️⃣ افزایش 400 درصدی پرفرمنس برنامه های ASP Core توسط قابلیت اجرای "in-process" درون IIS (یعنی وبسایت ما دیگه به صورت proxy پیشت iis اجرا نمیشه، بلکه درون خود iis worker process اجرا میشه. به همین دلیل پرفرمنس خیلی بالایی پیدا میکنیم)
https://bit.ly/2SvJQOG

6️⃣ افزایش 15 درصدی پرفرمنس سیستم اعتبار سنجی مدل (Model Validation)
https://bit.ly/2Su6SoZ

7️⃣ پیشتیبانی پیش نمایشی از HTTP/2 در Kestrel
https://bit.ly/2SstUfT

8️⃣ بروزرسانی Template های پروژه ASP Core جهت استفاده Bootstrap 4 و Angular 6

9️⃣ کتابخانه کلاینتی Java جهت ارتباط با ASP NET Core SignalR
https://bit.ly/2Ss3Q4H

🔟 افزایش 60درصدی پرفرمنس کلاس HttpClient بر روی لینوکس و افزایش 20درصدی بر روی ویندوز
https://bit.ly/2SAfcUr

البته به هنگام معرفی Roadmap و Planning نسخه 2.2، ماکروسافت قابلیت های زیادی رو برای افزودن نام برد از جمله موارد زیر
Authorization with IdentityServer4
Open API (Swagger) driven client code generation
HTTP REPL command line tool
ولی هنوز آماده نشده و در حال تکمیل شدن هست و به زودی دردسترس قرار میگیره
* میبینیم که ماکروسافت هم با اون عظمتش، توی برنامه ریزی هاش، فردین بازی در میاره و خیلی امکانات میگه ولی نمیرسه انجامشون بده (مثل هممون :دی)
________________
@IranAspMvc

❇️ بررسی تغییرات و بهبود های مهم EF Core 2.2

نسخه 2.2 در طول انتشار نسخه های پیش نمایشش قابلیت های مهمی رو به خودش اضافه کرد و بیش از 100 باگ گذارش شده رو برطرف کرد
کلا EF Core از اولش که اومد باگ ها و نواقص زیادی داشت و برای پروژه واقعی خیلی چنگی به دل نمیزد ولی هرچه بیشتر پیش میره پایدار تر و کامل تر داره میشه و به نحوی که الان واقعا میشه اسم که ORM کامل رو روش گذاشت

از مهم ترین تغییرات، بهبود ها و امکانات جدیدش میشه به موارد زیر اشاره کرد:

1️⃣ پشتیبانی از Spatial data (دیتا های مربوط به نقشه و فضای 2 بعدی)
مثلا برای ذخیره مختصات یک location، یا اندازه گیری فاصله بین دو location، یافتن نزدیک ترین location ها و یا ذخیره سازی انواع و اقسام اشکال (Shape) از جمله polygon و... ما نیاز به Spatial Data داریم، که این نوع توی اکثر دیتابیس ها از جمله SQL Server پشتیبانی میشه ولی قبلا توی EF Core نمیشد ازش استفاده کرد
هم اکنون EF Core 2.2 به لطف استفاده از کتابخانه جغرافیایی NetTopologySuite یا به اختصار (NTS) از این قابلیت پشتیبانی گسترده ای میکنه و محدودیت نسخه های پیش نمایش رو نداره.
در این راستا پکیج های مختلفی برای Provider های EF از جلمه SQL Server، PostgreSQL, SQLite و... ایجاد شده تا شما بتونین Spatial Data ها رو توسط EF Core داخلشون ذخیره کنین و یا بخونین ازشون و همچنین از function هاش استفاده کنین
مثلا برای استفاده از Spatial Data روی SQL Server توسط EF Core به پکیج زیر نیاز دارین
https://www.nuget.org/packages/Microsoft.EntityFrameworkCore.SqlServer.NetTopologySuite/
مطالعه بیشتر:
https://docs.microsoft.com/en-us/ef/core/modeling/spatial

2️⃣ پشتیبانی از Collections of Owned Entities
توی EF Core 2.0 قابلیتی به نام Owned Entities اضافه شد که مشابه به استفاده از Complex type ها توی EF 6 بود (مشابه رابطه 1 به 1). این قابلیت توی نسخه 2.1 تکمیل تر شد و توی نسخه 2.2 ما شاهد پشتیبانی "لیستی از Owned Entities ها" هستیم (مشابه رابطه 1 به چند).
درواقع توی دتیابیس های رابطه ای، به ازای Owned Collections، جداول جدایی ایجاد میشن (دقیقا مثل رابطه 1 به چند معمولی) ولی توی دیتابیس های غیر رابطه ای Document-Oriented، به ازای Owned Collections جدول جدایی ساخته نمیشه و به صورت document داخل خود جدول مالک ذخیره میشن
جهت استفاده ازش هم باید به صورت Fluent Api اون رو Config کنین
modelBuilder.Entity<Customer>().OwnsMany(c => c.Addresses);
جهت اطلاعات بیشتر
مطالعه بیشتر:
https://docs.microsoft.com/en-us/ef/core/modeling/owned-entities#collections-of-owned-types

3️⃣ قابلیت Query Tags
توسط این قابلیت میشه چیز خیلی خفنی نیست و فقط باعث میشه شما بتونین روی کوئری های Linq اتون یه توضیحی رو اضافه کنین و این توضیح توی کوئری SQL ساخته شده اضافه میشه و درنتیجه توی لاگ کوئری هاتون میتونین بالای سر هر کوئری، توضیحی رو که بهش اضافه کردین، مشاهده کنین
بیشتر موقع لاگ کردن کوئری هاتون مناسبه و باعث میشه بتونین راحت تر کوئری هاتون رو بررسی کنین
توضیحات بیشتر:
https://docs.microsoft.com/ef/core/querying/tags

نکته : طبق گفته های ماکروسافت این نسخه (یعنی 2.2) با نسخه قبلی (یعنی EF Core 2.1) سازگار هست و اصطلاحا Backwards Compatible هست و با خیال راحت میتونین پکیج EF پروژتون رو آپدیت کنین

🔰و اما قراره تو نسخه EF Core 3 قابلیت های جدید اضافه بشه، از جمله:
- بهبود هایی در رابطه با کوئری های Linq
- پروایدر جدید و پشتیبانی از Cosmos DB
- پشتیبانی از قابلیت های سی شارپ 8.0
- تولید View ها به هنگام Reverse POCO Generation
- قابلیت جدیدی به نام Property Bag Entities که باعث میشه بتونیم پروپرتی هایی از نوع Dictionary رو داخل دیتابیس ذخیره کنیم
- قابلیت اجرای EF 6.3 روی NET Core 3.0

_________________
@IranAspMvc

نسخه پیش نمایش Visual Studio 2019 منتشر شد

بیشتر تغییرات این نسخه مربوط به ظاهر و UX اون هست که واقعا خیلی جذاب و کارآمدش کرده

تغییرات ظاهری جدید:
https://blogs.msdn.microsoft.com/visualstudio/2018/12/04/making-every-developer-more-productive-with-visual-studio-2019/

لیست کامل تغییرات + لینک دانلود VS Installer آنلاین:
https://docs.microsoft.com/en-us/visualstudio/releases/2019/release-notes-preview

همزمان با نسخه پیش نمایش VS 2019، نسخه پیش نمایش NET Core 3.0 هم منتشر شد که توسط این ورژن از VS قابل استفاده است
http://aka.ms/netcore3preview1
لینک دانلود NET Core 3.0 نسخه preview
https://dotnet.microsoft.com/download/dotnet-core/3.0

_____________
@IranAspMvc

#Quotes

بهترین معماری، معماری ایی نیست که بیشترین پرفرمنس، یا بهترین دیزاین پترن ها را داشته باشد!
بهترین معماری، معماری ای است، "خاص سلوشن شما" که متعادل ترین وزن بین "دیزاین پترن ها"، "قرارداد ها"، "قابلیت توسعه و نگهداری"، "تست پذیری" و "پرفرمنس" را داشته باشد

@IranAspMvc