از سری مطالب معماری نرم افزار #1
بررسی اجمالی اصول طراحی و چرخه تولید نرم افزار ها

اگر هنرجو یا دانشجوی رشته مهندسی نرم افزار بوده باشید، حتما با رویکرد هایی که در آموزش برنامه نویسی و طراحی نرم افزار استفاده میشه آشنا هستین. اکثر شیوه های آموزشی در دانشگاه ها و آکادمی ها بیشتر جنبه آشنایی و تئوری دارن.
در فاز عملی، نحوه کدنویسی و مبانی پایه هر زبان آموزش داده میشه. مثلا الگوریتم، قواعد زبان c,c++ یا اخیرا c#، ساختمان داده و ازین دست مقوله ها. اگر کمی علمی تر باشه، شاید جنبه های چرخه تولید و نگهداری نرم افزار ها و رویکرد های تخصصی رو هم تا حدی بهش بپردازن. (اما چیزی که ما اکثرا دیدیم فقط یکسری کد و برنامه فاکتوریل و فیبوناچی و ستاره چاپ کن ... بوده)
در درجه اول این شما هستین که باید پیگیر موضوعات مختلف در علوم مهندسی نرم افزار باشین. پروتکل ها، پلتفرم ها، اصول و قواعد زبان های برنامه نویسی، همه در سطوح تئوری و تا حدودی عملی به شما معرفی میشن اما خیلی کمیاب و بعیده که به درون این مباحث هم بپردازن. (به قول استادی ما فقط استارت رو میزنیم، دیگه تهش یکم هل ات میدیم)
تایید حرف من رو میتونین در بین خیلی از دانشجوهای این رشته ببینید. حتی در بین برنامه نویس ها و تحصیل کرده های بازار کار این حوزه، هنوز عده کثیری درک درستی از ساختمان داده، الگوهای طراحی، اصول شئ گرایی و نرم افزار، به درستی ندارند. ضعف سیستم آموزشی ما بر هیچ کس پوشیده نیست، اما ضعف خود ما چی؟ چند درصد دانشجو ها و مهندس ها واقعا به دنبال یادگیری بیشتر و کسب تجربه میرن؟ (مطمئنم دلیل اینکه هی میگفتن رشته کامپیوتر اشباع شده رو الان بهتر درک میکنین، از جک هایی که راجع بهمون میگن که دیگه نگم براتون :D )

یکی از صدها موضوع فوق العاده مهم در علم مهندسی نرم افزار، معماری نرم افزار هست. به رشته های مکانیک، ساختمان و معماری نگاه کنید. صرفا داشتن ابزار و اطلاعات کمک کننده نیست. قبل از ساخت یک ساختمان، ابتدا نقشه منطقه و ساختمان، زیر ساخت ها، امکانات و نیازمندی ها و ... آماده میشه و بعد شروع به ساخت و ساز میکنن. مطمئنا اگر وسط ساخت و ساز به فکر تغییر ابعاد خانه یا رفع ناهماهنگی بین سازه ها و اجزای ساختمان باشین، تمام وقت و سرمایه خودتون و دیگران رو هدر خواهید داد و چه بسا خشت اول رو که کج بزارین، تا آخر کج خواهید رفت!
پس قبل از پلن پیاده سازی، باید بدونید چی نیاز دارین و چطور میخواین انجامش بدین، کدنویسی یک مهارته، فراتر از اون معماری و معماری طراحی هست (منظور دیزاین نیست) . به همین خاطر شما میتونید تنها یک معمار نرم افزار باشید چون خودش تخصص جداگانه ای هست که راحت کسب نمیشه. میتونید فقط یک کدنویس باشید که طبق معماری و خواسته های طراح و مدیر پروژه با سابقه ای پیاده سازی کنید.
طراحی نرم افزار مباحث زیادی داره که من فعلا موضوع معماری های نرم افزار رو مدنظر گرفتم.
*نکته مهم*
مباحث معماری نرم افزار، الگوی معماری نرم افزار و الگوی طراحی نرم افزار، سه مبحث کاملا متفاوت و بنیادی در مهندسی نرم افزار و برنامه نویسی است. گاها این سه مقوله یکسان در نظر گرفته میشن یا با هم اشتباه گرفته میشن. (خیلی جاها هم اصلا مفهوم معماری دیده نمیشه و فقط کدهای متعدد و لایه بندی های زیاد میبینیم بعد میگن معماریمون n-layer یا DDD عه! )
معماری و الگوهای استفاده شده در نرم افزار، پیاده سازی، آینده توسعه و نگهداری و استفاده از نرم افزار رو رقم میزنه. اینکه یک سامانه متشکل از صدها سرویس و هزاران کاربر چطور طراحی و پیاده سازی بشه تاثیر مستقیم در موفقیت تیم شما و محصول شما داره. معماری و تحلیل تکنیکال مناسب، تاثیر زیادی در صرفه جویی هزینه ها و زمان شما و تیم تون داره. همچنین میتونه تضمین کنه که تغییرات و اتفاقات آینده، با مناسب ترین هزینه و زمان به شیوه مشخص و بهینه ای قادر به انجام خواهند بود.
در مطلب بعدی درباره هر سه موضوع نام برده، توضیح میدم.
@csharpfriends #SoftwareEngineering #SoftwareArchitecture #SoftwareLifeCycle

از سری مطالب معماری و مهندسی نرم افزار #2

مفاهیمی در معماری نرم افزار خیلی وقت ها کج فهمیده میشه و در این مطلب سعی میکنم این موضوع رو کمی تشریح کنم.
1. معماری نرم افزار (Software Architecture):
معماری نرم افزار به موضوع شناخت و ترسیم کلیت نرم افزار و شکستن کل به بخش های مختلف، رفتارها و ارتباطاتش با دیگر اجزا مانند سرویس ها و برنامه های خارجی، دیتابیس، سرور ها و زیر ساخت ها می پردازد.
همچنین دید کلی از سامانه های نرم افزاری، شبکه ارتباطات داخلی و خارجی(external)، نگهداری و توسعه نرم افزار ها که ارتباط تنگاتنگی با معماری استفاده شده در نرم افزار ها دارد. به طور ساده تر و خلاصه تعریف معماری نرم افزار رو میتونیم به شکل: نقشه ای برای مدیریت پیچیدگی ها/نیازمندی های سیستم و ایجاد ارتباط و هماهنگی بین بخش های مختلف بیان کرد.

از معروف ترین معماری های نرم افزار، میتوان موارد زیر را نام برد:
معماری یکپارچه یا Monolithic
معماری سرویس گرا/مبتتنی بر سرویس یا SOA
معماری میکروسرویس یا Microservice

2. الگوی معماری نرم افزار (Software Architecture Pattern):
الگوهای معماری نرم افزار، جهت جداسازی منطق و ساختار لایه های مختلف، قابلیت استفاده مجدد و توسعه آنها استفاده میشوند. تعیین پروتکل های ارتباطی و منطق لایه های مختلف مانند لایه Presentation، دیتابیس و دسترسی به داده، سرویس ها و ... از خواص الگوی معماری انتخاب شده ارث میبرند. در واقع آنها روش هایی برای کمک به مشکلات و نیاز های مربوط به طراحی نرم افزار ارائه میدهند.
خیلی ها معماری و الگوی معماری نرم افزار را یکسان تلقی میکنن. در آموزش ها، مقالات و وبسایت ها اغلب یا به اشتباه توضیح داده میشن یا به یکسان. شیوه و روش طراحی نرم افزار، با معماری کل نرم افزار تفاوت دارد. به نما و کلیت معماری ساختمان، ساختار و سازه های داخلی و نحوه ارتباط اجزا مختلف و استفاده اونها فکر کنید. به سیم کشی ها و پیچیدگی های مخفی شده در بین سازه ها و ارتباط دیوارها و ستون ها، نحوه باز شدن درب و پنجره و .. اینها یکسان هستند؟!

برخی از پرکاربرد ترین الگوهای معماری نرم افزار(Architectural Patterns) :
- الگوی سه لایه و چند لایه 3Layer & N-Layer و n-Tire
- الگوی MVC (Model View Controller)
- الگوی MVP (Model View Presenter)
- الگوی MVVM (Model View Viewmodel)

رویکرد طراحی دامنه محور یا Domain Driven Design، به اختصار DDD ( اینجا اوردم چون خیلی با معماری و الگو اشتباه میگیرن)

3. الگوی طراحی نرم افزار (Software Design Pattern):
الگوهای طراحی (Design Patterns)، به شیوه و راه حل های مشکلات رایج در طراحی نرم افزار میپردازند. به عبارت دیگر مجموعه ‌‌ای از بهترین راه‌ حل‌های مشکلات متداول در فرآیند برنامه نویسی نرم ‌افزار را الگوهای طراحی می‌نامند.
الگوهای طراحی جزو معماری‌های نرم افزاری نیستند و فقط شیوه ای صحیح از کدنویسی را ارائه می‌دهند. بنابراین این الگوها فقط در قلمرو کدنویسی ( مخصوصا شی گرا) وارد می‌شوند و مستقل از زبان‌های برنامه نویسی هستند. ( در رابطه با تاریخچه و گروه Gang Of Four معروف به GOF، طبقه بندی کننده و نویسنده اولین کتاب الگوهای طراحی، مطلب جداگانه ای مینویسم)
**هر دیزاین پترن برای اهداف مشخصی ایجاد شده که به برخی از کاربردی ترین ها اشاره میکنم:
1. الگوهای طراحی سازنده(Creational)، به حل مشکلات مربوط به ایجاد اشیا در نرم افزار اشاره میکنند؛ مانند:
- الگوهای سازنده یا Builder، کارخانه یا Factory، یکتا/یگانه یا Singleton،
تزریق وابستگی یا Dependency Injection
2. دسته دیگر معروف به الگوهای طراحی ساختاری(Structural)، به مدیریت ارتباط میان کلاس‌ها و شی‌ها با یکدیگر پرداخته مانند:
- الگوهای فساد یا Facade، مخزن یا Repository، تزئین کننده یا Decorator، آداپتور یا Adapter، پُل یا Bridge، پراکسی یا Proxy
3. دسته دیگری معروف به الگوهای طراحی رفتاری(Behavioral)، به راهکارهای کدنویسی مربوط به تعامل و ارتباط اشیا با یکدیگر میپردازند؛ مانند:
- الگوهای دستور یا Command، واحد کار یا UnitOfWork، واسطه گر یا Mediator، توکن یا Memento

* الگوهای طراحی مزایایی همچون افزایش سرعت توسعه، انعطاف و توسعه پذیری، کاهش خطاها، مشکلات و میزان کدنویسی نرم افزار را به همراه دارند. ( البته کد کمتر همیشه درست یا خوب نیست، کد بیشتر هم همینطور، کد تمیز و ساختار مند انعطاف، مطالعه و توسعه پذیری توسط دیگران رو هم بالا میبره)
در عین حال استفاده نادرست و غلط از آنها نتیجه عکس خواهد داد و میتواند سربار و مشکلات دیگری اضافه کند؛ مانند استفاده های نادرست از الگوهای طراحی ریپازیتوری، تزریق وابستگی و ioc
در ادامه به ترتیب به تشریح 3 مفهوم فوق میپردازم.
@csharpfriends
#SoftwareArchitecture #SoftwareArchitecturePattern #SoftwareDesignPattern

گروه تبادل نظر و پرسش و پاسخ کانال: https://news.1rj.ru/str/csharpfriendsgroup
هر گونه انتقاد، پیشنهاد، مطلب و صحبتی داشتید میتونید با من و بقیه به اشتراک بگذارید، با نام خودتون، ناشناس یا هر شکل دیگه ای. هیچ چیز شخصی نیست و هدف، یادگیری و اشتراک دانش هست. انشالله تحت یک پلتفرم آنلاین در آینده.
اگر دوست داشتید به دیگران هم معرفی کنید.
@csharpfriends

از سری مطالب معماری های نرم افزار #3
در مطلب قبل در رابطه با 3 مفهوم معماری، الگوی معماری و الگوی طراحی در معماری نرم افزار توضیح داده شد. حال به چند نمونه معروف و رایج معماری های نرم افزار (Software Architecture) میپردازیم.

1.1 معماری یکپارچه (Monolithic)
در این معماری همه چیز در یک دید کلی ترسیم و پیاده سازی شده است. یک نرم افزار میتواند شامل ده ها و صد ها بخش (قابلیت/سرویس) باشد؛ که همگی در کنار هم و در یک نرم افزار واحد جای داده شده اند. نرم افزارهای مدیریت محتوا، CRM برخی از مثال های نرم افزار های تجاری یکپارچه اند. این نرم افزار ها قابلیت ها و کارهای زیادی را به صورت واحد انجام میدهند. مثلا ثبت نام و مدیریت کاربران، مدیریت محتوا و دیتابیس، سرویس های ارتباط با مشتریان و پشتیبانی و ...
اینگونه نرم افزار ها معمولا شامل چند بخش میشوند، بانک اطلاعاتی، رابط کاربری و بخش سمت سرور که مدیریت درخواست ها را انجام میدهد و واسطه پردازش داده های بانک اطلاعاتی با رابط کاربری میباشد.

این معماری قدمت زیادی دارد، اگر تجربه کار با سامانه ها و نرم افزار های قدیمی 10 سال پیش رو داشته باشید، بخوبی ساختار و مشکلات نگهداری و توسعه آنها را درک میکنید. هنوز هم بسیاری از سامانه ها و نرم افزار های دولتی و خصوصی بر پایه این معماری و فریم ورک های قدیمی است. دلایل عدم توانایی در ارتقا و توسعه آنها هم کاملا مشخص است. برخی از مزایا و معایب این معماری در زیر آورده شده:
+ مزایا (بیشتر مزایا برای نرم افزار هایی در مقیاس کوچک تا متوسط صادق است) :
* سهولت توسعه و نگهداری در ابتدای کار
* هزینه کم راه اندازی و نگهداری
* دغدغه های کمتر درباره امنیت و محافظت از نرم افزار، به دلیل یکپارچه بودن همه عملیات ها و نظارت بر آنها.
* پرفوورمنس و کارایی بهتر، به دلیل سرعت بالاتر دسترسی به حافظه اشتراکی، نسبت به سرعت پردازش و ارتباطات از طریق شبکه و کانال ها در معماری هایی مثل میکروسرویس.
- معایب:
* مقیاس پذیری و ارتقا: یکی از دشوارترین کارها در این نوع معماری است؛ زیرا همه اجزاء به صورت یک واحد یکتا در کنار هم چیده شده اند و نمیتوان فقط بخش ها و سرویس های خاصی را بیشتر کرد یا ارتقا داد.
* پیچیدگی و عدم انعطاف تکنولوژی ها، توسعه پذیری کم: هر تکنولوژی و کتابخانه ای که در طول توسعه نرم افزار استفاده شده شامل وابستگی ها و بخش های مختلفی هست که توسعه پذیری و انعطاف رو در برابر حذف یا تغییر دادن اونها به شدت کم میکنه. نتیجتا ساختار ها، فریم ورک ها و کتابخانه های استفاده شده در این نرم افزار، به اجبار باید در طول توسعه رعایت شوند؛ درغیر اینصورت کل نرم افزار باید زیر و رو شود (مثلا برای زبان برنامه نویسی یا یک کتابخانه مثل Entity freamework).
* استقرار، عیب یابی و بروزرسانی: در صورتی که بخشی از نرم افزار آپدیت شود و یا به مشکلی در راه اندازی بخورد، کل نرم افزار باید دوباره بروزرسانی و راه اندازی شود.
* پایداری کم، تفکیک پذیری پایین: در صورتی که بخشی از نرم افزار مثلا یک سرویس، منجر به بروز خطا ای در سیستم یا اختلالی در عملکرد نرم افزار شود، ممکن است کل نرم افزار را با مشکل مواجه کند و از کار بیندازد. همچنین پایین بودن امکان تفکیک سطوح مختلف، یا فرضا ماژولی به حافظه بیشتری نیاز داشته باشد و دیگری به پردازنده قوی تری.
* درک سخت تر، به دلیل پیچیدگی و اتصالات سفت بخش های مختلف برنامه در طول روند بزرگ و بزرگ تر شدن آن، به سختی میتوان عملکردی در نرم افزار را پیدا کرد و تغییر داد. علاوه بر آن مطالعه و تحلیل همه کدها به شدت زمان بر خواهد شد.
@csharpfriends
#SoftwareArchitecture #Monolithic

از سری مطالب معماری نرم افزار #4

1.2 معماری سرویس گرا (SOA)
به طور معمول با استفاده از معماری سرویس گرا و یا SOA، یک سیستم نرم افزاری به عنوان ترکیبی از سرویس‌های مختلف، طراحی و ایجاد می شود. مثلا سرویس های پرداخت، محصولات فروشگاه، گزارشگیری،احراز هویت. (نرم افزار به عنوان سرویس)
مشابه معماری یکپارچه، این سرویس ها که همگی جهت پاسخ به نیازها و معمولا در قالب یک نرم افزار طراحی شده اند، به صورت وب سرویس های جداگانه ارائه میشوند. اما از نظر ساختاری همچنان شباهت زیادی به معماری یکپارچه دارند. از اهداف اصلی SOA استفاده مجدد از عملکردهای سیستم و اشتراک گذاری اجزای آن است (برخلاف میکروسرویس ها که مستقل اند و اشتراک گذاری رو به حداقل میرسونن و بیشتر مفهوم bounded-context رو ارائه میدن).
پروتکل اصلی ارتباطی اینگونه نرم افزار ها Soap است. حتما با وب سرویس های قدیمی مثل asmx و wcf ها در دات نت سر و کار داشتید.
محاسبات سرویس گرا (SOC) ، نمونه ای از محاسبات است که در آن طراحی و توسعه سیستم های کاربردی بر پايه سرویس به عنوان عنصر اساسی ، انجام می گیرد. سرویس ها عناصری هستند که مستقل از پلتفرم بوده و در ساخت سیستمهای توزیع شده سریع و ارزان قیمت کمک می نمایند. همچنین سازمانها را قادر می- سازند تا توابع خود را از طریق زبانها و پروتکلهای بر پایه XML پیاده سازی و بر روی اینترنت یا اینترانت ارائه نمایند.
پروتکل های انتقال پیام متعددی میان سرویس ها استفاده میشود( در مطلب دیگری پروتکل ها رو توضیح میدم) که هر کدام شیوه پیاده سازی متفاوتی ارائه میکنند، برخلاف میکروسرویس ها که معمولا بر بستر استاندارد http rest ارتباط دارند و هرگونه کلاینت ای میتواند با آنها بدون وابستگی ارتباط برقرار کند.
در این معماری عملکرد و سرویس ها به 4 دسته تقسیم میشن:
* سرویس های تجاری: شامل سرویس های اصلی که توسط XML نمایش داده میشن.
* سرویس های سازمانی: برای برآورده کردن و پیاده سازی عملکردهایی که در لایه تجاری مورد نیاز هست، به عنوان واسط سرویس های زیر بنایی و برنامه عمل میکنن.
* سرویس های برنامه کاربردی: لایه ای که هر کدام از برنامه های کاربردی (سرویس ها) در آن توسعه داده میشود و توسط رابط کاربری و UI از اونها استفاده میشه.
* سرویس های زیربنایی: عملکرد های عمومی مشترک برنامه که میتونن از طریق بقیه برنامه ها و سرویس ها هم فراخوانی بشن؛ مانند مدیریت و احراز هویت کاربران.

+ مزایا:
* قابلیت تغییر و تحویل سریعتر، به شما اجازه میدهد عملکرد سرویس ها را تغییر داده و سریعتر آنها را به مصرف کننده برسانید.
* افزایش تعامل و امکان استفاده مجدد بیشتر، در سطوح مختلف مانند سرویس ها و داده ها
* تکامل و توسعه تدریجی، امکان افزودن قابلیت ها و بخش های مختلف را در قالب سرویس های جدید آسان تر میکند. بدین صورت دیگر مجبور به طراحی و استقرار کل نرم افزار بصورت یکجا و کلی نیستید.
* انعطاف پذیری بیشتر نسبت به معماری یکپارچه، امری است که باعث میشود سرویس ها چه داخل سازمان ها و چه خارج از آنها، منعطف تر و تغییر پذیر تر باشند.
- معایب:
* مشابه معماری یکپارچه، معمولا اکثر قابلیت ها و سرویس های نرم افزار در یک پروژه و تحت یک نرم افزار واحد به صورت وب سرویس نوشته میشوند که وب سرویس ها و لایه های کاربردی و عملیاتی آنها مشابه Monolithic است.
* زبان ارتباطی xml
* ارتباطات مستقیم وب سرویس ها و پروتکل ارتباطی میان آنها
* پرفورمنس کمتر بدلیل مشکلات مربوط به تاخیر و اختلال در ارتباطات بین سرویس ها، به دلیل ماهیت شبکه و بسترهای ارتباطی که در معماری های مبتنی بر سرویس رایج هستند

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

@csharpfriends
#SoftwareEngineering #SoftwareArchitecture #SOA

از سری مطالب معماری نرم افزار #5

1.3 مقدمه ای بر معماری میکروسرویس (Microservice)
رشد و تکامل در هر چیزی قابل مشاهده و اندازه گیری هست؛ تکامل گونه های جانوران، طبیعت، نسل های مختلف، علم و خیلی چیزهای دیگه پروسه های طولانی و زیادی رو طی کردن تا به شکل امروزی در اومدن و همچنان تا وقتی دنیا دنیاست، هر چیزی یا محکوم به فناست یا تکامل. فلسفیش نمیکنم، مقصودم بیان چرخه تغییر و ایجاد چیزهای مختلف در طول زمانه.
روزگاری در دنیای برنامه نویسی و نرم افزار، معماری های مختلفی معرفی و ابداع میشدن. یک روز معماری P2P، روز دیگری Master Slave، کلاینت-سرور، Mainframe و الی ماشالله، که در دهه های 1960-1970 و تا مدت ها بعد رشد و استفاده زیادی داشتند. نیازمندی ها روز به روز بیشتر و پیچیده تر میشن، برنامه ها بزرگ تر و توسعه و نگهداریشون هم به مراتب سخت تر و هزینه برتر.
حتی تا دهه اخیر، معماری سرویس گرا (SOA) با کلی ویژگی و برتری جزو پرکاربرد ترین معماری در طراحی نرم افزار ها و سامانه ها بود. با توجه به حجم بسیار زیادی از چیزهایی که دهه های پیشین در موردش گفته میشد و یک جورایی سوپرمنی آمده بود تا بسیاری از نیازمندی های سازمان ها و نرم افزار های Enterprise رو حل کنه. انصافا هم در دوره خودش بسیاری کاربرد ها داشت و داره.
امکان ایجاد ارتباط های مستقیم میان نرم افزار ها و اجزای مختلف سازمان و اشتراک گذاری داده میان آنها، از برجسته ترین نقطه قوت SOA هست. اکثر سامانه های دولتی و تجاری عمومی و خصوصی سازمان ها به شیوه سرویس گرا طراحی شدند. سامانه های وزارت دارائی، صنعت و معدن، استانداری ها و تعداد کثیری سرویس که من دیدم و در توسعه برخی از اونها نقش داشتم، هنوز هم بر پایه معماری SOA هستند.
با تکنولوژی وب سرویس های asmx و wcf دات نت و بعد ها web api و REST
فرآیندی که شما درخواست میکنید از طریق وب سرویس های مختلف پردازش و منتقل میشن. از سامانه ای به سامانه دیگر، از وزارت بهداشت به ثبت احوال و به دارائی و ورزش؛ نه فقط در کشور ایران، در بسیاری از کشور های جهان امثال بانک ها هم به همین صورت اند. خیلی هاشون انقدر در هم تنیده و بزرگ شدن که روزانه اخبار هک شدن و درز اطلاعات یا از کار افتادنشون رو میشنویم (در کشور عزیز ما البته همه دیتاهامون کف اینترنت ریخته، به لطف دوستان و اربابان)

در ادامه به شرح علل به وجود اومدن میکروسرویس ها و دلایل استفاده از اونها میپردازم
@csharpfriends
#SoftwareEngineering #SoftwareArchitecture #Microservice

چگونه تصمیم گرفتم از Blazor استفاده کنم:

مدتی هست که در حال نوشتن یک سیستم مدیریت محتوا و وبلاگ بر پایه معماری میکروسرویس هستم که دربارش توضیح مفصلی در مطلب دیگه ای خواهم داد.
رابط کاربری و سمت فرانت اند رو اول با Angular شروع کردم به پیاده سازی. متای سرویس ها و مدل های سمت سرور به صورت خودکار توسط nswag تولید میشه برای کلاینت آنگولار. nswag کتابخانه ای برای تولید کدهای سمت سرور شما برای کلاینت ها با زبان های مختلفی مثل typenoscript, c#, js و ... استفاده میشه.
فقط نیاز هست تا ماژول ها، کامپوننت های مورد نظر و فراخوانی سرویس ها نوشته بشه که در کلاینت generate شده. برای من بخش سخت و طاقت فرسای کار طراحی رابط کاربری و سر و کله زدن با پکیج های node بود. علاوه بر اون syntax تایپ اسکریپت (که باز نسبت به js خیلی بهتره) یه سری قواعد متفاوتی داره. در عین حال فریم ورک خوبیه هم از لحاظ سرعت و هم ابزارها و امکانات زیادی که براش تولید شده. امکان PWA کردن اپ هم به راحتی هست.
اما همونطور که گفتم چند چیز اذیتم میکرد، اول پکیج های بسیار زیاد npm و مدیریت ورژن ها و آپدیت هاشون که کلی side effect و باگ ممکنه ایجاد بکنن در برنامه. دوم با syntax اش خیلی راحت نبودم و کلی باید میگشتم تا مثلا بفهمم داده های دریافتی رو چطوری Map میکنن و کلی تابع و چیز مختلف که داره.
این مشکلات برای امثال من بیشتر پر رنگ هست که فرانت کار حرفه ای نیستن یا با این فریم ورک ها زیاد کار نکردن. برای کسی که کلی وقت گذاشته و پروژه زده مسلما راحت تره کما اینکه میشنوم خیلیاشون به مشکلات آنگولار واقف ان.
در درجه بعد نمیخواستم mvc بزنم فرانت رو چون SPA میخواستم.
تا چند وقت پیش که با یکی از دوستان بحث Blazor و وب اسمبلی شد. از نحوه کارکردش تا مقایسه اش با مابقی فریم ورک ها. مهمتر از همه بحث وب اسمبلی.
بعد از اون مشتاق شدم درباره Blazor در دات نت 5، یه تحقیق مجدد بکنم. دیدم نسبت به ۲ سال پیش خیلی بهتر شده هر چند هنوز جای کار داره اما سریع باهاش ارتباط گرفتم. وب اسمبلی و در کنارش طراحی رابط کاربری با سی شارپ و قابلیت هاش برام جذاب بود. کما اینکه افرادی مثل من که به سی شارپ و net core تسلط بیشتری دارن تا جاوا اسکریپت و تایپ اسکریپت، به راحتی میتونن باهاش فرانت اند رو هم پیاده بکنن و چندین ماه درگیر یادگیری فریم ورک های دیگه و سر و کله زدن باهاشون نشن.
به خصوص که من نیاز دارم تا برای پروژم فرانت هم طبق نیازهای خودم پیاده سازی کنم.
در ادامه درمورد وب اسمبلی و فریم ورک Blazor.net یه توضیحی میدم و نمونه پروژه ای که باهاش پیاده کردم رو در گیتهاب قرار میدم تا بقیه علاقه مندان هم بتونن باهاش آشنا بشن.
@csharpfriends #Blazor #WebAssembly #FrontEnd

اگر اهل موسیقی مخصوصا موزیکای خاص موقع کار کردن هستین میتونین اینجا دانلود کنین و یا با بقیه به اشتراک بزارین.
📣 channel : @PG_sound
group:
https://news.1rj.ru/str/ProgrammingSound

توضیحی درباره فریم ورک Blazor و برنامه های وب اسمبلی blazor و blazor server side

فریم ورک blazor دات نت، دو مدل داره، مدل اول با asp.net core کار میکنه و مثل برنامه های Asp core همون قابلیت ها رو به شما میده، بجای mvc شما از razor پیج ها استفاده میکنین و میتونین سرور و کلاینت رو در یک پروژه پیاده سازی کنین. تو این حالت صفحات از سرور به کلاینت ارسال میشن و توسط وب سرور داخلی asp core یعنی kestrel هاست میشن. تو این مدل شما خروجی وب اسمبلی ندارین.
مدل دوم که خروجیش وب اسمبلی هست مستقل از فریم ورک دات نت، روی مرورگر کاربر دانلود و اجرا میشه. امکاناتش نسب به مدل blazor server کمتره و معمولا فقط کدهای سمت کاربر رو داره و از طریق http میتونه با api های شما ارتباط برقرار کنه. تو این مدل که بیشتر شبیه برنامه های PWA هست همه چیز در قالب وب اسمبلی در مرورگر کاربر دانلود و پردازش میشه. بر خلاف مدل server که نیازمند سروری برای اجرا و پردازش درخواست هاست.
برای همین فقط باید کدهای سمت فرانت و ارتباط با سرویس هاتون رو توش بنویسین و از نوشتن منطق و ارتباط با دیتابیس و چیزهای حساس باید خودداری بکنین. به این دلیل که روش کنترلی نخواهید داشت و توسط کلاینت قابل مشاهده و کشف هست.
همچنین خروجی های وب اسمبلی به دلیل مستقل بودن میتونن هر جایی اجرا بشن. به این صورت شما نیازی به host یا سرور مجازی برای پروژه کلاینت تون ندارین و میتونین اون رو مانند کتابخانه ها و فایل ها، در CDN ها، صفحه های Github یا هر مکان دیگه ای برای دانلودش قرار بدین. برخلاف مدل سرور که نیاز به وب سرور و .net host داره.
مفاهیم Blazor تقریبا همانند فریم ورک های دیگه SPA است، مانند آنگولار و React.js.
امکان ساختن Component ها، service ها، استفاده از پکیج ها مثل بوت استرپ، material و هر کتابخانه جاوا اسکریپتی و یا nugget پکیج های دات نت دیگه ای.
همچنین علاوه بر این که میتونین از قابلیت های زبان c# در طراحی صفحاتتون استفاده کنین، امکان استفاده از جاوا اسکریپت هم دارید و دستتون بازه.
وب اسمبلی استاندارد جدیدی در دنیای وب هست و رفته رفته برای زبان های مختلفی مثل سی شارپ، داره براش کامپایلر نوشته میشه. این کامپایلر وظیفه تبدیل کدهای زبان مبدا به استاندارد های وب اسمبلی رو داره که توسط اکثر مرورگر های نسل جدید قابل فهم و اجراست. به این ترتیب دگرگونی بزرگی در دنیای وب ایجاد میشه. چرا که با هر زبانی که براش کامپایلر وب اسمبلی نوشته شده باشه، میتونید رابط کاربری و برنامه های وب و موبایل خودتون رو با کمترین وابستگی به جاوا اسکریپت تولید کنید.
در ادامه یک پروژه نمونه توسط Blazor client(وب اسمبلی) نوشتم که در گیتهاب قرار دادم. در پست بعدی به توضیح این مثال میپردازم.
https://github.com/mrgrayhat/BlazorMicroBlog/blob/master/Documents/screenshot/Index_FullPageScreenshot.png?raw=true

Project Repository:
https://github.com/mrgrayhat/BlazorMicroBlog

نمونه پروژه آموزشی blazor web assembly
Blazor MicroBlog:
همونطور که در مطلب قبلی گفتم، فریم ورک Blazor دات نت به شما امکان طراحی رابط کاربری و وب اپلیکیشن ها رو با کمترین میزان نیاز به جاوا اسکریپت و پکیج های شخص ثالث میده.
تصمیم گرفتم یک اپ PWA بلاگ، با blazor و مدل web assembly بنویسم.
این پروژه به ۳ قسمت تقسیم شده:
1. پروژه سرور که یک سرویس rest api نوشته شده با Asp.net core هست و امکان انجام عملیات CRUD یک وبلاگ رو داره و از efcore و دیتابیس sqlite استفاده میکنه.
همچنین قادر به هاست پروژه کلاینت در خودش هست و فقط کافیه exe یا dll این api رو اجرا کنید. خودش اپ blazor wasm رو پراکسی و برای کلاینت ها ارسال میکنه. (Blazor Asp.net Core Hosted)
همچنین قابلیت برگردوندن خروجی های paged و پاسخ های یکدست به صورت json و پشتیبانی از swagger و documentation داره که کار تست و تولید کد کلاینت هارو ساده میکنه.
2. پروژه کلاینت که تحت Blazor web assembly هست و شامل رابط کاربری برای نمایش و مدیریت وبلاگه. تا حد امکان سعی شده بی نیاز به js باشه و از قابلیت های c# و Razor components بهره گرفته بشه. همچنین بخش های مختلف صفحه، در قالب کامپوننت های مجزا طراحی شده، مانند قابلیت صفحه بندی (Pagination)، Card های بوت استرپ برای پست ها و نمایش لیست پست ها، ارسال toast نوتیفیکیشن، تغییر Theme به دو حالت Dark&Light.
این اپ pwa هست و با اولین اجرا از طریق مرورگر، میتونین روی موبایل و سیستم install کنین.(edge|chrome)
بیشتر جنبه آموزشی و تست پرفورمنس مدنظر بوده که راضی بودم، همه امکانات کامل نیست و به مرور تکمیل خواهد شد.
توضیحات بیشتر در readme ریپازیتوری گیت هاب من موجود است.
اگر پسندیدید به ریپازیتوری star و نظر بدین.
برای کامپایل و اجرا به Net5 Sdk. نیازمندید.
مخزن پروژه:
https://github.com/mrgrayhat/BlazorMicroBlog
(Thanks for you'r opinions and stars, share what you think with me And participate).

*یک نکته درباره فریم ورک Blazor و مدل کلاینت یا همون WebAssembly

همینطور که در مطالب قبلی گفته شد، blazor دات نت، دو مدل ServerApp و WebAssembly داره.
نمونه پروژه ای که در مطلب پیشین معرفی کردم با مدل وب اسمبلی blazor نوشته شده. وقتی یک پروژه blazor میسازید، در حالت blazor web assembly دو option وجود داره:
1. گزینه اول Asp.Net Core Hosted، امکان میده برنامه blazor شما، تحت Net. هاست بشه. یعنی نیاز به net core. برای اجرا شدن روی سرور شما داره و به راحتی میتونین از طریق خروجی exe یا dll که میسازه، اون رو اجرا کنید. (با مدل blazor server اشتباه نگیرید، این گزینه فقط امکان اجرای برنامه روی وب سرور دات نت رو اضافه میکنه و خروجی همچنان یک وب اسمبلی هست)
اگر تیک این گزینه رو نزنید( یا در کنسول آرگومان hosted-- موقع new کردن ندین)، خروجی پابلیش برنامه مستقل از دات نت ساخته میشه و اصلاحا فایل های فشرده static میده مثل html, js که میتونین اون ها رو در CDN ها یا Github Pages آپلود و اجرا کنین. پابلیش کردن این مدل مقداری کانفیگ و مراحل داره برای اجرا.

2. گزینه دوم PWA، که امکانات لازم مانند service worker.js رو برای ساختن یک اپ PWA به پروژه اضافه میکنه. میتونید خروجی رو روی سیستم عامل یا موبایلتون بدون نیاز به مرورگر اجرا کنین و قابلیت offline browsing داشته باشین. درست مثل یک اپ دسکتاپ یا موبایل. در غیر اینصورت برنامه باید حتما روی مرورگر و آنلاین کار بکنه.
برای ساختن اپ blazor pwa در vscode در command line وارد کنید:

 dotnet new blazorwasm --hosted --pwa 

یا با VisualStudio مدل blazor web assembly رو انتخاب و تیک گزینه PWA و Hosted و همچنین Configure Https رو بزنین (امن بودن ارتباطات در این اپ ها الزامیه و نیاز به https هست و این قابلیت فقط در خروجی publish فعال میشه)

اکثر فریم ورک ها مانند Angular, React.js,Vue.js هم از ساختن برنامه های PWA پشتیبانی میکنن.
برنامه های PWA امکان میدن تا وب سایت خودتون رو به شکل یک اپ ریسپانسیو موبایلی یا دسکتاپ در بیارین و کاربر میتونه اون رو مستقل از مرورگر نصب و اجرا کنه. به اینصورت نیاز به ساخت اپ های native برای هر سیستم عاملی مثل android,ios,windows,... نیست.

برای ساخت و آشنایی بیشتر با اپ های PWA میتوانید مقاله های زیر را مطالعه کنید:
https://devblogs.microsoft.com/visualstudio/building-a-progressive-web-app-with-blazor/
https://www.dotnetcurry.com/aspnet-core/progressive-web-apps-blazor-vuejs-angular
مقاله فارسی:
https://roocket.ir/articles/progressive-web-apps-future-of-modern-web

t.me/csharpfriends
#Blazor #WebAssembly #PWA #Net5 #AspNetCore

یک ویدئو آموزشی بسیار خوب درباره Blazor و قابلیت هایی که داره:
https://www.youtube.com/watch?v=Oeh2IJw7Zig
ویلیام در این ویدئو توضیح میده که چرا با جاوا اسکریپت خداحافظی کرده و با blazor رِل زده :)
از صفر ایجاد یک پروژه و افزودن قابلیت های مختلف، استفاده از js و ... نشون میده:
t.me/csharpfriends #Blazor #Net5

چند سالیه که NetCore. و AspCore خیلی سر و صدا کرده. از بدو انتشارش تا الان، مهمترین موضوعاتی که مورد توجه برنامه نویس ها و اهل فن بوده، پرفورمنس زیاد و چندسکویی بودن اونه. قبلا نرم افزار هایی که با c#.net نوشته میشدن مختص محیط ویندوز بودن. بعدها عده ای خوش ذوق Mono رو نوشتن که امکان کامپایل و اجرای برنامه های تحت .net رو برای لینوکس و مک میداد. این اتفاق پیش آمدی شد برای موتور بازی سازی Unity تا بتونین توسط c# و mono برای هر os ای بازی بنویسین.
فریم ورک های دیگه ای مثل Xamarin قوی تر شدن که امکان طراحی و برنامه نویسی اپلیکیشن های موبایل برای android/ios/windowsPhone با c# و xaml رو میده.
اما با ظهور NetCore. و اخیرا Net5. دیگه این محدودیت ها به چشم نمیان و شما میتونین برنامه های وب و حتی دسکتاپ تون رو برای سیستم عامل های دیگه هم کامپایل کنین. علاوه بر اینکه NetCore. پیشفرض خروجی portable میده و همه جا فقط با نصب NetRuntime. اجرا میشن ( که با نوعی کامپایل میشه نیاز به رانتایم رو هم حذف کرد عملا، فقط حجم خروجی یکم بیشتر میشه). موتور unity جدید هم از netstandard. پشتیبانی میکنه.

نکته مهم بعدی اینه که تقریبا تمام بنچ مارک ها ، تست های پرفورمنسی و عملیاتی ای که در وب سایت های معروفی مثل techempower منتشر میشه و میبینید؛ بر بستر لینوکس هستند. طبق گفته مایکروسافت، Asp.Net Core در حالتی که توسط وب سرور داخلی خودش یعنی Kestrel اجرا بشه چندین برابر سریعتر از حالتیه که در IIS ویندوز اجرا بشه. به دلیل اینکه واسط های اضافی ارتباطی کمتر میشن و از قابلیت های بازنویسی شده خود net core که بهینه ترن استفاده میشه.
علاوه بر این قضیه، اشاره شده که سرعت اجرا و عملکرد برنامه های netcore. در محیط های لینوکسی (بهتره بگم unix base) بیشتر از ویندوز هست. این مهم چندین دلیل داره که برخی از اون هارو که میدونم و تست کردم میگم:
1. محیط ترمینال برنامه، در ویندوز cmd یک ترمینال وابسته است که به صورت sync کار میکنه. همچنین encoding و فرآیند درج و چاپ متن در اون تک رشته ایه و با block شدن thread برنامه همراهه، ازین رو با محیط های unix ای متفاوته.
پروسه درج و چاپ متن در ترمینال های لینوکس async هست، سریعتره و حافظه و پردازش کمتری مصرف میکنه. برای تست این موضوع میتونین تعداد زیادی Log در برنامه تون ایجاد کنین که در کنسول نمایش داده بشه. این خروجی رو در ویندوز و لینوکس مقایسه بکنین مثلا response time درخواست ها یا سرعت خاتمه کار اون task پس از چاپ تعداد زیادی متن در console.
(میتونین با یک کتابخانه logging مثل serilog لاگینگ برنامه تون رو کامل تر و بیشتر بکنین و request/response ها و توابع تون رو لاگ کنین و سطح لاگینگ رو بزارین روی Debug، این قضیه بیشتر هنگام زیر بار بودن سرور مشهوده)
2. پلتفرم اجرای برنامه، در هر دو سیستم عامل ویندوز و لینوکس api های متفاوتی برای ارتباط در سطوح پایین تر و سیستم عامل وجود داره. به شکل چشم گیری توابع و کتابخانه های لینوکسی بهینه تر و سریعتر عمل میکنن (حالا چه به خاطر زبان c و کتابخانه های پورت شده زبان ماشین و چه کرنِل)، به همین دلیل مایکروسافت چندین بار کتابخانه های netcore. رو تعویض و بازنویسی کرده.
3. مصرف منابع یکی دیگه از معضلات ویندوز، به دلایل متعددی ویندوزها resource بیشتری در اختیار میگیرین و خودشون اون رو به برنامه های ثالث دیگه تخصیص میدن و مدیریت میکنن. مصرف حافظه و سربار پردازشی در این قضیه مشهوده و از کسی پوشیده نیست. ساده ترین کار مقایسه یک سیستم عامل لینوکسی با یک ویندوزی هست.
یا مثلا اخیرا سرور مجازی ای گرفته بودم که 2 هسته cpu و 2g رم داشت. پروژه رو روی یک ubuntu اجرا کردم و نهایت مصرف سرور من 1 هسته cpu و 512mb الی 1g رم بود. در حالی که در نسخه ویندوزی این مشخصات حتی قادر به اجرای خود اون ویندوز هم نبودن(حتی در نسخه بدون رابط کاربری ویندوز مثل nano/core)، و حداقل 4 هسته و 4 گیگ رم دیگه باید بهش افزوده میشد. همین الان هم میتونین خودتون بدون نیاز به این کارها. کارای روزمره تون رو با این 2 سیستم عامل انجام بدین و خودتون مقایسه کنین.

مسئله دیگه ای که در benchmark های aspcore/netcore مشاهده میشه. دیتابیس هست. معمولا بنچمارک هایی که در اون ها از دیتابیس هایی مثل PostgreSQL و elastic استفاده شده، یا orm اونها ado.net بوده پرفورمنس و نتایج بهتری نسبت به sql server و mysql با efcore داشتن.
مراحل و stage هاشونم مشخصه. یکسری تست پردازش text ان، یکسری پردازش آبجکت های بزرگ مثل لیست ها و آرایه ها، یکسری کوئری ها و درج و خوندن و الی یادگیری ماشین و پردازش تصویر، انصافا عملکرد خوبی رو به نمایش گزاشته. اینم اضافه کنم که native ها از managed ها و اونایی که مصرف حافظه رو خودشون مدیریت میکنن منطقا سریعترند.

این نتایج بنچمارک دوره 20 ام وبسایت Techempower در تاریخ (2021-02-08) است.
شامل پرفورمنس تست فریم ورک ها، میکرو فریم ورک ها و کتابخانه های وب میشه.
نزدیک 440 وب فریمورک و نتایج شون برای عملیات های مختلف قابل مشاهده و مقایسه است. هر کدوم از بخش ها در این صفحه، عملکردشون در سناریو های متفاوت رو نشون میده. مثلا تصویر اولی که در بالا فرستادم، در بحث کار با دیتابیس شامل کوئری گرفتن و برگرداندن لیستی از داده ها در زمان اجرا، به کلاینت عملکرد 347 فریم ورک رو گزارش کرده.
در این گزارش، ستون ها به ترتیب نشان دهنده موارد زیر به ازای هر رکورد هستن:
نام framework، حداکثر میزان کارایی (بسته به نوع تست مثلا تعداد پاسخ در ثانیه، زمان سریالایز و deserialize کردن json و کوئری ها و ...)، نرخ پاسخ موفق (Success Rate) و ستون آخر شامل طبقه بندی (نوع فریم ورک مثلا micro/fullstack)، زبان برنامه نویسی مثلا Rust/Go، پلتفرم مثلا Net.، وب سرور مثلا Kestrel/Nginx، سیستم عامل (که معمولا Linux هست)، دیتابیس مثلا postgres/sql/mysql، سیستم عاملی که دیتابیس رو اجرا میکنه (معمولا Linux)، ORM و رویکرد پیاده سازی (Impl Approach).
هر گزارشی تقریبا به همین شکله با اندکی تغییر در جزئیات دیگر در ستون های ذکر شده. مثلا تست های JSON serialization، Plaintext، Single/Multiple Queries هر کدوم به شرح گزارش عملکرد این فریم ورک ها در این سناریو ها پرداختن.
در تصویر اول فوق که تست Fortune هست، aspcore-ado-pg رتبه 12 ام با 401 هزار پاسخ در ثانیه است. (asp.net core + ado.net + postgreSql Db)
(Furtune Test: This test exercises the ORM, database connectivity, dynamic-size collections, sorting, server-side templates, XSS countermeasures, and character encoding.)
در ردیف های اول فریم ورک و میکروفریم ورک هایی مثل dragon و actix به ترتیب با 666,660(تقریبا 670هزار) پاسخ در ثانیه قرار دارند. (این فریم ورک ها با زبان های c++ و rust کار میکنن که خیلی سریع تر و بهینه تر هستن، اما توسعه با اون ها کار به مراتب دشوار تری هست)
در نظر داشته باشین، بعضی از این web framework ها، خیلی کوچک و با یکسری کاربرد های محدود و مشخص هستند. در عین حال وب فریم ورک هایی مثل Asp.NetCore یا فریم ورک های بر پایه Java یا پایتون، امکانات و کاربردهای بیشتری برای نرم افزار های بزرگ و enterprise دارن. تا مدتی node js هم در ردیف های بالای گزارش ها بود، اما رفته رفته نزول پیدا کرد و کمتر توسعه داده شد، مخصوصا با قدرت گرفتن NetCore. و یا فریم ورک هایی که با زبان سریع rust طراحی میشدن. اما هنوز هم نسبت به php نتایج قابل قبول تری داره :))
در تصویر دوم، تست PlainText (که فقط یک برنامه HelloWorld ساده است با تعداد بسیار عظیمی درخواست که باید به همه اونها متن HelloWorld رو برگردونه) Asp.net Core در rank دوم با 7,016,966 (تقریبا 7 میلیون و 17 هزار) پاسخ در ثانیه و نرخ 99.9% قرار گرفته که به جرعت، شاهکاری در سال های اخیر برای Net. هست (چرا که از معایب اون ضعف در پردازش رشته ها و مشکلات GC برای اون بود که الان خیلی بهینه تر شده، خوبه که بدونید دات نت رشته های پراستفاده و تکراری رو نگه میداره و ازشون استفاده مجدد میکنه بنابراین حجمشون کمتر و سرعت بالاتر میره).
(PlainText Test: In this test, the framework responds with the simplest of responses: a "Hello, World" message rendered as plain text. The size of the response is kept small so that gigabit Ethernet is not the limiting factor for all implementations. HTTP pipelining is enabled and higher client-side concurrency levels are used for this test)
تست های متعدد دیگه ای هم هست که میتونین در سایت ببینید:
https://www.techempower.com/benchmarks
t.me/csharpfriends #Benchmark #Techempower #Performance

یک نکته درباره اجرای پروژه Blazor MicroBlog و عملکردش:

توجه داشتیه باشین که برای استفاده از قابلیت pwa پروژه Blazor MicroBlog و نصب اون مثل یک اپلیکیشن در دستگاهتون، باید خروجی publish از api بگیرید و روی https اجرا کنین (ترجیحا Edge/Chrome)
(همچنین برای تست میتونید نسخه v0.8-beta1 PreRelease رو از قسمت releases گیتهاب پروژه دانلود و اجرا کنید)
برنامه سرور Api، اپ کلاینت رو داخل Net. پراکسی و هاست میکنه. از مزایای این روش عدم نیاز به اجرای جداگانه پروژه ها، caching یکپارچه تر، تست و اجرای نسخه pwa برنامه است.
تنها عیب این حالت نیاز به net core. برای اجراست که در هر صورت برای اجرای پروژه سرور نیازه. بعد از اون رابط کاربری روی مرورگر کاربر ذخیره و از همونجا اجرا میشه. بنابراین سرور سبک تر خواهد بود و کلاینت هم میتونه از قابلیت offline استفاده بکنه. چرا که نیاز به گرفتن صفحات از سرور نداره و از وب اسمبلی استفاده میکنه.
اگر نمیخواین از مدل Net Hosted. استفاده کنین، باید سرویس های Blazor رو از فایل startup سرور حذف کنین. در اینصورت پروژه کلاینت blazor رو باید دستی هاست و اجرا کنین که یکم دردسر داره. و بعدا روشش رو میگم. (چون فقط static file دارید)

خوشحال میشم دوستانی که علاقه مند هستن، نسخه 0.8 بتا پروژه MicroBlog رو تست کنن و بازخورد بدن. میتونید مستقیما exe برنامه رو اجرا کنین، بدون دردسر و کامپایل. در release ها موجوده)

https://github.com/mrgrayhat/BlazorMicroBlog
t.me/csharpfriends
#Blazor #Net5 #WebAssembly #BlazorHosted