دو تا از مهمترین مولفه هایی که Dependency Injection باعث کندی پرفورمنس توی سیستم شما و شلخته شدن معماری پروژه شما میشه اینا هستند:

1.شما در یک کلاس سرویس دوتا interface رو inject میکنید در حالی که ممکنه در بعضی از سرویس هاتون (متد هاتون) از اونا استفاده نکنید.این یعنی بخواید نخواید اون Dependency توی constructor کلاس inject خواهد شد و علاوه بر اینکه اینکار یک سربار اضافه بر روی سرویس های شماست حتی اینکه چرا از اون کلاس inject شده استفاده نمی کنید ولی اونو inject میکنید و یا در فیلد های کلاس شما هست خودش مساله هست که معماری سیستم شمارو زیر سوال میبره.بنابراین راه کار اینه که کلاسیرو inject کنید که حتما از اون توی تمامی سرویس ها استفاده میکنید یا اگر نمی کنید توابع رو در یک سرویس جداگانه بزنید که این عمل هم خودش ممکنه باعث زیاد شدن کلاس های سرویس ها به ازای هر interface ای که inject میکنید بشه.

2.به طور کلی استفاده از عملیات runtime برای instance گرفتن کلاس ها از طریق Activator.CreateInstance و روش های دیگه ی Runtime چندین برابر نسبت به عملیات کامپایل تایم کند هست.یعنی شما اگر به صورت دستی یک کلاس رو new کنید صد ها برابر سریعتر از کلاسی هست که به صورت runtime در حافظه new میشه.در Dependency Injection به طور کاملا صد در صد کلاس های سرویس شما به ازای هر بار صدا زدن توسط Activator در حافظه new میشن و همونجا هم constructor هایی که باید inject بشن هم new یا به صورت cache توی اون کلاس inject میشن نمیتونم بگم این عملیات چقدر کند هست اما وقتی این اتفاق توی بک اند کم کم اتفاق میوفته به قول معروف قطره قطره جمع شود وانگهی دریا شود، سیستم شما رو بشدت کند میکنه و شما کماکان دنبال کدهایی در ساختار خودتون برای بالا بردن پرفورمنس میگردید در حالی که مشکل از جای دیگه آب میخوره.

#CSharp
#Dependency_Injection
@CsharpTips

SignalGo 5.0 Performance vs Asp Net Core 5.0
Without JsonGo and version 6.0

1000 request concurrent

------
SignalGo Self Host Net Core 3.1 Debug:
------
TotalTime: 7591.359 ms
finish Success :1000 Fail :0
Success Min Time: 433 ms
Success Max Time: 7564 ms
______________________________________

------
Asp Core Self Host Net 5.0 Release
------
TotalTime: 15128.056 ms
finish Success :1000 Fail :0
Success Min Time: 1591 ms
Success Max Time: 15094 ms
______________________________________

------
Asp Core Self Host Net 3.1 Release
------
TotalTime: 26935.405 ms
finish Success :1000 Fail :0
Success Min Time: 1698 ms
Success Max Time: 26917 ms
______________________________________

آیا شما از سیگنالگو استفاده می کنید؟ Are you using SignalGo?
anonymous poll

بله Yes – 5
👍👍👍👍👍👍👍 29%

خیر No – 5
👍👍👍👍👍👍👍 29%

در آینده استفاده می کنم I will use in the future – 4
👍👍👍👍👍👍 24%

قبلا استفاده می کردم I already use – 3
👍👍👍👍 18%

👥 17 people voted so far.

یه جوری کد میزنی انگاری که دیرته
نوشتن باگهاتم جزئی از تقدیرته

میون همه ی کدهات کامنت هاتم جا میذاری
رو صندلیت لم و دادی و نسکافه نزدیکته
باگ پیچیده ای، تو آی دی ایت پهن باشه
از پشت میز نگام کنی وقتی کارت لنگ باشه
جای تند تند کد زدن کمی تامل میدونی
مهربون باش فکر نمی کنم کارت سخت باشه

چی میشه باگ هاتو رفع بکنی
همه ی تست هاتو پس بکنی

تقصیر من چیه آرزوش این شده
کارتو تموم کنم بعد خودکشی

تو سال 2017 وقتی بک اند برخی پروژه هامون رو با WCF زدیم و خواستیم کلاینت اندروید هم داشته باشیم، در نتیجه تصمیم گرفتیم کلاینت اندروید رو با جاوا بزنیم و وقتی زدیم متوجه شدیم WCF به صورت Duplex کلاینت های جاوا رو ساپورت نمی کنه، کار سخت شد شروع کردیم تحقیق کردن و مجبور شدیم ابزار رو عوض کنیم در نتیجه SignalR رو انتخاب کردیم، سیگنال آر گزینه خوبی بود و تا جای ممکن کارمون رو راه انداخت اما توی اسکیل های بزرگ تر به مشکلات جبران ناپذیری خوردیم که دیگه برامون پروژه قابل توسعه نبود، پیشنهاد دادم به مدیرمون که میتونیم خودمون ابزاری بسازیم که ارتباط بین کلاینت و سرور رو خودمون مدیریت کنیم، بعد از موافقت مدیریت شروع به ساختن پروژه ی SignalGo کردیم و تا به امروز خیلی پروژه ها رو باهاش توسعه دادیم همه نقطه ضعف ها و مشکلاتی که داشت رو حل و رفع کردیم و همچنان در حال توسعه اون هستیم.
حالا امروز بعد از انتشار دات نت 5 میبینم که WCF دیگه توسعه داده نمیشه و مایکروسافت به طور مستقیم دیگه از اون پشتیبانی نمی کنه.
حالا ابزار های سیگنالگو با بیش از 60 هزار دانلود توی nuget مایکروسافت همچنان با قدرت ادامه میده 👌💪💪
#به_ما_بپیوندید

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

یکی از کارهایی که شما میتونید با سی شارپ انجام بدید تا دسترسی مستقیم به یک مقدار توی حافظه از یک متغیر داشته باشید استفاده از StructLayout هست.
در مثال زیر اگر شما مقدار value رو تغییر بدید مقادیر 4 بایت در حافظه در متغیر های byte0 تا byte3 تغییر میکنن.برای همین شما نیاز به BitConverter ندارید تا یک عدد رو به یک ارایه از بایت ها تبدیل کنید.
یکی از دلایلی که JsonGo از بقیه serializer ها سریعتر عمل میکنه (حتی سریالایرز های unsafe)
مثال:

    [StructLayout(LayoutKind.Explicit)]
    public ref struct IntStruct
    {
        [FieldOffset(0)]
        public byte byte0;
        [FieldOffset(1)]
        public byte byte1;
        [FieldOffset(2)]
        public byte byte2;
        [FieldOffset(3)]
        public byte byte3;

        [FieldOffset(0)]
        public int Value;
    }

@CsharpTips

#سی_شارپ
#تست
#آزمایشگاه

یکی از ابزارهای تست ابزار Mock کردن تست هاست، ابزارهایی توی سی شارپ و زبان های برنامه نویسی وجود دارن که شما میتونید باهاشون مدل های آزمایشگاهی خودتون رو کمی به واقعیت نزدیک کنید و برای پروژه خودتون تست بنویسید.
اما آیا این تست ها 100% واقعی بودن و به واقعیت نزدیک بودن تست شمارو تضمین میکنن؟ خیر، آیا تا بحال بهش فکر کردید؟ چقدر فرق میکنن؟
ببینید توی تست های Mock چند تا اتفاق بد میوفته:
1.شما حتما باید یک فضای اضافی برای Mock کردن کلاس هاتون بسازید، این یعنی اینکه حتما مجبورید برای نوشتن Mock اینترفیس داشته باشید و حتما کلاس های اصلی پروژه تون درگیر داشتن اینترفیس هایی میشن که میتونستن هیچوقت وجود نداشته باشن. یعنی باید برنامه نویسی کنید.
از نظر من تست بالاترین لایه ی سیستم هست، معماری پروژه شما نباید بدونه شما دارید براش تست می نویسید، در نتیجه نباید کدهای لایه ی پایین اپلیکیشن خودتون رو درگیر کد های لایه بالاتر کنید، این یعنی پیچیدگی و پیچیدگی = مرگ
فرض رو بر این بگیرید که اصلا قرار نیست پروژه های سطح پایین درگیر خراب کاری هایی که شما سمت تست می کنید بشن.حالا چیکار میکنید؟
2.فرایندها به طور 100% واقعی تست نمیشن، مثلا وقتی شما یک سرور خارجی رو به صورت Rest صدا میزنید این سرور ممکنه خروجی xml یا json داشته باشه آیا همه ی فرایند های serialize و deserialize و post و get و ارتباط های شبکه ای شما هم با سرور مورد نظر تست میشه؟ Exception های اون سرور چطور؟ هیچ کدوم؟ پس این سرور mock فقط قراره یه سری داده رو بگیره و بفرسته؟ همون ورودی و خروجی های خودمون؟

اگر هنوز فکر میکنید دارم اغراق میکنم سر بزنید به لینک زیر تا ببینید چرا برنامه نویس ها نمیتونن یک کلاس HttpClient رو Mock کنند و دست به دامن تغییرات زیادی توی کدهاشون شدن:
https://stackoverflow.com/questions/36425008/mocking-httpclient-in-unit-tests

حالا اینارو گفتم که بعدش چه چیزی گفته باشم؟
ما توی شرکتمون ابزاری ایجاد کردیم به نام Laboratory و نام مدل های آزمایشگاهی اونو گذاشتیم Mockup کاری که این ابزار میکنه اینه که به صورت 100% فرایند تست Mock شمارو تضمین میکنه و به شکل یک سرور واقعی اما به صورت مجازی موقع تست های شما در پشت صحنه اجرا میشه و تمامی فرایند های پروژه شما از ابتدا تا انتها و حتی بعد از HttpClient ها و ... جایی که حتی Header ها رو میتونید برگردونید جایی که دقیقا یک پورت http گوش بزنگه تا httpClient شما بهش رکوئست بزنه تا به صورت واقعی درخواست های xml یا json یا ... رو به سرویس های شما برگردونه.
حالا دیگه نه نیازی دارید interface های اضافه بسازید، نه نیاز دارید که حتی یک خط اضافه توی لاجیک هاتون به خاطر Mock کردن پروژه بزنید اعم از ساختن interface ها یا حتی تغییرکد ها توی تست کیس ها تنها کاری که میکنید یه سری Resource میسازید تا در فرایند تست سرور به صورت مجازی لود بشه و داده هارو مجازی سازی کنه.

@csharptips

همراه با آهنگ بخونید 😆

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

باگ
تو که معماری رو از قبلش دیدی
بهم میریزی هی مگه مریضی
با این همه باز چه سپیچی

باگ
سوسه ای وسط پیشونی
یه کدی که تا همیشه میمونی
به جون خودت درد بی درمونی

باگ
یه کد کثیف پر طرفداری
حیف تو فقط که مردم آزاری
داری میکنی برده داری

آهای عالیجناب باگ
هیچی نمی کنی لاگ
حریف تو نمیشه
هیچ تستی توی دیباگ

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

.
.
.
.
.
.



باگ
با توام ای کد هرجایی
چیزی نمونده چون آخرایی
بعد فکر میکنی آخر دنیایی

باگ
منه منگ توی گشت شبونه
گاهی حتی با قطر بالاخونه
فکر میکنی خیلی آسونه



آهای عالیجناب باگ
زدم یدونه وبلاگ
بگم خسته شدم باز
شدم از دستت هلاک


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

@CSharpTips

در معماری نرم افزار بخصوص Back-End اونم توی معماری میکروسرویس ها پرفورمنس بسیار مساله مهمی هست، بحث فقط سرعت بازدهی به مشتری نیست، بلکه شامل هزینه هایی که برای شرکت ها در نظر گرفته میشه هم هست، شما با استفاده از یک معماری خوب و ساختار چینی درست و بالا بردن پرفورمنس سیستم میتونید برای شرکتتون هزینه های کمتری برای بروزرسانی، پهنای باند و حتی تعداد سرور ها در نظر بگیرید، فکرشو بکنید یک شرکت بزرگی میشید مثل مایکروسافت و سالانه هزاران یا میلیون ها دلار صرف نگهداری سرور ها میکنید، در حالی که با یک کد خوب میتونید هزاران دلار صرفه جویی کنید چون معمولا توی بالانس کردن سرویس هاتون به کیس های بیشتری نیاز خواهید داشت پس اگر کد بهینه بزنید توی پروژه های بزرگ تعداد کیس ها و سرورها کمتر خواهد شد
@csharptips

چندتا چیز مهم رو هیچوقت یادتون نره:
1.همه چیز توی اینترنت نیست
2.تا جای ممکن وابستگی هاتون رو پایین بیارید
3.از ابزار هایی که سیستم شمارو به سیستم خودشون وابسته و برای تغییر شمارو درگیر هزینه های زیادی میکنن دوری کنید
4.فراموش نکنید شرکت های بزرگ نادان نیستن که بهترین ابزارهاشونو لقمه کنن و بدن شما استفاده کنید قطعا شما ازمایشگاهشون هستید اونا بهترین ایده ها و بهترین کارهاشونو برای خودشون نگه میدارن
5.مطالعه خوبه تا خلاقیت خودتون و راه خودتون رو پیدا کنید، تقلید و استفاده کننده نباشید اینکار بشدت شمارو کند و بعد از مدتی ضعیف و بی اعتبار میکنه
6.به چالش بکشید و دنبال چالش های جدید باشید تا پیشرفت کنید هیچ سیستمی رو بهترین ندونید معماری بی نقض نداریم همه چیزو زیر سوال ببرید و راه کار جدید و بهتر ارائه کنید تا جا برای پیشرفت بذارید به چالش کشیدن با ارائه راهکار بهتر با معنیه وگرنه ارزشی نداره
7.همیشه توی شرکت ها دوتا هدف رو دنبال کنید یکی موفقیت خودتون یکی موفقیت شرکت و همکارانتون اگر دومی رو از دست بدید غمگین نمیشید.
شمام اگر نکته ای دارید اضافه کنید..
@CsharpTips

مقایسه کارکرد فیلد و پراپرتی در کلاسهای سی شارپ

https://youtu.be/BA3mpAyRbCU

سه تا نکته مهم در مورد Field و پروپتری:
1.فیلد ها پروفورمنس بیشتری در حالت اجرای get و set توی کلاس شما دارن، یکی از علت هاش اینه که پروپتری ها خودشون دارای دو متد get و set هستند حتی به صورت پیشفرض get و set خالی هم بذارید پرفورمنس اجرای کد رو پایین میارن.بنابراین یکی از پیشنهادات خودم اینه که موقعی بحث پروفورمنس خیلی مطرح هست حتما از فیلد ها به جای پروپرتی ها استفاده کنید.
2.علت بوجود اومدن پروپرتی ها قابلیت بارگذاری یا override کردن مقادیر get و set در اونهاست، بنابراین توی binding های برنامه نویسی کلاینت توی WPF شما نمیتونید از field ها انتظار داشته باشید در هنگام تغییرات پروپرتی های بایند شده رو براتون بروزرسانی کنن و خیلی مهم هست که حتما اونجا از پروپرتی استفاده بشه.
3.و مساله بعدی Entity framework هست وقتی شما از پروپرتی استفاده میکنید EF میاد و اونارو توی کلاس جدید برای Change Tracker خودش override میکنه برای همین موقعی که شما میخواید یک مدل دیتابیسی رو ویرایش کنید میتونید بدون کد اضافی یک پروپرتی رو توی دیتابیس ویرایش کنید اما اگر از field استفاده میکردید change tracker نمیتونست تشخصی بده شما چه وقتی فیلد یک مدل دیتابیسی رو تغییر دادید.علتش اینه که توی سی شارپ از طریق Emit و Reflection ها توانایی ساخت یک متد برای فیلد ها وجود نداره و فیلد ها مستقیما اشاره به مقدار یک متغیر توی حافظه میکنن نه مقدار یک متد توی حافظه برای همین قابلیت این رو ندارن که شما اونارو توی حافظه مجدد بسازید یا تغییرشون بدید.

@CSharpTips

پروژه اپن سورس BinaryGo Preview 8 ریلیز شد.
این پروژه توی سریالازر باینری نزدیک به دوبرابر سرعت بیشتری نسبت به سریالایزر grpc protobuf داره.
علاوه بر این، مزیت بزرگ دیگه ای که این ابزار نسبت به ابزار های مشابه مثل grpc داره اینه که شما لازم نیست بالای کلاس ها و پروپرتی هاتون Attribute بذارید یا فایل های proto بسازید. یعنی کد هاتون کلین و بدون Dependency به پکیج باقی میمونن.
سورس پکیج:
https://github.com/Ali-YousefiTelori/BinaryGo

نصب پکیج:
https://www.nuget.org/packages/BinaryGo

@CSharpTips

یکی از مشکلاتی که شما ممکنه توی استفاده از GRPC یا MessagePack یا ZeroBuffer بخورید مبحث backward-compatibility هست.

فرض کنید شما میخواهید مدل های سرویستون رو بروزرسانی کنید، چندتا رو حذف کنید و یکم اونارو مرتب کنید، خوب برای مرتب کردن سعی میکنید ایندکس ProtoMember رو تغییر ندید، ولی مطمئنا برای حذف کردن نمیتونید به این راحتی تصمیم بگیرید، برای همین توصیه ای که شده اینه که اونارو منقضی کنید و دست بهشون نزنید و کم کم یه برنامه زمانی براش بذارید تا اونارو به طور کامل حذف کنید.
چه اتفاقی میوفته این وسط:
1.کدهاتون شلخته و کثیف میشه، یعنی چیزهای اضافه ای دارید که دوست دارید حذف کنید ولی نمیتونید به این سادگی اینکار رو انجام بدید
2.معماری ای که میخواستید بچینید و مرتب باشه کم کم توی ده ها میکروسرویس داره توسط صد ها اتریبیوت ProtoMember فقط برای یکم پرفورمنس بهم میریزه و فردا که خواستید تغییرش بدید باید کلی چیز اضافه از توی مدل هاتون پاک کنید. یعنی وابستگی
این مورد رو برای تغییر انواع هم خواهید داشت مثلا اگر یک نوع int رو به string یا بالعکس تغییر بدید سیستم شما با خطا مواجه میشه.

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

ما توی BinaryGo این معضل بزرگ رو حل کردیم، علاوه بر اینکه شما اتریبیوت و وابستگی ندارید حتی ساختاری به نام StructureChanged برای breacking changes و backward-compatibility بوجود اوردیم که هیچ مشکلی برای تغییر مدل ها بوجود نمیاره 😊
@CSharpTips

جدیدترین پکیجی که شروع کردم به نوشتن 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