بعضی از قابلیت های سیگنالگو که شاید برای شما جالب باشد و برخی از آنها در داکیومنت ها یا آموزش ها نباشند که میتوانید از خودم بپرسید:
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
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
از محبوبیت زبان های برنامه نویسی بترسید، محبوب ترین زبان های برنامه نویسی توی دنیا داینامیک ترین اونها هستند که به صورت پیشفرض میتونید کثیف ترین کدها رو با اونها بزنید، بنابراین اصلا به این ننازید که با زبانی کار میکنید که کل دنیا دارن باهاش کار میکنن، وقتی چند تا کار بین المللی انجام بدید و توی پروژه های اپن سورس دنیا وارد بشید میبینید که داینامیک کد زدن هیچ کجا مرسوم نیست و ازتون میخوان کدهاتون رو داکیومنت کنید، فانکشنالیتی کد بزنید و ان کپسولیشن و ...رو رعایت کنید حالا فرقی نمیکنه با چه زبان برنامه نویسی ای کار میکنید این جنگ همیشه وجود داره.
اما نکته مهم اینه که همیشه شما با هر زبانی میتونید شلخته کد بزنید با هر زبانی هم میتونید زیبا و خوانا کد بزنید.
اگر زیبا و خوانا کد زدید این دلیل برتری زبان برنامه نویسی شما نیست (هرچند توی معماری نرم افزار تایپ سیف بودن بی تاثیر نیست)، این هنر دست شماست که تونستید کدی بزنید که همکاران شما بتونن بخونن و کارفرما احساس نکنه پولش رو دور ریخته
@csharptips
وقتی مایکروسافت میگه اینترفیس هارو مارکاپ نکنید یعنی اینترفیسی که خالیه نسازید بعد Abp میاد IApplication میسازه و میشه یه معماری مورد توجه دنیا منو یاد بنی اسرائیل میندازه خدا اونارو از ماهیگیری روز شنبه ممنوع کرده بود ولی اونا شنبه تور مینداختن و روز بعد تورارو جمع میکردن 😆😆
C# Programming Guide
وقتی مایکروسافت میگه اینترفیس هارو مارکاپ نکنید یعنی اینترفیسی که خالیه نسازید بعد 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 استفاده کنید.
یکی از دوستان گفتن اگر قرار باشه توی یک متدی از طریق شروط جنریک استفاده بشه چطوری میخواید بدون اینترفیس حلش کنید.
ببینید ما اصلا فقط وقتی روی جنریک های یک متد باید شروط بذاریم که حتما و حتما از اون شروط در داخل متد استفاده کنیم وگرنه وارد اشتباه دوم توی معماری شدیم.برای مثال به دو قطعه کد زیر دقت کنید:
کد اشتباه:
کد درست:
توی حالت صحیح اگر دقت کنید به راحتی میتونید تابع اینترفیس رو صدا بزنید حالا برنامه نویس مورد نظر از بیرون تابع میتونه سرویس کاوه نگار یا .. خودش رو به شما پاس بده. اما توی حالت غلط که مثال اول هست شما چیکار میتونید با اون اینترفیس انجام بدید؟؟ هیچ تابعی رو در حالت کامپایل تایم نمیتونید کال کنید برای همین مایکروسافت میگه نوشتن اینترفیس مارکر بی ارزش و اشتباه هست.اگر میخواهید کاری رو در حالت رانتایم انجام بدید فرضا توابع instance اون اینترفیس رو بررسی کنید در نتیجه شما دارید عملیات رانتایم انجام میدید لازم نیست معماری سیستم رو بهم بزنید تا برنامه نویس ده ها جا دنبال اینترفیس بره تا ببینه دقیقا کجاها داره برای چی استفاده میشه، بهتره که همه ی عملیات رو رانتایم کنید و در یک کلاس ReflectionHelper اینکار رو انجام بدید تا اینکه کدهای ناخوانا و پیچیده ایجاد کنید.
@CsharpTips
اول از همه لینک مایکروسافت در مورد اینکه اینترفیس مارکر نسازید:
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
Docs
Interface Design - Framework Design Guidelines
Learn more about: Interface Design
توی سریالایز کردن در 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
برای مثال اگر شما ی کلاس 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
C# Programming Guide
توی سریالایز کردن در grpc طبق معماری کنونی سریالایز کردن به صورت وراثتی خوب پیاده سازی نشده، این یعنی ساپورت میکنه اما برای پیاده سازی به شکل خیلی عجیبی باید در کلاس Base پیاده سازی بشه نه در کلاس فرزند. برای مثال اگر شما ی کلاس MessageContract داشته باشید…
شناخت ابزار ها و نقطه ضعف هاشون بهتون کمک میکنه که توی انتخاب ابزار بهترین گزینه رو انتخاب کنید و اگر میخواهید ابزاری بسازید حواستون به چالش هایی که ممکنه بهش برخورد کنید باشه.
بررسی این ابزار ها و اینکه چطوری کار میکنند بهتون شناخت بیشتری توی معماری نرم افزار میده و اینکه بدونید شرکت های بزرگ چطوری کار می کنند خیلی توی روند پیشرفت و برنامه نویسی بهتون کمک میکنه، بدترین قسمت اونجاست که به این نقطه برسیم که از اسم شرکت ها استفاده کنیم تا مدعی بشیم این ابزار خوبه چون فلان شرکت زده.
@CsharpTips
بررسی این ابزار ها و اینکه چطوری کار میکنند بهتون شناخت بیشتری توی معماری نرم افزار میده و اینکه بدونید شرکت های بزرگ چطوری کار می کنند خیلی توی روند پیشرفت و برنامه نویسی بهتون کمک میکنه، بدترین قسمت اونجاست که به این نقطه برسیم که از اسم شرکت ها استفاده کنیم تا مدعی بشیم این ابزار خوبه چون فلان شرکت زده.
@CsharpTips
Microservices
ASP.NET Core
ویس ضبط شده گفتگوی دوم #فری_تاک با موضوع Microservices - قسمت 1
DDD
ASP.NET Core
ویس ضبط شده گفتگوی سوم #فری_تاک با موضوع DDD
Clean Architecture
ASP.NET Core
ویس ضبط شده گفتگوی فنی #فری_تاک با موضوع Clean Architecture
Monitoring/Logging/Tracing/HealthCheck
ASP.NET Core
ویس ضبط شده گفتگوی فنی #فری_تاک با موضوع
Monitoring/Logging/Tracing/HealthCheck
Monitoring/Logging/Tracing/HealthCheck
C# Programming Guide
ASP.NET Core – Microservices
حیفه مطالبی که دوستان زحمت میکشن و جمع آوری میکنن پراکنده باشه بنظرم نظرات همدیگر رو بشنویم و یاد بگیریم خیلی توی پیشرفتمون تاثیرگذار هست، پیشنهاد می کنم این ویس هارو گوش کنید اگر میخواهید در مورد معماری های رایج در مورد میکروسرویس ها و ... اطلاعات کسب کنید. این ویس ها از خود مقاله ها میتونن تاثیر گذار تر باشن 👌👍
چطوری میتونیم بین دوتا دیتابیس مجزا مثل 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
به طور طبیعی اینکار ممکن نیست، اما پترنی برای انجام اینکار وجود داره و شما میتونید توسط این پترن بین این دوتا دیتابیس 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
@CsharpTips
Testing
DotNetZoom
✅ ویس ضبط شده هفتمین گفتگوی فنی #فری_تاک با موضوع Testing
ارائه دهندگان : محمدجواد ابراهیمی، معین تاجیک
_________________
@DotNetZoom
ارائه دهندگان : محمدجواد ابراهیمی، معین تاجیک
_________________
@DotNetZoom
CQRS
DotNetZoom
✅ ویس ضبط شده ششمین گفتگوی فنی #فری_تاک با موضوع CQRS
ارائه دهندگان : محمدجواد ابراهیمی، معین تاجیک
_________________
@DotNetZoom
ارائه دهندگان : محمدجواد ابراهیمی، معین تاجیک
_________________
@DotNetZoom
C# Programming Guide
DotNetZoom – Testing
ممنون از دوستان عزیز که زحمت کشیدن و مطالب زیادی رو جمع آوری کردن و کمک بزرگی به برنامه نویسان میکنن تا به جای مطالعه ده ها مقاله با گوش کردن یک ویس خیلی کلیات و بعضا جزئیات رو یاد بگیرن.
توی بحث تست مخصوصا بخش ماک یه موضوع مهمی فراموش شده من فقط نکاتش رو بیان میکنم که توی پروژه هاتون در نظر بگیرید.
توی بحث B2B یه مبحثی داریم که شما به مشتری هاتون سرویس های تست میدید تا اونا بتونن با منطق پروژه ی شما سناریوهای لازم رو تست بگیرن، برای مثال فرض کنید میخواید یک سرویس B2B برای Api پرواز به مشتری هاتون ارائه بدید و اونا برای اینکه بتونن سرویس های شمارو تست کنن لزوما نباید به صورت لایو عملیات booking رو انجام بدن، بنابراین بهتره توی این شرایط شما سرویس هاتون رو به صورت virtual شده در اختیارشون قرار بدید تا هرچقدر دوست دارن بتونن برای پیاده سازی سرویس هاشون سرویس های شمارو بدون مشکل و هزینه کال کنن.
من پیشنهادم اینه که شما تست های ماک خودتون رو که برای سرویس های خارجی (Api های خارج از شرکت) پیاده سازی میکنید اونو طوری پیاده سازی کنید که هم برای مبحث تست ها و هم برای مبحث virtual کردن برای مشتری های بیزینسی خودتون سرویس دهی داشته باشید.
بنابراین ماک کردن رو فقط برای اینکه بتونید سرویس های بیرونی رو virtual کنید تا تستهاتون بدون هزینه و با سرعت پس بشن انجام ندید برای اینکه هم برنامه نویس ها و تستر های پروژه شما بتونن همیشه فرایند های وبسایت شمارو کامل تست کنن ولی بدون هزینه و پیگیری کنسل کردن و ... و بدون اینکه لایو باشه ،هم اینکه مشتری های بیزینسی شما بتونن به صورت virtual از سرویس های شما داده دریافت کنن و بدون هزینه عملیات booking رو با ورودی های مختلف تست بگیرن.
#Mock
#Test
توی بحث تست مخصوصا بخش ماک یه موضوع مهمی فراموش شده من فقط نکاتش رو بیان میکنم که توی پروژه هاتون در نظر بگیرید.
توی بحث B2B یه مبحثی داریم که شما به مشتری هاتون سرویس های تست میدید تا اونا بتونن با منطق پروژه ی شما سناریوهای لازم رو تست بگیرن، برای مثال فرض کنید میخواید یک سرویس B2B برای Api پرواز به مشتری هاتون ارائه بدید و اونا برای اینکه بتونن سرویس های شمارو تست کنن لزوما نباید به صورت لایو عملیات booking رو انجام بدن، بنابراین بهتره توی این شرایط شما سرویس هاتون رو به صورت virtual شده در اختیارشون قرار بدید تا هرچقدر دوست دارن بتونن برای پیاده سازی سرویس هاشون سرویس های شمارو بدون مشکل و هزینه کال کنن.
من پیشنهادم اینه که شما تست های ماک خودتون رو که برای سرویس های خارجی (Api های خارج از شرکت) پیاده سازی میکنید اونو طوری پیاده سازی کنید که هم برای مبحث تست ها و هم برای مبحث virtual کردن برای مشتری های بیزینسی خودتون سرویس دهی داشته باشید.
بنابراین ماک کردن رو فقط برای اینکه بتونید سرویس های بیرونی رو virtual کنید تا تستهاتون بدون هزینه و با سرعت پس بشن انجام ندید برای اینکه هم برنامه نویس ها و تستر های پروژه شما بتونن همیشه فرایند های وبسایت شمارو کامل تست کنن ولی بدون هزینه و پیگیری کنسل کردن و ... و بدون اینکه لایو باشه ،هم اینکه مشتری های بیزینسی شما بتونن به صورت virtual از سرویس های شما داده دریافت کنن و بدون هزینه عملیات booking رو با ورودی های مختلف تست بگیرن.
#Mock
#Test
قبل اینکه Solid رو رعایت کنید معماری رو درست پیاده سازی کنید
#معماری
#solid
#javascript
#architecture
@CsharpTips
#معماری
#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
وقتی که به شما میگن یک سیستم پیامکی میخوام برامون بیارید بالا، اگر شما در پیاده سازی اون پروژه فقط و فقط درگیر مباحث و مسائل همون سیستم یا Api پیامکی شدید که میخواستید پیاده سازی کنید یعنی معماری سیستم شما درست پیاده سازی شده. اما اگر برای پیاده سازی این سیستم پیامکی درگیر این مباحث شدید معماری شما دارای ایراد هست:
1.دخل و تصرف توی سیستم های دیگه، مثلا ایمیل یا پرداخت یا ...
2.درگیر مباحث تکراری شدن:
فرض کنید شما قراره توی سیستم پیامکی چندتا سرویس کاوه نگار، ملی پیامک و ... رو پیاده سازی کنید اگر توی پیاده سازی اینها فقط درگیر پیاده سازی کردن ورودی و خروجی سرویسهای این Api ها شدید یعنی معماری رو درست پیاده سازی کردید اما اگر توی هر کدوم به صورت جداگانه درگیر ذخیره سازی در دیتابیس، کوئری ها و لاگ و مدیریت خطا ها و ... که مربوط به خود اون سیستم پیامکی نیستند شدید یعنی معماری درست پیاده سازی نشده و شما درگیر عملیات تکراری شدید و برای پیاده سازی سرویس جدید باید مجدد همه این راه ها رو تکرار کنید در حالی که برنامه نویس فقط باید درگیر چارچوب همون سرویس برای پیاده سازی بشه.
3.برکینگ چنج های سرسام آور:
معماری رو از ابتدا طوری پیاده سازی کنید و انواع تست هارو روی اون بگیرید و سناریو های مشخص و زیادی رو روش بررسی کنید تا کمترین برکینگ چنج هارو توی توسعه داشته باشید فراموش نکنید وقتی پروژه شما Release شد و مشتری داره از اون سرویس استفاده می کنه حتی نباید یک پروپرتی به کلاس ورودی یا خروجی اون سرویس اضافه کنید (منظور مشتری بیزینسی هست نه کلاینت خودتون که با برکینگ چنج شما میتونه کنار بیاد). شاید با خودتون فکر کنید اضافه کردن یک پروپرتی مشکلی ایجاد نمی کنه اما شما نمی دونید مشتری شما چطوری کد زده و ممکنه با اضافه کردن پروپرتی کدی که قبلا زده روی سیستمش کار نکنه بنابراین وقتی کارتون به مشتری نهایی رسید باید از خیر تغییر دادن اون سرویس بگذرید و ورژن بندی کنید.
4.شرط های تست و لایو:
توی پروژه هاتون نباید شرط هایی داشته باشید که چک کنن اگر روی تست بودم فلان کن اگر روی لایو بودم فلان کن چون وقتی پروژه شما لایو میشه نباید هر بار این شرط چک بشه چون روی لایو هستید و لزومی به چک کردن این شرط ها ندارید، چطوری این موضوع رو هندل کنیم؟
از طریق داده های دیتابیس یا کانفیگ ها میتونید پیاده سازی یک کلاس تست از یک کلاس لایو رو از هم جدا کنید بنابراین وقتی توی initialize اولیه پروژه هاتون بتونید به برنامه بگید الان سوییچ کن روی لایو یا الان سوییچ کن روی تست و در روند اجرایی برنامه دیگه این شرایط چک نشن یعنی راه رو درست رفتید و نرم افزار شما در فرایند لایو دیگه نمیدونه فرایند تست چیه و در فرایند تست دیگه نمیدونه فرایند لایو چیه و لازم نیست هربار این شرط که روی تست هستیم یا روی لایو چک بشه.
5.بروزرسانی سرویس ها:
موقع بروزرسانی سرویس ها کاربران نباید متوجه بروزرسانی بشن مگر اینکه خرابکاری کرده باشید 😂، بنابراین وقتی خراب کاری کردید میتونید به کاربرتون بگید صبر کنن تا بروزرسانی تموم بشه ولی توی حالت عادی کاربراتون باید بدون مشکل با سایت کار کنن.
چطوری هندلش کنیم؟
با استفاده از پترن Blue Green میتونید این مشکل رو حل کنید همیشه باید یک سرویس دیگه برای ارائه به مشتری داشته باشید،بنابراین وقتی مشتری داره با سرویس 1 شما کار میکنه سرویس 2 رو بروزرسانی می کنید و مشتری توسط Geteway برای درخواست های جدید به سرور 2 وصل میشه سپس سرویس 1 رو بروزرسانی میکنید بدین ترتیب مشتری متوجه بروزرسانی شما نمیشه فقط حواستون باشه وقتی سرویس در حال کار هست و مشتری ها دارن باهاش کار میکنن اونو Down نکنید و توسط Gateway هاتون باید مشتری هارو سوییچ کنید توی سیستمی که بروزرسانی شده تا درخواست ها از سرویس 1 به صفر برسه و سپس سرویس 1 رو بروزرسانی کنید.
شاید موارد دیگه ای هم باشه ولی فعلا به همین چند مورد بسنده کردم.
#Architecture
#معماری
@CSharpTips
میزان دانلود پکیج های سیگنالگو از مرز یکصد هزارتا گذشت
از سال 2016 پکیج سیگنالگو رو ساختیم تا ارتباط بلادرنگ بین کلاینت و سرورها رو فراهم کنیم به دلیل کمبود وقت فرصت نکردم همیشه بروزرسانیش کنم و همه ایده هایی که براش دارم رو اجرا کنم ولی امروز توی یوتراوز بیش از هفتاد میکروسرویس داره توسط پروتکل های سیگنالگو بدون مشکل با هم کار میکنه و ما کم کم اونو توسعه دادیم و به زودی ان شالله توسعه چشم گیری در اون خواهیم داشت
توسعه سریع
استفاده آسان
بدون ایجاد وابستگی
و باز بودن دست برنامه نویس برای پیاده سازی معماری خاص خودش بهش این امکان رو میده تا از پروژه های با سورس های کوچک تا پروژه های #Enterprise رو بشه باهاش پیاده سازی کرد
استفاده از چندین پروتکل همزمان روی یک سرویس بدون نیاز به کد زدن اضافی
کد جنریتور قوی برای متریال ویو ها و کلاینت انگولار و فلاتر
البته ایرانی های زیادی رو میشناسم که هیچوقت از کارم حمایت نکردن منظورم برنامه نویس هاست حتی خودشون هم وقتی این پست رو بخونن با خبر میشن😞
از سال 2016 پکیج سیگنالگو رو ساختیم تا ارتباط بلادرنگ بین کلاینت و سرورها رو فراهم کنیم به دلیل کمبود وقت فرصت نکردم همیشه بروزرسانیش کنم و همه ایده هایی که براش دارم رو اجرا کنم ولی امروز توی یوتراوز بیش از هفتاد میکروسرویس داره توسط پروتکل های سیگنالگو بدون مشکل با هم کار میکنه و ما کم کم اونو توسعه دادیم و به زودی ان شالله توسعه چشم گیری در اون خواهیم داشت
توسعه سریع
استفاده آسان
بدون ایجاد وابستگی
و باز بودن دست برنامه نویس برای پیاده سازی معماری خاص خودش بهش این امکان رو میده تا از پروژه های با سورس های کوچک تا پروژه های #Enterprise رو بشه باهاش پیاده سازی کرد
استفاده از چندین پروتکل همزمان روی یک سرویس بدون نیاز به کد زدن اضافی
کد جنریتور قوی برای متریال ویو ها و کلاینت انگولار و فلاتر
البته ایرانی های زیادی رو میشناسم که هیچوقت از کارم حمایت نکردن منظورم برنامه نویس هاست حتی خودشون هم وقتی این پست رو بخونن با خبر میشن😞