#Api_Documention
معرفی #بهترین ابزار های #مستند_سازی و تست Api
https://bit.ly/api-documention
_______________
@IranAspMvc

به سلامتی #RedHat هم رفت خونه بخت!
شرکت IBM شرکت Red Hat را 34 میلیارد دلار خرید.
https://read.bi/2zdaZh8
___________
@IranAspMvc

#News #NetCore3
ماکروسافت اعلام کرد ASP NET Core 3.0 دیگر از Net Framework Full پشتیبانی نخواهد کرد
http://bit.ly/2zgCiqR
___________
@IranAspMvc

یکی از امکانات Angular 7، ویژگی Virtual Scrolling می‌باشد. در صورتیکه شما قصد داشته باشید یک لیست بزرگ از المنت‌ها (مثلا 1000 آیتم) را بارگذاری کنید، این‌کار می‌تواند بر روی کارآیی برنامه‌ی شما تاثیر بگذارد .
می تواند برای بارگذاری تنها بخش‌های قابل مشاهده‌ از یک لیست (مثلا 10 آیتم)، بر روی صفحه نمایش استفاده شود و همچنین تنها آیتم‌هایی Render خواهند شد که می‌تواند آن‌ها را در صفحه نمایش جا دهد. اگر لیست بارگذاری شده را اسکرول کنیم، در این حالت المنت‌ها در DOM به صورت پویا load و unload می‌شوند.

آموزش Virtual Scrolling در Angular 7 :
https://www.dotnettips.info/post/2939
لینک Demo :
https://stackblitz.com/edit/angular-jnjms3
___________
@IranAspMvc

http://bit.ly/2PEJSpr
بررسی و Navigate کردن بین کد های داخل Github مثل همیشه یک دردسر بوده و به راحتی امکان پذیر نیست، چرا که مانند یک IDE، رفرنس بین کدها مشخص نیست یا مثلا گزینه ای مانند Go to Definition وجود ندارد که بتوان محل تعریف یک متد را که در جایی درگیر استفاده شده است، یافت؛ به همین منوال برای یافتن کلاس هایی که یک Interface را Implement کرده اند و یا پیدا کردن کد های کلاسی که کلاس جاری از آن ارث بری کرده است
در این موارد تنها راه چاره، سرچ کردن نام متد یا کلاس درریپازیتوری Github است و سپس روبرو شدن با حجم انبوهی از کد ها که متن جستجو شده در آنها به کار رفته به مانند پیدا کردن "سوزن در گاه دون" است

افزونه Sourcegraph ابزاریست که قابلیت intelligence را به کد های Github شما میدهد و توسط آن میتوانید 3 عمل زیر را به راحتی انجام دهید
1- Go to Definition : یافتن کد تعریف کد مربوطه
2- Find References : یافتن تمام صفحاتی که کد مربوطه در آنجا استفاده شده است
3- Find Implementations : یافتن تمام پیاده سازی های کد(مثلا interface) مربوطه

* این افزونه از زبان های مختلفی مانند JavaScript, TypeScript, Python, Java, Go, ... پشتیبانی میکند ولی متاسفانه از زبان C# پشتیبانی نکرده و در مورد ریپازیتوری های C# کمکی به ما نمیکند

لینک دانلود افزونه Chrome:
https://chrome.google.com/webstore/detail/sourcegraph/dgjhfomjieaadpoljlnidmbgkdffpack
_______________
@IranAspMvc

در ادامه پست قبلی به معرفی ابزاری برای 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