توی سی شارپ استفاده از try همیشه به معنای catch کردن و جلوگیری از بروز خطا ها نیست گاهی اوقات شما میتونید فقط از try finally استفاده کنید تا کار خاصی رو انجام بدید و مطمئن بشید که اون قطعه کد داخل finally حتما اجرا میشه چه کد شما خطا داشته باشه چه نداشته باشه.

برای مثال شما میخواید یک قطعه کدی بزنید که ممکنه خطا داشته باشه ولی نمیخواید که توی همون متد خطا رو catch کنید یعنی میخواید از بیرون catch کنید ولی یک قطعه کدی رو میخواید بنویسید که در هر صورت اون اجرا بشه چه تابع شما به خطا بخوره چه نخوره.

try
{
 //your code
}
finally
{
 //your code
}

در قطعه کد بالا اگر توی try به خطا برخورد کنید چون catch نکردید تابع به طور کامل break میشه تا زمانی که خارج از تابع catch داشته باشید ولی قطعه کد داخل finally حتما اجرا خواهد شد.مثلا برای dispose کردن یک dbContext یا یک استریم این میتونه براتون کاربردی باشه.البته اگر هم catch داشته باشید در هر دو صورت هم finally اجرا خواهد شد.

یک مثال بارز این کد که در بالا نوشتم استفاده از کلیدواژه ی using هست.using در واقع تشکیل شده از یک try و finally بدون catch هست که تضمین میکنه که چه کد شما به خطا بخوره و چه نخوره تابع Dispose کلاس شمارو صدا بزنه.

@csharptips

قابلیت ثبت اعتبار سنجی برای پارامتر های ورودی توابع سرویس ها در سیگنالگو

Add validations for parameters of service method in SignalGo

کلاس های استاتیک اصولا کلاس های Single Instance هستند یعنی یکبار در حافظه ساخته میشن و تا اخر اجرای برنامه (یا لود بودن AppDomain) در حافظه میمونن،کانستراکتور های Static هم توی سی شارپ کاربرد های جالبی دارن مثلا هر وقت اون کلاس Static قرار بود یکبار توی حافظه ساخته بشه این کانستراکتور فقط یکبار توی کل روند برنامه صدا زده میشه، مثلا شما برای شروع یک Engine و یا Background worker میتونید از این کانستراکتور جالب استفاده کنید و داخلش job رو شروع کنید بدون اینکه نگران باشید که جایی لازم باشه متد Start رو صدا بزنید چون کلاس های استاتیک و کانستراکتور های استاتیک فقط وقتی بارگزاری میشن (یعنی یک Instance از کلاس ساخته میشه) که توی کد ازشون استفاده بشه و در روند اجرا شدن برنامه توی حافظه ساخته نمیشن بلکه فقط وقتی ساخته میشن که توی یک خط کدی ازش استفاده کنید.مثلا اگر کاربر روی یک دکمه کلیک کنه که توی متد اون دکمه از اون کلاس استاتیک استفاده کنید اینجا تازه اون کلاس استاتیک توی حافظه ساخته میشه و کانستراکتور استاکیش صدا زده میشه.
و همچنین اگر یک کلاس جنریک داشته باشید به ازای هر نوع مختلف از T یک Instance جداگونه از اون کلاس استاتیک و کانستراکتورش خواهید داشت، مثلا MyClass<int>.Name با MyClass<string>.Name مقادیرش توی حافظه مختلف خواهند بود ولی هر کدام Static هستند و یکبار در حافظه ساخته شدند و کانستراکتور های خودشون رو هم دارند.
#سی_شارپ
#Static
#CSharp

@CsharpTips

تقلید چیز خوبی نیست، نه در دین و نه در برنامه نویسی، تقلید چیزیه که انسان رو گمراه میکنه، آدم باید خودش به حقیقت برسه و تقلید چیزیه که باعث تعصب میشه اگر ما از یک سری ساختار در برنامه نویسی به عنوان استاندارد جهانی تقلید میکنیم خودبخود برای اینکه اون ساختار رو برای کسی توجیه کنیم و یا توضیح بدیم میگیم این یک "استاندارده" و همه دارن ازش استفاده میکنن من به شخصیه با این قضیه به شدت مخالفم، هیچ استانداردی وجود نداره و اگر داره، کاری که شما میکنید، ساختاری که شما میچینید هم میتونه یک استاندارد باشه و اینکه کلا جهان ساختار شمارو متوجه نمیشن به این معنی نیست که شما نمیفهمید یا در اشتباهید بلکه به این معنی میتونه باشه که شما از اینده اومدید و تفکری پیشتازتر دارید.
توی برنامه نویسی اصلا دوست ندارم از ساختار و استاندارد های دیگران استفاده کنم همه چیز توی ذهن من به طور پیشفرض مسیر اشتباهی رو طی میکنن مگر اینکه دلیل منطقی ای براش باشه، استفاده از کلمه های استاندارد جهانی یا چیزی که همه قبولش دارن برای من سیستم و درست بودن ساختار رو توجیه نمی کنه، اگر اینطور فکر کنید همیشه برای کارهایی که میکنید راه کار های بهتر و راحت تر به ذهنتون میرسه، متفاوت فکر کردن اشتباه نیست همه ی تکنولوژی ها ایده ها و ساختار های جدید وقتی تولید شدن که افراد متفاوت فکر کردن. متفاوت فکر کردن که دات نت کور ساخته شد متفاوت فکر کردن که برق اختراع شد متفاوت فکر کردن که هواپیما اختراع شد و دنیا رو متحول کردن.
استاندارد خودتون رو داشته باشید، شاید یه روزی اونی که دنیا رو متحول میکنه شما باشید.
آرزوی موفقیت.
#تقلید
#استاندارد
@CsharpTips

ساختارها(structure)،تفکر ها و الگوهای (patterns) برنامه نویسی برای این ساخته و برخی استاندارد شده اند تا طراحی و پیاده سازی زیرساخت و برنامه ها اسون تر و قابل فهم تر باشن. به شکلی که بقیه برنامه نویس ها بتونن پروژه شمارو درک کنن و توسعه بدن بدون اینکه بخوان همش با سازنده در ارتباط باشن و داکیومنت های مختلف بخوان، روی توسعه تمرکز کنن.
فریم ورک هایی مثل ABP,asp.net zero وجود دارن که زیرساخت اپلیکیشن رو از پیش پی ریزی کردن، به عنوان مثال مباحث احراز هویت، سرویس ها و دیتابیس(ef) و یک رابط کاربری پیش فرض که هم نسخه angular و هم و mvc ajax داره که پیشفرض برپایه SPA هست.

فریمورک abp بر پایه معماری و تفکر DDD و الگوهایی مثل Dependency injection همراه قابلیت ها‌و پترن های دیگه ای مثل auto mapper, entity framework, identity, service injection و ...که برخی توسط خود abp کاستوم شده و قابلیت extensions هایی بهشون اضافه شده که چهارتاشم بیشتر استفاده نمیکنین حالا ولی خوبن.
پروژه ها و لایه هاتون. برای هر کدوم شما دامین ها و dto هاتون رو پیاده سازی میکنید. logic و سرویس هاتون رو مینویسید و اینترفیس هاتون رو برای هر کدوم تعریف میکنید، همچنین از برخی کلاس ها و اینترفیس های abp ارث بری میکنید مثل application service و crud تا براتون سرویس های restful ساخته بشه و عملیات های کلاینتتون رو انجام بدین.
اگه میخواین یکم‌تمیز تر‌ باشین لایه های core, contract و shared رو برای شما گزاشتن.
البته یادتون نره کامنتم بزنین بلکه یکی دیگم بفهمه!
دیتابیس تون و جداولتون رو مینویسین و به کاستوم مپ auto mapper میفهمونین( یا حداقل سعی میکنین بفهمونین) که باید با چه DTO هایی در ارتباط باشه. یک طرفه باشه یا دو reverse یا همشو؟!
مدلهای dto صفحه بندی شده paged با ارث بری از کلاس های پیشفرضش میسازید و خواص، فیلتر ها رو برای سرچ تعیین میکنین(اگر به Paging و Huge List ها نیاز هست)

مباحثی مثل نقش ها و دسترسی ها، چند مستاجری (Tenant) و چند زبانی (multi linguql) پیشفرض وجود داره و میتونین کانفیگ کنین.
وقتی backend‌ رو پیاده کردین نسخه کلاینت رو میگیرین. آنگولار یا mvc/jquery
با استفاده از swagger و اسکریپت خودش، میتونین تمام dtoهای سرویس هاتون رو برای کلاینت بسازید(Generate) و شروع به نوشتن کامپوننت و سرویس هاتون برای استفاده بکنین و از شیوه خودش بهره ببرین به لطف type script.
اگر آنگولار رو برای ui انتخاب میکنین باید حوصله بیشتری خرج کنین، پکیج ها و کتابخونه ها رو با npm یا yarn نصب و اپدیت کنین(اپدیت پیشنهاد نمیشه این اول چون احتمال سفید شدن موهاتون زیاده تا کانفلیکت ها و compatibility ها رو تنظیم کنین. به نسخه ۹ که اصن هیییچ) و از داکیومنت های بی انتهای abp یا zero بهره ببرید تا منوها، صفحه ها و سرویس هاتون رو توسعه بدین.
باشد تا متوجه شوید که هر کدوم چکار میکنن.

اگر Mvc رو انتخاب میکنین باید با js و jquery سر‌ و کله بزنین و کلاینتتون رو برای اسفاده طراحی کنین. مواظب باشین دچار سندروم جاوا اسکریپت نشین!!
ویژوال استادیو هم هنوز یکم نفهمه درست جاوا اسکریپت نمیفهمه.
vscode پیشنهاد میکنم برای هر دو.
تا اینجای کار که بدک نیست و سریع میشه پروژه زد و توسعه داد و فیچر هارو بالای هم چید و پابلیش بدیم مشتری حال کنه مام حال کنیم با یک عالمه کد :)

در یک پست دیگه منظورم رو کاملتر میگم و از اندک تجربم هم براتون بیشتر مینویسم.
@csharpfriends @CsharpTips

Signalgo version 5.5.5 released:
1.Support for custom compression and decompression
2.Fix some bugs

https://www.nuget.org/packages/SignalGo.Net.Server/
https://www.nuget.org/packages/SignalGo.Net.Client/

دو نوع برنامه نویس داریم:
1.برنامه نویس هایی که چرخ ها رو از اول اختراع می کنن
2. برنامه نویس هایی که از چرخ هایی که دیگران استفاده کردند برای توسعه اپلیکیشن هاشون استفاده میکنن.

من توی دسته ی اول هستم.شاید از دیدگاه شما جالب نباشه و همیشه با خودتون فکر کنید که وقتی توی دسته ی دوم قرار بگیرید میتونید سریعتر کد بزنید و سریعتر توسعه بدید.

اما دسته ی دوم دوتا مشکل داره:
1.محدودیت
2.وابستگی

اگر برنامه نویس حرفه ای باشید میدونید چه وقتهایی باید توی دسته ی اول قرار بگیرید و چه وقتهایی باید توی دسته ی دوم قرار بگیرید. دقیقا وقتی باید چرخ رو اختراع کنید که:
1.محدودیت زیادی توی استفاده از کامپوننت دارید مثل باگ، فیچر ها و ...
2.احساس کنید اختراع چرخ از استفاده از کامپوننت بقیه سریعتر اتفاق میوفته

برای مثال ما یک جا توی شرکت بنا شد قسمتی از پروژه رو از دیتابیس No Sql استفاده کنیم، خب طبق معمول همه پیشنهاد دادن بریم سراغ Mongo db در حالی که من میدونستم نوشتن چیزی مثل دیتابیس No Sql برای من زیاد طول نمی کشه فلذا باهاشون مخالفت کردم و توی کمتر از 8 ساعت دیتابیس No Sql زدم و توی کمتر از یک هفته هم Provider اش رو برای EF Core زدم تا با کمترین تغییرات سیستممون لانچ بشه و شد.
اما مزیت این چی بود؟
1. سرعت
2.بسیار سبک و سریع در حد سه تا کلاس سی شارپ (بدون در نظر گرفتن Provider)
3.تجربه و اعتماد
4.عدم وابستگی و محدودیت
5.بدون نیاز به تغییرات خاص

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

سوال یکی از کاربران در مورد Query و Data Exchanger توی سیگنالگو که نسخه ی آزمایشی اون رو توی Nuget منتشر کردم:

https://github.com/SignalGo/SignalGo-full-net/issues/26

یکی از قابلیت هایی که جدیدا به سیگنالگو اضافه شده قابلیت جنریت کردن خروجی های سرویس ها برای سمت کلاینت با قابلیت حفظ نام برای Value Tuple های سی شارپ 7 هست.توی این نسخه نام های ValueTuple ها موقعی که برای سمت کلاینت جنریت میشن حفظ میشن و زیبایی کد ها حفظ میشه
@csharptips

ویدئوی آموزش سیگنالگو در لینوکس که توسط دوست و همکار عزیزم آقای سعید رضایی @mrgrayhat ساخته شده که میتونید توسط این آموزش یاد بگیرید که توی لینوکس چطوری یک سرور و کلاینت سیگنالگو رو با ویژوال استادیو کد و سیگنالگو کد جنریتور بسازید.

https://www.youtube.com/watch?v=WzbYpTiH2L8

کانال رسمی Signalgo Publisher :
پروژه ای که برای مدیریت و آپلود میکروسرویس های سیگنالگو بهتون کمک میکنه و قراره جایگزینی برای Docker و kubernetes باشه.بخش هایی که تا به امروز انجام شده و قابل استفاده است:
1.کامپیل کردن پروژه
2.اجرای تست های پروژه
3.پابلیش کردن پروژه روی سرور در صورت ی که تست ها Pass بشن
4.میتونید سرور های مختلفی داشته باشید، مثلا سرور های تست و اصلی که روی هر کدوم خواستید سلوشن هاتون رو پابلیش کنید.
5.و خیلی امکانات دیگه

هدف این بوده که برنامه نویس ها با کمترین دانش و بیشترین سرعت بتونن سرویس هاشون رو سریع روی سرور های مورد نظرشون پابلیش کنن.

https://t.iss.one/PublisherGo

#تخصصی
#پرفورمنس
#حرفه_ای
#سی_شارپ

نوع و طریقه استفاده از متغیر ها میتونه توی پرفورمنس تاثیر بسزایی داشته باشه، همه میدونیم دسترسی مقادیر به حافظه stack سریعتر از حافظه heap هست چون برای دسترسی به حافظه heap نیاز به یک اشاره گر در حافظه stack داریم در حالی که مقادیر value type ها به خودی خود اشاره به مقدار اون در حافظه stack میکنن، مثل این میمونه که شما مستقیم از شیر آب، آب بنوشید یا ابتدا آب رو توی یک لیوان بریزید سپس اون رو بنوشید. خب مسلما راه سریعتر برای سیراب شدن خوردن آب از شیر هست.

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

            for (int i = 0; i < test1.Items.Count; i++)
            {

            }

هر باری که حلقه میخواد ببینه به پایان رسیده یا نه مجبوره i رو با مقدار test1.Items.Count چک کنه و این یکم مشکل پرفورمنسی داره، چرا؟ چون توی قسمت test1 ابتدا باید یک اشاره به پوینتر کلاس توی حافظه استک کنه سپس بر اساس اون بره توی حافظه ی Heap و اشاره کنه به Items سپس اشاره کنه به Count این عملیات هر بار که شرط حلقه ی شما اجرا بشه اتفاق میوفته و شاید شما بگید چیز خاصی نیست ولی یک برنامه نویس بکند اگر هزاران خط کد اینشکلی داشته باشه که میلیون ها کلاینت دارن همزمان از این عملیات استفاده میکنن، اونوقت فاجعه افت پرفورمنس رو به وفور خواهید دید و با رعایت این مسائل براحتی میتونید پرفورمنس بهتری توی بکند داشته باشید

برای حل این مشکل باید چیکار کنیم؟

کاری که باید بکنیم اینه که ابتدا مقدار مورد نظر رو در یک حافظه Stack میریزیم.سپس به حلقه اجازه میدیم که مستقیم با همون متغیر که توی stack هست کار کنه.
به این شکل:

            int len = test1.Items.Count;
            for (int i = 0; i < len; i++)
            {

            }

@csharptips

چرا نباید از Async void استفاده کنیم؟

https://tinyurl.com/codehaks-avoid-async-void

این دیدگاه اشتباه هست که چرا نباید از async void استفاده کنیم.چون این خودش یکی از ویژگی های سی شارپ هست، توی برنامه نویسی Multi-Threading وقتی شما به صورت دستی یک Thread میسازید اگر توی اون ترد عملیات try catch انجام نداده باشید هم با خطای unhandle exception مواجه میشید و اپلیکیشن شما کرش میکنه و کاملا متوقف میشه هرچند با روش هایی میشه حتی unhandle exception ها رو هم هندل کرد.اما هیچ برنامه نویس Multi-Threading ای نمیاد یک ترد رو بدون try catch اجرا کنه تا با این خطا مواجه بشه در نتیجه استفاده از async void مستقیم هیچ اشکالی نداره که هیچ خیلی جاها هم کاربرد داره منتهی باید حواستون باشه که توی تابع باید از try catch استفاده کنید تا هنگام مواجه شدن با خطای unhandle exception خطا رو catch کرده باشید.

#csharp
#multi_threading

@csharptips

#تخصصی
#پرفورمنس
#حرفه_ای
#سی_شارپ

فرق struct ها با ref struct ها توی اینه که ref struct ها همون struct هستن با این تفاوت که در زمان کامپایل، کامپایلر سی شارپ به شما اجازه نمیده طوری کد بزنید که struct رو بفرستید توی heap و تضمین میکنه که همیشه متغیر شما توی stack قرار بگیره، چه وقتهایی struct ها در heap قرار میگیرن؟ وقتی که اونارو توی کلاس یا ارایه قرار میدین یا ... در نتیجه شما نمیتونید ref struct ها رو طوری تعریف کنید که توی heap قرار بگیرن و وقتی یک نوع ref struct تعریف میکنید خیالتون راحته که اون همیشه توی stack قرار میگیره و کامپایلر نمیذاره که اشتباها اونو توی heap بفرستید.

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

پ.ن: میزان فهم و سرعت یادگیری یک برنامه نویس تازه کار از معماری پروژه شما، سادگی یا پیچیدگی پروژه شمارو مشخص خواهد کرد.
#DependencyInjection

مقاله ای نوشتم با عنوان اشکالاتی که به دیزاین Solid وارد هست.گاهی اوقات فکر میکنیم اگر چیزی به عنوان استاندارد تعریف شد پس قاعدتا باید درست باشه، بنظر من فقط برای اینه که طرفدار بیشتر جمع کنیم وگرنه هیچ چیزی استاندارد نیست چون جهان در حال تغییر هست، و اگر استاندارد ها چیز هایی نیستند که ثابت باشند در نتیجه بهتره همیشه با منطق انتخاب کنیم تا در مقابل چیزی که نسبت بهش اطلاع نداریم بگیم این یک استاندارده و همه ازش استفاده میکنن!
@CsharpTips

فایل نمایشی پاور پوینت

آگر در نوع کوئری زدن ها و واکشی داده از دیتابیس، تعداد Include های یک کوئری خیلی زیاد باشد یعنی ساختار دیتابس شما نباید Relational و SQL باشد و باید از NoSQL استفاده کنید.
@csharptips