جدیدترین پکیجی که شروع کردم به نوشتن CodeReviewer هست، این پکیج قراره فقط به پروژه های تست شما اضافه بشه و یه سری تست کیس جدید به پروژه هاتون اضافه میکنه فرض کنید شما یکسری برنامه نویس تازه کار توی شرکتتون دارید که برخی از اصول های برنامه نویسی رو رعایت نمی کنند این پکیج قراره کار کد رویو رو برای شما آسون تر کنه، برای مثال اگر کسی توی نام گذاری پروپرتی ها یا کلاس های سی شارپ PascalCase رو رعایت نکنه یه سری تست ها Pass نمی شن و بهش هشدار میدن که کجا رو اشتباه کد زده، هرچند ویژوال استادیو خودش یه سری پیشنهاداتی برای اینکار داره اما دوتا نکته هست:
1.برنامه نویس های تازه کار همه چیز رو نمیدونن و از همه ی قابلیت های سی شارپ استفاده نمی کنند و همیشه شما باید کدهاشون رو چشمی Review کنید.
2.برای خیلی مسائل مثل Validation ها و اتریبیوت های خاص که باید برای یه سری کدها زده بشه همیشه ویژوال استادیو نمیتونه کمکتون کنه و شما برای اینکه به برنامه نویس هاتون یاد بدید که اصول و معماری رو درست رعایت کنند همیشه نیاز به رویو کردن کدهاشون دارید.

هرچند این پکیج رو تازه شروع به نوشتن کردم اما توی خیلی مسائل مخصوصا زمانی که از Pipeline های Azure استفاده میکنید تا تست ها پس بشه سپس پروژه ریلیز بشه کاربرد های جالبی میتونه داشته باشه.
هدف اصلی این پکیج انجام تست کیس هایی روی کدهای برنامه نویسان برای رعایت مسائل Clean Code و معماری پروژه هاتون هست.
پروژه Open Source هست و حتی خودتون هم میتونید جزو توسعه دهندگان اون باشید.
https://github.com/Ali-YousefiTelori/CodeReviewer

پکیج:
https://www.nuget.org/packages/CodeReviewer

@CSharpTips

تست بی کد 😆 این قسمت آهنگ خاطره انگیز رگ خواب از محسن یگانه:

رفع باگ این کد تو دست تو بوده
خطاهای سرویس تردست تو بوده
کدو با یه ترفند به باگا کشوندی
با یک شرط ناقص به دانتایم رسوندی

تو اجرا نکردی کد مشکوکم رو
ندیده گرفتی تست بی کدم رو

با این آرزویی که بی تست محاله
یه خط کد با مفهوم، فقط یک خیاله

چقدر حیفه این تست
همینجور هدر شه
یروزی یه کاربر بره دست به کار شه، بره دست به سر شه!

باید سر کنم با
همین تست خالی
حالا باگ رو سرور بگو در چه حالی

تو اجرا نکردی کد مشکوکم رو
ندیده گرفتی تست بی کدم رو

با این آرزویی که بی تست محاله
یه خط کد با کامنت، فقط یک خیاله

نکته آموزشی: توی ویژوال استادیو تست های تو خالی پس می شوند چون هیچ Assert ای ندارند 😳😆

@CsharpTips

آیا یک پروژه با معماری میکروسرویس همه چیز آن میکروسرویس هست؟
دسته بندی معماری پروژه ها توی برنامه نویسی کار اشتباهی هست، اینکه شما یک چیزی رو آکادمیک مطالعه کنید و تفکیک کنید قطعا مطالعات آکادمیک فقط مسیر نقشه رو بهتون نشون میدن اما اینکه واقعا توی اون مسیر به چه معضلاتی میخورید رو هیچ کجا نمی تونید پیدا کنید و کاملا بستگی به نوع و بزرگی پروژه هاتون داره.حتی ممکنه 180 درجه با اونچه که مطالعه میکنید فرق داشته باشه بنابراین تجربه همیشه حرف اول رو میزنه.
داستان معماری های Monolith یا SOA یا Microservice یا ... مثل مقایسه ی بین Mongo و Sql میمونه، اصلا کسی که اینارو با هم مقایسه میکنه حداقل از نظر من یعنی پروژه میکروسرویسی اجرا و لانچ نکرده، خب قطعا شما توی پروژه هاتون بسته به نوع درخواست ها و سناریو ها هم ممکنه از SQL استفاده کنید و هم Mongo اونم به طور همزمان بنابراین کسی که بیاد بگه مونگو بهتره یا SQL پرفورمنس بیشتری داره و مزیت هاشون نسبت به هم چی هست اصلا متوجه موضوع و فرق بین این دو نشده، تفکیک این دو توی سناریوی پروژه مشخص میشن نه اینکه انتخابی بینشون داشته باشیم.
توی معماری نرم افزار، توی بازه های پروژه های خیلی بزرگ تر دیگه SOA یا Microservice معماری نمیشن، تبدیل به یک پترن میشن، دقت کنید معماری یعنی یک چارچوب خاصی که شما باهاش کد میزنید پترن یعنی نقشه راهی که باهاش معماری رو میچینید. چرا میگم اینا تبدیل به پترن یا الگو میشن؟ چون هرچی بازه ی پروژه شما بزرگتر میشه معماری پروژه شما هم خاص تر میشه (خاص همون پروژه)، بنابراین یک قسمتی از کار رو شما میتونید از پترن SOA یا Monolith و یا Microservice استفاده کنید یعنی ترکیب همه ی اینها که حالا اسمشو میتونید بذارید Aggrigator مطابق مطالعات آکادمیکی که میتونید بدست بیارید یکی از پترن های میکروسرویس هست. اما در نهایت کل سیستم شما که داره برای مشتری ارزش آفرینی میکنه میشه معماری یا ساختار یکپارچه ای که شما به مشتریهاتون سرویس میدید. همچنانکه شما نمیتونید بگید ساختار دیتابیسی شما SQL هست یا No SQL بلکه ترکیبی از این دو هست به همین صورت نمیتونید بگید سیستم شما میکروسرویسی هست یا SOA یا ... ولی میتونید بگید بله ما از معماری یا همون الگوی میکروسرویسی هم توی پروژمون استفاده می کنیم، معماری برای تفهیم موضوع کل ساختار و الگوی پروژه های شرکتتون و الگو یا پترن برای تفکیک قسمتی از پروژه استفاده اش بنظرم مشکلی نداره
بازم میگم تجربه حداقل صد قدم جلو تر از مطالعات آکادمیک هست.اصلا روی اینکه آکادمیک مطالعه کنید و از اسامی هم همونطور استفاده کنید قفل نکنید، مثلا نگید ما معماری پروژمون میکروسرویس هست و بعد من بپرسم آیا توش SOA هم دارید و بگید نه در حالی که اون قسمتی که دارید به مشتری سرویس میدید صد در صد SOA هست نه میکروسرویس.یا وقتی از پترن Aggrigator استفاده میکنید دیگه از تعریف میکروسرویس خارج میشید و به همون SOA میرسید یا اگر توی همون SOA دیتابیس خودش رو دارید که ترکیبی از میکروسرویس ها هم استفاده می کنید قطعا شما Monolith هم زدید.
اینارو بر حسب تجربه میگم برای همین میگم روی کلمات گیر نکنید کسانی که مقالات (حتی خارجی) در مورد مقایسه ساختار های Monolith و Microservice مینویسن شک نکنید همه ی پروژه هاشون رو فقط Monolith یا SOA یا Microservice نمیزنن و یک پروژه با مقیاس بزرگ همه ی اینها رو دربر خواهد داشت و این طبیعت کار هست.
@CSharpTips

علت اینکه توی کمتر چند روز تلاش تونستم عضو Contributor های EF Core مایکروسافت بشم و کدهارو متوجه بشم و توسعه بدم این نبود که از زیر ساخت های مایکروسافت و گوگل استفاده کردم، علتش این بود که من عادت به تقلید ندارم و زیرساخت و معماری خودم رو میسازم، اما چطوری؟ اینطوری که زیرساخت های مایکروسافت و دیگر شرکت هارو مطالعه میکنم و سعی میکنم براش روش بهتری بسازم تا برنامه نویس ها راحت تر کد بزنن و کار کردن با ابزار های جدید براشون راحت تر باشه، مطالعه کد ها بیشتر از مطالعه مقالات باعث پیشرفت میشن اگر میدونستید. و برای اینکار نیاز به فهم عمیق کارکرد اون پروژه ها دارم که توی دلشون چطوری کار میکنن، برای همین وقتی زیر ساخت های خودم رو ساختم فهمیدن کد های شرکتهایی مثل مایکروسافت برام چیزی نداشت و براحتی برام قابل توسعه بود.
مقلد نباشید.
@CsharpTips

لایه authentication بالاترین لایه سرویس های شماست یعنی اولین سرویسی که کاربر صدا میزنه باید احراز هویتش مشخص باشه و لایه دیتابیس پایینترین لایه حالا اگر شما میخواید اطلاعات کاربر رو توی لایه دیتابیس بیارید یعنی به عبارت ساده دارید سر نرم افزار رو به تهش وصل میکنید 😆 بعضی کارارو نباید انجام بدید هرچند معماری ای که دارید استفاده میکنید این اجازه رو به شما میده چون اگر سر نرم افزار بتونه توی ته نرم افزار باشه یعنی میتونه همه جا باشه پس یعنی برای رفع باگ مربوط به احراز هویت میتونید کل نرم افزار رو بررسی کنید، نکنید اقا 😁 بیشتر فکر کنید و جاشو همونجایی که هست حفظ کنید دیوار بکشید تا توسعه اپلیکیشن های بزرگ براتون راحت تر باشه
@csharptips

یه نکته توی EF Core رو فراموش نکنید، مدل ها به ازای هر Context کش میشن. این یعنی شما نمیتونید یک context داشته باشید و در طول برنامه ازش استفاده کنید چون اگر در طول برنامه مقدار یک پروپرتی تغییر کنه و همچنان از context قبلی استفاده کنید مدل های اون context بروز نمیشن.
یکی از دلایلی که به ازای هر رکوئست باید Context رو new کنید همین مساله هست.
شاید اصولا به این مشکل نخورید چون توی رکوئست هاتون همیشه context ها new میشن، اما یه جایی ممکنه شما هم یادتون بره و اونم توی background worker ها هست که چون همیشه یک عملیات ثابت داره برای دیتابیس اتفاق میوفته شاید با خودتون فکر کنید اگر یک context داشته باشم هزینه کمتری داره، اما اینجاست که نگه داشتن فقط یک context باعث به وجود اومدن کش میشه و دیگه context شما متوجه تغییرات دیتابیسی نخواهد شد.

#EFCore
@CSharpTips

بعضی از قابلیت های سیگنالگو که شاید برای شما جالب باشد و برخی از آنها در داکیومنت ها یا آموزش ها نباشند که میتوانید از خودم بپرسید:
1.قابلیت ErrorHandling:
در سیگنالگو Duplex وقتی سرور با یک exception ای مواجه می شود آن را به سمت کلاینت ارسال میکند و برای کلاینت هم همان خطا throw میشود، اما اگر شما میخواهید به جای exception خوردن سمت کلاینت یک خروجی خاص مثل MessageContract با issuccess = false برگردونید میتونید از این قابلیت استفاده کنید و به صورت global یا customize خروجی متد رو همیشه بدون Exception به سمت کلاینت ارسال کنید، تنظیمات گلوبال سیگنالگو برای همه ی پروتکل ها مثل Rest ، Duplex ، Wesocket ، Oneway اعمال خواهند شد هرچند بازم توانایی شخصی سازی دارند.
2.توی سیگنال میتونید یک وبسایت رو به طور کامل به صورت Self-host بالا بیارید بدون نیاز به iis مثلا یک سایت انگولار
3.توی سیگنالگو میتونید یک متد گلوبال داشته باشید که وقتی کاربر فقط دامنه رو صدا میزنه اون متد Call میشه بدون اینکه ادرس Api رو بزنه.
4.وقتی دارید برای یک api مثل بانک callback میسازید ولی نمیدونید که اون بانک چه پارامتر هایی برمیگردونه میتونید یک تابع داشته باشید و پارامتر ها رو به صورت داینامیک بگیرید بعد پارسشون کنید.
5.شما میتونید برای سرویس ها و توابعتون محدودیت برای آی پی های خاص مشخص کنید
6.شما میتونید lock همزمانی برای متد ها یا سرویس هاتون بذارید.
7.یه قابلیتی به نام DisposableTransactionObjects وجود داره که توانایی اینو داره که آبجکت هایی که یادتون رفته dispose کنید رو براتون dispose میکنه، یا میتونید کاستوم کنید اگر آبجکتی رو یادتون رفته dispose کنید یا از using استفاده کنید بهتون خطا بده.
8.شما میتونید سریالایزر کاستوم برای ابجکت هایی که قابلیت سریالایز شدن به json ندارن بنویسید.
9.یک سرویس کامل Signalgo توانایی اینو داره که بدون تغییرات در کد به صورت کامل روی IIS هاست بشه.
10. با دو خط کد ناقابل سرویس های سیگنالگو رو تبدیل به بات تلگرام کنید.
11.به صورت Self-Host پروتکل Https رو روی سیگنالگو تنظیم کنید.
12.پکیج آزمایشی DataExchanger هم آمادست تا به شکل graph روی متد هاتون کوئری ارسال کنید.
13.توانایی Bind کردن داده های ورودی با Dto هاتون رو خواهید داشت که فقط یه سری دیتا از یک Dto سمت کلاینت ارسال یا دریافت بشه.
14.قابلیت Reference Resolver که لوپ رو توی مدل هاتون هندل میکنه و تا کلاینت هم لوپ ارسال و هندل میشه.
15.قابلیت کاستوم سازی جنریت کردن سرویس ها برای کلاینت مثلا سرویس های ادمین از سرویس های کلاینت جدا شوند و جنریشن برای هر کدوم جداگانه فقط توابع خودشون رو جنریت کنن.
16.قابلیت ساخت پارامتر Fake برای جلوگیری از کش مرورگر
17.ولیدیشن های خاص و قدرتمند روی پارامتر های ورودی سرویس ها و کلاس ها و پروپرتی هاشون
18.مدیریت کامل پروتکل Http به همراه header هایی که کاربران میفرستند و ساختن چیزهایی مثل Expire date برای session ها و ...
19.قابلیت ModelMapp برای کد جنریتور که باهاش میتونید مدل های سمت کلاینت رو کاستومایز کنید مثلا پروپتری بهش اضافه یا ازش کم کنید! یه قابلیت بسیار کاربردی برای کسانی که میخوان کلاینت و سرورشون رو کامل با سیگنالگو انجام بدن.
20.قابلیت Priority برای متد ها سمت کلاینت در صورت قطع شدن اتصال سمت کلاینت که در این صورت میتونید بهش بگید قبل از صدا زدن هر تابع اول لاگین مجدد انجام بشه برای ارتباط های Duplex که این امکان رو به شما میده همیشه کاربر برای صدا زدن توابع لاگین باشه
21.قابلیت فشرده سازی داده ها
22.مدیریت داده های بزرگ در وب سوکت به دلیل محدود بودن ارسال داده در این پروتکل
23.قابلیت کاستوم کردن امنیت تبادل اطلاعات بین کلاینت و سرور
24.قابلیت جنریت کردن اتوماتیک سمت کلاینت توسط Code Generator که به دو حالت Desktop App و VS Extension نوشته شده.
25.اپلیکیشن Desktop App سمت کلاینت برای تست سرویس های سرور که شبیه پستمن هست اما همه ی سرویس ها و کدهارو براتون جنریت میکنه و نیازی به درج و حذف اونا ندارید.
26.قابلیت جنریت کردن کد ها برای سی شارپ،فلاتر (دارت)، جاوا، انگولار،سوییفت و پستمن!
27.مدیریت و پیاده سازی Authentication به روش کاملا Customize
#SignalGo
@CSharpTips

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

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

اگر زیبا و خوانا کد زدید این دلیل برتری زبان برنامه نویسی شما نیست (هرچند توی معماری نرم افزار تایپ سیف بودن بی تاثیر نیست)، این هنر دست شماست که تونستید کدی بزنید که همکاران شما بتونن بخونن و کارفرما احساس نکنه پولش رو دور ریخته
@csharptips

وقتی مایکروسافت میگه اینترفیس هارو مارکاپ نکنید یعنی اینترفیسی که خالیه نسازید بعد Abp میاد IApplication میسازه و میشه یه معماری مورد توجه دنیا منو یاد بنی اسرائیل میندازه خدا اونارو از ماهیگیری روز شنبه ممنوع کرده بود ولی اونا شنبه تور مینداختن و روز بعد تورارو جمع میکردن 😆😆

چون یکی از بچه ها توی پست قبلی سوال کرده بود ترجیحا موضوع رو بیشتر توضیح میدم که بیشتر متوجه بشیم چرا این حرکت اشتباهه.
اول از همه لینک مایکروسافت در مورد اینکه اینترفیس مارکر نسازید:
https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/interface?redirectedfrom=MSDN

دوم لینک ABP برای اینکه اینترفیس مارکر ساخته:
https://aspnetboilerplate.com/api-docs/html/T_Abp_Application_Services_IApplicationService.htm

خب سوال اینجاست که چرا اصلا نباید اینکار رو بکنیم، ببینید توی معماری نرم افزار هر چیزی که میسازید باید براش دلیل خوبی داشته باشید تا کدهاتون برای خوانندگان خوانایی داشته باشه من به عنوان کسی که میخوام کد شمارو بخونم وقتی یک اینترفیس خالی میبینم اولین چیزی که به ذهنم میرسه اینه که یک کلاس از طریق ارث بری این اینترفیس قراره چه چیزی رو پیاده سازی کنه؟ هیچی نمیفهمم باید برم جاهایی که ازش ارث برده بفهمم؟ خوب اونجا ها هم نمیفهمم! باید برم توی متد هایی که شروطی برای بررسی این اینترفیس دارن؟ دیدید چقدر سخت شد؟
اصلا چرا ما اینترفیس میسازیم؟ فلسفه ساختن اینترفیس برای این هست که در زمان کامپایل جلوی خطاهای کامپیوتر در حال پردازش اطلاعات گرفته بشه تا در زمان اجرا دیگه اشاره گر های کلاس ها چک نشه و برای برنامه نویس ها مزیتش اینه که بتونن جلوی خطاهای پیاده سازی خودشون رو بگیرن و توسعه یک کلاس با پیاده سازی های متعدد براشون آسون تر باشه.
بنابراین اینترفیس ها خیلی مهم هستن اما اگر اینترفیس مارکر بسازید هیچ مزیتی نه در حالت کامپایل و نه در حالت توسعه ایجاد نکردید.برای مثال من یک اینترفیس دارم با متد Send که قراره ارسال اس ام اس رو پیاده سازی کنه.
اونوقت سه تا API دارم:
1.کاوه نگار
2.ملی پیامک
3.قاصدک

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

    public interface IApplicationService
    {

    }

    public static class ServiceExtensions
    {
        public static void SendSMS<TApplication>(this IApplicationService service)
            where TApplication : IApplicationService
        {
            //
        }
    }

کد درست:

    public interface ISMSSender
    {
        void Send(string message, string number);
    }
    public static class SMSExtensions
    {
        public static void SendSMS<TSender>(this TSender sender, string message, string number)
            where TSender : ISMSSender
        {
            sender.Send(message, number);
        }
    }

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

توی سریالایز کردن در grpc طبق معماری کنونی سریالایز کردن به صورت وراثتی خوب پیاده سازی نشده، این یعنی ساپورت میکنه اما برای پیاده سازی به شکل خیلی عجیبی باید در کلاس Base پیاده سازی بشه نه در کلاس فرزند.
برای مثال اگر شما ی کلاس MessageContract داشته باشید و یک کلاس MessageContract<T> که ازش ارث ببره برای اینکه بتونید اونو به صورت جنریک سریالایز کنید حتما باید در کلاس پدر بگید که چه نوع هایی از MessageContract<T> رو ساپورت میکنه این یعنی اگر شما از کلاس فرزند n تا نوع داشته باشید در نتیجه باید روی کلاس پدر n تا اتریبیوت بذارید البته از طریق Fluent هم میتونید اینکار رو بکنید ولی تغییری در روند و معماری اشتباه grpc ایجاد نمی کنه.
یکی از مباحثی که احتمالا ممکنه توی استفاده اش به مشکل بخورید بحث global exception handling هست که توی این حالت اگر middleware داشته باشید نمی تونید همه ی n تا تایپ رو خروجی بگیرید و سریالایز کنید کلی باید کد بزنید و بی معنیه که برای تک تک توابعتون هم try catch بذارید در نتیجه ترجیح میدید توی midleware نوع MessageContract یعنی کلاس پدر رو برگردونید که منطقی هم هست اما توی grpc توی دیسریالایز به مشکل خواهید خورد چون سرویس کلاینت (یا میکروسرویس) میخواد از نوع MessageContract<T> دیسریالایز کنه که باید برای هندل کردنش یک midleware دیگه سمت کلاینت بسازید و ابتدا به MessageContract دیسریالایز کنید سپس دستی اونو تبدیل به MessageContract<T> کنید.
🤪

#OOP
#معماری
#گوگل

@CSharpTips

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

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

چطوری میتونیم بین دوتا دیتابیس مجزا مثل SQL و NoSQL عملیات Transaction رو انجام بدیم؟
به طور طبیعی اینکار ممکن نیست، اما پترنی برای انجام اینکار وجود داره و شما میتونید توسط این پترن بین این دوتا دیتابیس transaction بزنید.
1.در صورتی که هر دو دیتابیس SQL و NoSQL قابلیت transaction رو داشته باشن:
در این روش شما میتونید ابتدا اطلاعات رو به صورت transaction توی دیتابیس ها ذخیره کنید بدون اینکه transaction ها رو commit کنید، سپس اگر هر دو transaction با موفقیت اطلاعات رو تونستن به ثبت یا حذف برسونن اونوقت transaction هر دو دیتابیس رو Commit کنید و اطلاعات رو ذخیره کنید.
2.در صورتی که فقط یکی از دو دیتابیس قابلیت transaction داشته باشن:
در این روش ابتدا کوئری رو روی اون دیتابیسی که قابلیت transaction داره اجرا می کنید ولی commit نمی کنید سپس کوئری رو روی دیتابیسی که transaction نداره اجرا می کنید اگر دیتابیس دوم به خطا نخورد transaction دیتابیس اول رو کامیت می کنید، در غیر این صورت اگر دیتابیس دوم خطا بخوره دیتابیس اول هم تغییراتش نباید commit بشه.

ما توی سیستم خودمون ساختار SQL و No SQL هامون یکی هست یعنی برنامه نویس اصلا متوجه این نمیشه که کوئری ها رو باید برای sql یا no sql مجزا بزنه هر دو یک شکل هستن فقط توی زیر ساخت مشخص میکنیم که این context قراره sql باشه یا no sql و تبدیل یک دیتابیس sql به no sql فقط با یک ارث بری فاصله داره و ساختار transaction بین دوتا دیتابیس مجزا رو توی هسته این سیستم پیاده سازی کردیم به همین روش هایی که در بالا توضیح دادم.

#CSharp
#EFCore
#Transaction

@CSharpTips

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

@CsharpTips