ممنون از دوستان عزیز که زحمت کشیدن و مطالب زیادی رو جمع آوری کردن و کمک بزرگی به برنامه نویسان میکنن تا به جای مطالعه ده ها مقاله با گوش کردن یک ویس خیلی کلیات و بعضا جزئیات رو یاد بگیرن.
توی بحث تست مخصوصا بخش ماک یه موضوع مهمی فراموش شده من فقط نکاتش رو بیان میکنم که توی پروژه هاتون در نظر بگیرید.
توی بحث B2B یه مبحثی داریم که شما به مشتری هاتون سرویس های تست میدید تا اونا بتونن با منطق پروژه ی شما سناریوهای لازم رو تست بگیرن، برای مثال فرض کنید میخواید یک سرویس B2B برای Api پرواز به مشتری هاتون ارائه بدید و اونا برای اینکه بتونن سرویس های شمارو تست کنن لزوما نباید به صورت لایو عملیات booking رو انجام بدن، بنابراین بهتره توی این شرایط شما سرویس هاتون رو به صورت virtual شده در اختیارشون قرار بدید تا هرچقدر دوست دارن بتونن برای پیاده سازی سرویس هاشون سرویس های شمارو بدون مشکل و هزینه کال کنن.
من پیشنهادم اینه که شما تست های ماک خودتون رو که برای سرویس های خارجی (Api های خارج از شرکت) پیاده سازی میکنید اونو طوری پیاده سازی کنید که هم برای مبحث تست ها و هم برای مبحث virtual کردن برای مشتری های بیزینسی خودتون سرویس دهی داشته باشید.
بنابراین ماک کردن رو فقط برای اینکه بتونید سرویس های بیرونی رو virtual کنید تا تستهاتون بدون هزینه و با سرعت پس بشن انجام ندید برای اینکه هم برنامه نویس ها و تستر های پروژه شما بتونن همیشه فرایند های وبسایت شمارو کامل تست کنن ولی بدون هزینه و پیگیری کنسل کردن و ... و بدون اینکه لایو باشه ،هم اینکه مشتری های بیزینسی شما بتونن به صورت virtual از سرویس های شما داده دریافت کنن و بدون هزینه عملیات booking رو با ورودی های مختلف تست بگیرن.

#Mock
#Test

قبل اینکه Solid رو رعایت کنید معماری رو درست پیاده سازی کنید

#معماری
#solid
#javascript
#architecture

@CsharpTips

چطوری بفهمیم یک پروژه خوب و درست معماری شده؟
وقتی که به شما میگن یک سیستم پیامکی میخوام برامون بیارید بالا، اگر شما در پیاده سازی اون پروژه فقط و فقط درگیر مباحث و مسائل همون سیستم یا Api پیامکی شدید که میخواستید پیاده سازی کنید یعنی معماری سیستم شما درست پیاده سازی شده. اما اگر برای پیاده سازی این سیستم پیامکی درگیر این مباحث شدید معماری شما دارای ایراد هست:
1.دخل و تصرف توی سیستم های دیگه، مثلا ایمیل یا پرداخت یا ...
2.درگیر مباحث تکراری شدن:
فرض کنید شما قراره توی سیستم پیامکی چندتا سرویس کاوه نگار، ملی پیامک و ... رو پیاده سازی کنید اگر توی پیاده سازی اینها فقط درگیر پیاده سازی کردن ورودی و خروجی سرویسهای این Api ها شدید یعنی معماری رو درست پیاده سازی کردید اما اگر توی هر کدوم به صورت جداگانه درگیر ذخیره سازی در دیتابیس، کوئری ها و لاگ و مدیریت خطا ها و ... که مربوط به خود اون سیستم پیامکی نیستند شدید یعنی معماری درست پیاده سازی نشده و شما درگیر عملیات تکراری شدید و برای پیاده سازی سرویس جدید باید مجدد همه این راه ها رو تکرار کنید در حالی که برنامه نویس فقط باید درگیر چارچوب همون سرویس برای پیاده سازی بشه.
3.برکینگ چنج های سرسام آور:
معماری رو از ابتدا طوری پیاده سازی کنید و انواع تست هارو روی اون بگیرید و سناریو های مشخص و زیادی رو روش بررسی کنید تا کمترین برکینگ چنج هارو توی توسعه داشته باشید فراموش نکنید وقتی پروژه شما Release شد و مشتری داره از اون سرویس استفاده می کنه حتی نباید یک پروپرتی به کلاس ورودی یا خروجی اون سرویس اضافه کنید (منظور مشتری بیزینسی هست نه کلاینت خودتون که با برکینگ چنج شما میتونه کنار بیاد). شاید با خودتون فکر کنید اضافه کردن یک پروپرتی مشکلی ایجاد نمی کنه اما شما نمی دونید مشتری شما چطوری کد زده و ممکنه با اضافه کردن پروپرتی کدی که قبلا زده روی سیستمش کار نکنه بنابراین وقتی کارتون به مشتری نهایی رسید باید از خیر تغییر دادن اون سرویس بگذرید و ورژن بندی کنید.
4.شرط های تست و لایو:
توی پروژه هاتون نباید شرط هایی داشته باشید که چک کنن اگر روی تست بودم فلان کن اگر روی لایو بودم فلان کن چون وقتی پروژه شما لایو میشه نباید هر بار این شرط چک بشه چون روی لایو هستید و لزومی به چک کردن این شرط ها ندارید، چطوری این موضوع رو هندل کنیم؟
از طریق داده های دیتابیس یا کانفیگ ها میتونید پیاده سازی یک کلاس تست از یک کلاس لایو رو از هم جدا کنید بنابراین وقتی توی initialize اولیه پروژه هاتون بتونید به برنامه بگید الان سوییچ کن روی لایو یا الان سوییچ کن روی تست و در روند اجرایی برنامه دیگه این شرایط چک نشن یعنی راه رو درست رفتید و نرم افزار شما در فرایند لایو دیگه نمیدونه فرایند تست چیه و در فرایند تست دیگه نمیدونه فرایند لایو چیه و لازم نیست هربار این شرط که روی تست هستیم یا روی لایو چک بشه.
5.بروزرسانی سرویس ها:
موقع بروزرسانی سرویس ها کاربران نباید متوجه بروزرسانی بشن مگر اینکه خرابکاری کرده باشید 😂، بنابراین وقتی خراب کاری کردید میتونید به کاربرتون بگید صبر کنن تا بروزرسانی تموم بشه ولی توی حالت عادی کاربراتون باید بدون مشکل با سایت کار کنن.
چطوری هندلش کنیم؟
با استفاده از پترن Blue Green میتونید این مشکل رو حل کنید همیشه باید یک سرویس دیگه برای ارائه به مشتری داشته باشید،بنابراین وقتی مشتری داره با سرویس 1 شما کار میکنه سرویس 2 رو بروزرسانی می کنید و مشتری توسط Geteway برای درخواست های جدید به سرور 2 وصل میشه سپس سرویس 1 رو بروزرسانی میکنید بدین ترتیب مشتری متوجه بروزرسانی شما نمیشه فقط حواستون باشه وقتی سرویس در حال کار هست و مشتری ها دارن باهاش کار میکنن اونو Down نکنید و توسط Gateway هاتون باید مشتری هارو سوییچ کنید توی سیستمی که بروزرسانی شده تا درخواست ها از سرویس 1 به صفر برسه و سپس سرویس 1 رو بروزرسانی کنید.

شاید موارد دیگه ای هم باشه ولی فعلا به همین چند مورد بسنده کردم.
#Architecture
#معماری

@CSharpTips

میزان دانلود پکیج های سیگنالگو از مرز یکصد هزارتا گذشت

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

توسعه سریع
استفاده آسان
بدون ایجاد وابستگی
و باز بودن دست برنامه نویس برای پیاده سازی معماری خاص خودش بهش این امکان رو میده تا از پروژه های با سورس های کوچک تا پروژه های #Enterprise رو بشه باهاش پیاده سازی کرد
استفاده از چندین پروتکل همزمان روی یک سرویس بدون نیاز به کد زدن اضافی
کد جنریتور قوی برای متریال ویو ها و کلاینت انگولار و فلاتر

البته ایرانی های زیادی رو میشناسم که هیچوقت از کارم حمایت نکردن منظورم برنامه نویس هاست حتی خودشون هم وقتی این پست رو بخونن با خبر میشن😞

اگر یک گیمر هستید، از امروز میتونید بازی های پلی استیشن 4 و 5 رو روی PC بازی کنید، این خبر توسط سایت رسمی خود Play Station منتشر شده.
لینک مشاهده جزئیات و دانلود اپلیکیشن:
https://www.playstation.com/en-us/ps-now/ps-now-on-pc/

یکی از مواقعی که بهتر است از async void استفاده کنیم.

تفاوت Async Void و Async Task در هنگام تعریف یک متد چیست و چه موقع میتوان از هرکدام استفاده کرد. اگر این متد ها داخل try-catch صدا زده شوند عملکرد هر کدام هنگام رخ دادن exception چگونه است؟

پاسخ:

توابع async Task به خودی خود خطا های درون آنها هندل میشوند اما async void یک تسک کاملا مستقل است که در صورت خطا خوردن باعث کرش کردن نرم افزار می شود.
مواقعی که میخواهید یک background job درست کنید از async void استفاده کنید و حتما توابع داخل انرا درون try catch بگذارید.
زمانی که شما async Task استفاده می کنید یعنی به برنامه نویس استفاده کننده در توابع async می فهمانید که باید آنرا await کند برنامه نویس نمی داند این یک تسک background است و ممکن است فراموش کند که نباید آنرا await کند و در صورت await کردن ممکن است تا ابد آن تابع منتظر پاسخ بماند تا پایان یابد در حالی که درون آن یک while true قرار دارد و هیچوقت پایان نمی یابد.
بنابراین در این شرایط بهتر است از async void استفاده شود تا برنامه نویس استفاده کننده دچار اشتباه نشود و آنرا await نکند.
در این صورت برنامه نویس نمی تواند آنرا await کند و نرم افزار بلافاصله آنکار را در بکگراند اجرا می کند.

@CSharpTips

معمولا شما برای جلوگیری از warning یا اخطار ویژوال استادیو برای اجرای یک تسک در بکگراند اینطوری عمل می کنید:

_ = DoTask();

اما فراموش نکنید برنامه نویس استفاده کننده نمی دونه شما درون تابع DoTask ممکنه یک while true داشته باشید که به شکل بالا اونو در بکگراند اجرا کنه، معمولا برنامه نویس وقتی از روش بالا استفاده می کنه که مطمئن باشه نمی خواد await انجام بده و صد در صد میخواد در بکگراند انجام بده و از محتویات درون DoTask هم آگاهه، اما در حالت عادی برنامه نویسان وقتی یک تابع Task میبینند اونو await می کنند تا بعد از اتمام کار تابع، مراحل بعدی رو انجام بدن. استفاده از async void به شما این کمک رو می کنه که جلوی اشتباه برنامه نویس رو بگیرید.

@CSharpTips

در حالاتی که شما می خواهید در تابع خودتون ورودی بگیرید و عملیات validation انجام بدید برای مدیریت این نوع بکگراند ها بهتره از روش دیگری استفاده کنید و اون اینه که تابع خودتون رو به صورت معمولی void تعریف کنید و تابع درونی کلاس رو از طریق یک Task.Factory صدا بزنید، در این حالت میتونید قبل از صدا زدن توابع درون Task.Factory یک exception throw کنید و به برنامه نویس خطای اعتبار سنجی برگردونید. ولی اگر توی async void بخواهید exception برای اعتبار سنجی برگردونید نمیتونید و اپلیکیشن شما کرش می کنه.

روش دومی که الان گفتم در BackgroundWorker خود مایکروسافت هم استفاده شده که لینکش رو میذارم میتونید مطالعه کنید.
این نکته رو هم فراموش نکنید با اجرای Task.Run یا Factory خیال خودتون رو راحت نکنید که داخلش Exception هارو هندل می کنه حتما خطا ها رو به روش هایی که وجود داره لاگ کنید و رفعشون کنید تا برنامه تون به باگ نخوره و فرایندش درست اجرا بشه.

https://github.com/dotnet/runtime/blob/main/src/libraries/System.ComponentModel.EventBasedAsync/src/System/ComponentModel/BackgroundWorker.cs

@CSharpTips

چندتا نکته برای اینکه بتونید عضو کانتریبیوتر های پروژه های بزرگ و اپن سورس جهانی بشید و رزومه خوبی برای خودتون بسازید
1.یکی از پروژه هایی که خیلی باهاش سرو کار دارید رو نشون کنید،فورک و پول کنید مثلا من EF Core رو انتخاب کردم
https://github.com/dotnet/efcore/issues
2.به روش های مختلفی میتونید عضو توسعه دهندگانش بشید، سوالات رو نگاه کنید و اون سوالاتی که با تگ باگ یا فیچر از هم تفکیک شدند رو پیدا کنید و باگ ها رو پیدا و رفع کنید، فراموش نکنید که حتما از پروژه یک فورک بگیرید و روی سورس خودتون تغییرات رو اعمال کنید و سپس پول رکوئست بزنید
3.به قسمت پروژه و بکلاگش برید و ببینید چه فیچر هایی رو در نظر دارن در آینده انجام بدن اگر میتونید انتخابش کنید و انجامش بدید مطمئن بشید که کسی دیگه در حال انجام اون نباشه که کانفیلیت بخورید.لینک:
https://github.com/dotnet/efcore/projects/1

4.نکته مهم اینه که از خودتون ایده پیاده سازی نکنید، یعنی اینکه بدون اینکه تیم مایکروسافت رو در جریان بذارید بشینید یه ایده رو پیاده سازی کنید و انتظار داشته باشید اونا هم پول رکوئست شمارو تایید کنند، در این حالت بهتون میگن برید همون سورس خودتون رو گسترش بدید و پروژه خودتون رو بسازید و نیوگت خودتون رو هم داشته باشید البته اصلا مخالف اینکار نیستند و تایید هم می کنند ولی میگن در دستور کار ما و روند جاری پروژه رسمی ما نیست، بنابراین بهتره قبل اینکه ایده تون رو پیاده کنید حتما پرسش (Issue) بزنید و اونارو در جریان بذارید در صورتی که تایید کردن و در دستور کارشون قرار گرفت برید و انجامش بدید

5.برای کارهایی که انجام میدید حتما تست کیس بزنید

6.اصلا و ابدا کدها و توابع پابلیک رو تغییر ندید، تغییرات برکینگ چنج بشدت مردود هست حتی تغییراتی که باعث بشه خطای Ambiguous توی حالت رانتایم بخوره مثلا یک تابعی وجود داره که از طریق GetMethod توی رانتایم میشه بهش دسترسی داشت بعد شما یک تابع هم اسم اون می سازید ولی نوع ورودیش فرق داره کامپایلر خطا نمی خوره ولی قطعا در رانتایم باعث برکینگ چنج شدید و برنامه کلاینت ها در صورتی که توابع رانتایم رو صدا بزنند در ورژن بعدی خطا خواهد خورد

اگرم موردی از قلم افتاده می تونید توی کامنت ها بذارید که دوستان مطالعه کنند، با تشکر

#opensource
#microsoft
#EFCore
#contributions

@CsharpTips

اینجا زیر پست یا مستقیما در گروه، نظراتتون رو به اشتراک بزارید
از منو بیو کانال discussion انتخاب کنید وارد گروه میشید.

توی زبان برنامه نویسی Go شما توانایی هندل کردن Exception ها رو به صورت try catch ندارید یعنی اصلا سینتکسی در اون وجود نداره که بخواهید خطاهایی که رخ میده رو catch کنید، این یعنی همه ی خطاهارو باید موقع خروجی گرفتن از توابع هندل کنید و همیشه شرط بذارید، اینکار اشتباه نیست برای همین رعایت ها زبان گو پرفورمنس بسیار بالایی داره.

یه بحثی بود قبلا کرده بودم که throw exception کردن برای اینکه به کاربرامون بفهمونیم خطای ولیدیشن دارن یا خطاهای user friendly خوردن صحیح نیست. چندتا نکته:
1.خطا throw کردن به صورت دستی وقتی یک نفر api شمارو صدا میزنه باعث ایجاد وقفه توی سیستم شما میشه و پردازش های Cpu و Ram رو بیشتر می کنه.
2.کلا استفاده از try و catch پروفورمنس کد شمارو پایین میاره حتی اگر به خطا نخورید و چیزی throw نشه.
3.خوانایی کد رو پایین میاره و فانکشنالیتی کد شمارو بهم میریزه.

حالا توی زبان برنامه نویسی Go یکم از اون ور پشت بوم افتاده چون وقتی سیستم به خطایی بخوره که هندل نشده اپ شما کرش می کنه یعنی به برنامه نویس ها میگن شما باید در هر صورت جلوی رخ دادن خطا رو بگیرید و موقع مواجه با استثناها شما عملا باید اپ رو مجدد اجرا کنید و ریسک این نوع برنامه نویسی هم بالاست چون اگر یک درخواست از سمت کلاینت بتونه روی سرور شما exception ایجاد کنه، بوم!!

من بهتون پیشنهاد میکنم خوبی های هر کدوم رو داشته باشید و فقط وقتی throw exception کنید که واقعا لازمه و تا جایی که میتونید استفاده از try catch رو توی کدهاتون کم کنید.

@CSharpTips

نوشتن ابزار هایی که جلوی اشتباهات برنامه نویس هارو بگیره موقع اجرا بیشتر باعث صرف جویی میشه تا اینکه کدهاتون کلین باشه، منظورم این نیست که کلین کد در اولویت نیست منظورم اینه که اولویت اول نیست، توی پروژه اینترپرایز در مدیریت بالای 50 میکروسرویس اگر تعداد برنامه نویسها کمه مثلا 5 نفر😒! و سرعت توسعه و اضافه کردن فیچر ها و رفع باگ ها خیلی زیاده، ابزار ها مهمه.
مثلا:
1.جلوگیری از اشتباهات در کانفیگ ها مثلا کلید هایی که دیگه توی کانفیگ استفاده نمیشن حذف بشن تا کانفیگ ها کلین بمونن و شلوغ نشن.
2.جلوگیری از اشتباهات برنامه نویس ها در اجرای تست کیس ها، مثلا کانفیگ رو بذارن رو لایو و شروع کنن به اجرای تست کیس ها 😒😂
3.جلوگیری از اشتباهات پابلیش، به جای اینکه روی تست بفرستن، روی لایو بفرستن !!
4.جلوگیری از اجرای اتو مایگریشن ها روی لایو
5.جلوگیری از اینکه دیتابیس رو تغییر بدن و یادشون بره مایگریشن بزنن
6.جلوگیری از اینکه مپر های لوپ بزنن و باعث بوجود اومدن خطا های استک اور فلو بشن که پیدا کردنش شکستن شاخ غول میخواد
7.همیشه علاوه بر سرور بلو و گرین یک بلک هم داشته باشید که دقیقا مثل لایو باشه ولی فقط داخل شرکت کاربرد داشته باشه که دیتابیسش کاملا مجزاست و استفاده ی بیزینسی نداره و برای تسته اما داده ها لایوه، اونوقت تست های دیتابیسی و مایگریشن و پچ و ... رو ابتدا روی اون انجام بدید تا مطمئن بشید همه چیز به خوبی کار می کنه.
8.همیشه یک کلیک بهتر از ده کلیکه، پس به جای کامند زدن سعی کنید ابزار داشته باشید که کارتون سریع باشه برای همینه که ویندوز ابزار هایی که UI داره کاربردش خیلی سریعتره تا سیستم عاملی که فقط کامند قبول می کنه.مثلا به جای استفاده ممتد از گیت clr از گیتهاب دسکتاپ استفاده کنید و با یک یا دو کلیک همه چیز رو هندل کنید.به جای اینکه روی کیبرد صد تا کلیک بزنید تا به مرادتون برسید (سیستم عامل رو شما نساختید پس روش تعصب نداشته باشید و برای وقتتون ارزش قائل بشید)
9.کارهارو اتوماتیک کنید و از انجام کارهای دستی جلوگیری کنید.هرچی کارها اتوماتیک تر بشه و محاسباتش توسط کامپیوتر انجام بشه ایجاد خطاهای انسانی کمتر میشه.
10.اگر با دیتابیس ممکنه سرو کار داشته باشید و بخواید توش کوئری بزنید همیشه یک یوزر ReadOnly بسازید و مطمئن بشید که روی لایو کوئری های ویرایشی سهوا اجرا نمیشن.

@CsharpTips

از پیچیدگی هسته هراسان نباشید، هسته همیشه پیچیدگی خودش رو خواهد داشت، نحوه ی استفاده از Component شما بسیار مهمه.برای مثال در طراحی ماشین باید براتون خیلی مهم باشه که فرمون جای راحتی باشه، قابل دسترسی باشه، نرم باشه دنده در جای خودش باشه و حتی حذف بشه! کامپیوتر جلوی چشم باشه و گاز و ترمز در جای مناسب و استفاده اش آسون باشه ولی وقتی موتور ماشین رو پیاده سازی می کنید نمیشه براش جای صندلی برای نشستن بذارید یا مثل دنده و فرمون زیبا و زینت بهش بدید و انتظار داشته باشید کسی که پشت فرمون میشینه از موتور ماشین هم سردربیاره.
هسته ی ابزار ها توی برنامه نویسی همیشه مثل موتور ماشین پیچیدگی خودش رو خواهد داشت، یادگیریش سخت خواهد بود بخاطر اینکه ده ها و صد ها و هزاران چیز دارن تبدیل میشن به چهار تا چیز که کارش برای End User راحت باشه.شما هسته ی دات نت یا EF رو ببینید باید در مورد IL و Expression و Reflection ها خیلی چیزها بدونین و مسلط باشید.با این ها میتونید ابزار ها و هسته هایی بسازید که کار برنامه نویس های توسعه دهنده و حتی جونیور هم راحت بشه ولی انتظار نداریم که یک جونیور براحتی بفهمه داخل هسته داره چه اتفاقی میوفته.
هرچی که بخواید کار برنامه نویس استفاده کننده از ابزار شما آسون تر بشه، بخاطر رعایت مسائل پرفورمنس و مموری و OOP و ... شما هسته رو پیچیده تر طراحی خواهید کرد، مثل جویدن لقمه برای نوزادی میمونه که خودش توانایی انجام اینکار رو نداره و شما هم ازش این انتظار رو ندارید.

@CSharpTips

در راستای توضیح هسته:
این دو تابع دوتا ورودی فانکشن رو با هم And و Or میکنن و تبدیل به یک func می کنن.
نحوه ی استفاده از Expression ها برای And و Or کردن دو Func ورودی که جلوتر توضیح خواهم داد.
#Expression
#CSharp

@CSharpTips

تابع OrAlso که در تصویر می بینید در اصل دو فانکشن میگیره و اونارو با هم Or میکنه و تبدیل به یک فانکشن به صورت Experssion میکنه به طوری که برای ORM هایی مثل EF Core قابلیت تبدیل به کوئری های دیتابیس رو داره.
حالا چطوری یاد بگیریم که با Experssion ها کار کنیم و باهاش چیزای جالبی خلق کنیم؟
چندتا قانون رو باید در نظر بگیرید:
1.اینکه Experssion ها دقیقا مثل کد نویسی شما نیستند بنابراین انتظار نداشته باشید بدون اینکه به Experssion بگید که این قسمت کدم باید اجرا بشه و نتیجه اش مقایسه بشه به صورت جادو وار خودش بفهمه.پس صدا زدن Expression.Invoke مهمه.
2.اگر Experssion رو کامپایل کنید بهتون خروجی delegate رو میده پس حواستون باشه که اگر کامپایلش کنید دیگه ORM نمیتونه تبدیلش کنه به کوئری دیتابیس.منظور از کامپایل کردن صدا زدن تابع Compile هست.
3.و اینکه Experssion ها توابع قابل تبدیل و ترجمه شدن در Runtime هستند که چون توی یک delegate به صورت خیلی ساده و مستقیم نوشته میشن خیلی هم ساده قابلیت تبدیل شدن و ترجمه دارن پس انتظار نداشته باشید یک تابع با body چند خطی که کلی توش ضرب و تقسیم کردید براتون تبدیل به experssion بشه که قابل ترجمه برای ORM ها باشه.

میخوام تابع زیر رو تبدیل به experssion در حالت runtime کنم:

        public static Func<T, bool> OrAlso2<T>(this Func<T, bool> left, Func<T, bool> right)
        {
            return x => left(x) || right(x);
        }

توضیحات:

var param = Expression.Parameter(typeof(T), "x");

در خط کد بالا شما میبینید که من دارم یک پارامتر تعریف می کنم.

در کد زیر میبینید که من با استفاده از تابع OrElse دوتا فانکشن رو با هم Or کردم که همون عملگر || توی سی شارپ هست. وقتی نوشتم Expression.Invoke به این معنی هست که خروجی اون فانکشن باید با خروجی فانکشن دومی Or بشه.دوتا ورودی داریم که من ورودی اول رو همون فانکشن میذارم و بهش میگم که پارامترم رو به ورودی فانکشن بفرست.این به این معنی هست که من الان دارم یک فانکشنی میسازم که داخلش دوتا فانکشن رو با هم Or میکنم پس فانکشن اصلی من یک ورودی به نام x داره که x رو توی دوتا فانکشنی که دارم به عنوان ورودی بعدی پاس میدم تا ازش خروجی بگیرم.

var body = Expression.OrElse(Expression.Invoke(left, param), Expression.Invoke(right, param));

مثال بارز استفاده اش اینطوریه:

            Expression<Func<MyClass, bool>> firstQuery = x => x.Name == "Ali";
            Expression<Func<MyClass, bool>> secondQuery = x => x.Age > 10;
            Expression<Func<MyClass, bool>> mergedQuery = ExpressionHelper.OrAlso(firstQuery, secondQuery);

در کد های بالا ورودی اصلی x ما همون کلاس MyClass خواهد بود و ما وقتی توی خط اول Experssion هامون گفتیم Expression.Parameter(typeof(T), "x") یعنی همون ورودی x که از نوع MyClass هست رو تعریف کردیم.
حالا در کد های بعدی ما سه تا بلاک داریم:
1.Expression.Invoke(left, param)
2.Expression.Invoke(right, param)
3.Expression.OrElse

شماره یک و دو دارن ورودی x رو به عنوان پارامتر به فانکشن های ورودی میفرستن تا خروجی رو بگیرن یعنی یکبار x => x.Name == "Ali" و یکبار x => x.Age > 10 اجرا میشه و بعد توسط تابع Expression.OrElse با هم Or میشن.
حالا قدم بعدی اینه که وقتی پارامتر هارو ساختیم حالا باید از کاری که کردیم یک خروجی delegate از نوع experssion بسازیم که در خط آخر میبینید:

            var lambda = Expression.Lambda<Func<T, bool>>(body, param);

اینجا پارامتر اصلی experssion خودمون رو به عنوان ورودی از نوع param دادیم و منطق اصلی experssion مون که توسط OrElse ساختیم رو به عنوان body میدیم و انتظار داریم که خروجی ای که به ما میده یک experssion از نوع or کردن دو فانکشن experssion باشه که برای ORM ها قابل ترجمه باشه.
امیدوارم این آموزش براتون قابل استفاده بوده باشه.

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

این قابلیت Fetch and merge گیتهاب واقعا کار راه اندازه، خوبای گیت میدونن که اگر این قابلیت نبود چقدر دردسر برای Rebase کردن و مرج کردن با upstream داشتن

این فیچر باعث میشه پروژه ی اصلی با فورک شما مرج بشه و آخرین تغییرات همیشه روی فورک شما اعمال بشه، با این حال اگر از تغییرات روی پروژه های اصلی گیتهاب عقب بمونید دیگه لازم نیست کلی دردسر برای Rebase کردن بکشید که در نهایت کلی وقتتون گرفته بشه که فقط فورک خودتون رو با upstream اصلی مرج کنید

@CSharpTips


#گیتهاب
#مرج
#ریبیس
#git
#github
#rebase

دوباره، اینبار توی دات نت رانتایم، فقط 5 دیقه وقتم رو گرفت به زودی یه داستان برای اینکه چطوری تونستم توی پنج دیقه عضو کانتریبیوتر های دات کور با یک تغییر ساده بشم براتون میذارم.

https://github.com/dotnet/runtime/pull/62633

@CSharpTips

Don't Do That, Do This: The .NET 6 Edition
https://www.daveabrock.com/2021/12/08/do-this-not-that-the-net-6-edition/