Software Philosophy – Telegram
Software Philosophy
3.45K subscribers
160 photos
41 videos
1.54K links
چکیده‌ای از مفاهیم به روز مهندسی نرم افزار برای مهندسین نرم‌افزار.
معماری نوین نرم‌افزار، تکنولوژی‌های برنامه نویسی جدید
Download Telegram
Forwarded from Software Philosophy
یکی از ارکان مهم هر تیم رهبری تیم است. منظور از رهبر، یک نفر خاص نیست. بلکه رهبری یک ویژگی شخصیتی است که وجود آن در تک تک افراد تیم باعث پیشرفت تیم می‌شود.
در یک تیم فوتبال، دربازه‌بان شخصیتی است که وظیفه بسیار سختی دارد. برعکس مهاجمان که از بین تمام حرکاتشان فقط آنهایی که منجر به گل زدن می‌شود شمرده می‌شوند و مستحق تشویقند، دربازه‌بان‌ها بین تمام حرکاتشان فقط اشتباهاتشان شمرده می‌شود که منجر به شکست تیم می‌شود.
در یک تیم شخصیت رهبری تشابهات زیادی با ویژگی‌های شخصیتی یک دربازه‌بان دارد. در لینک زیر توضیح داده شده است که چگونه خصلت‌های دربازه‌بان‌ها می‌تواند الگویی برای تقویت روحیه رهبری باشد.


http://mehrandvd.me/2015/07/16/goalkeepers-vs-leaders-2/

#مهران_داودی
لینکداین:
https://ir.linkedin.com/in/mehrandvd


کانال تلگرام:
@SoftwarePhilosophy


___
چگونه فکر کنیم؟ چگونه دور از هم با هم فکر کنیم!!

فکر کردن، و مخصوصا با هم فکر کردن یکی از کارهای سختی است که معمولا ترجیح می‌دهیم آن را انجام ندهیم.
معمولا خیلی سخت است که در یک جمع فکر کنیم و به نظرمان همه چیز درست پیش برود! این کار خیلی خیلی سخت‌تر می‌شود اگر کل تیم شما «ریموت» است و باید «دور از هم با هم فکر کنید»!!!

امروز در INOTEX 2019 مهران داودی توضیح می‌دهد که چگونه یکی از مفاهیم جذاب Design Thinking می‌تواند کمک کند بسیار کارآمدتر با هم فکر کنیم.

زمان و مکان:
امروز ساعت ۱۶:۴۰ نمایشگاه بین‌المللی، سالن ۴۰

www.inotex.com
Forwarded from فلسفه دیزاین
تا ماتریکس و فراتر از آن

با بررسی Trendها می‌توان انتظار داشت که در ده سال آینده شاهد تغییری بزرگ و اساسی، در تعامل انسان با کامپیوتر باشیم. زمانی که دیگر محدود به چاردیواری صفحه‌نمایش‌ِ موبایل‌ِ خود نخواهیم بود.
در سال‌های پیش رو محصولات دیجیتالی، بیشتر و بیشتر وابسته به تجربه‌ی کاربر از طریقه دو هوش عقلی (IQ) و هوش هیجانی (EQ) خواهند بود.

آیا می‌توانید دنیا را بدون دکمه‌ها، پنل‌ها و منوها تصور کنید؟ دنیای دیجیتالی که قابل جداسازی از دنیای واقعی نباشد و از تمامی حواس پنج‌گانه‌ی ما برای تعامل استفاده کند.

در مقاله‌ی پیش رو سه مدیومی را که قبلا نام آن‌ها به گوشمان خورده، با جزئیات بیشتر و از منظر طراحی، بررسی خواهیم کرد.
۱) صدا
۲) واقعیت افزوده (AR)
۳) واقعیت مجازی (VR)

باید محدودیت مغزمان که به ما می‌گوید «همه چیز باید آنطور باشد که قبلن بوده است» را کنار گذاشته و با آینده‌ای روبرو شویم که تمامی امکانات آن، در حال حاضر فراهم شده است:

http://bit.ly/dxgn478


و در آخر بعد از خواندن مقاله لینک‌های زیر را برای غرق شدن در این دنیای جذاب و همچنین آشنایی بیشتر با جزئیات آن پیشنهاد می‌کنیم.

۱) https://www.toptal.com/designers/ui/future-ui-design-without-buttons
۲) https://www.getwrecked.com/the-future-of-ui-design-and-how-it-will-impact-our-everday-lives/
۳) https://virtualreality.su/
۴) https://developers.google.com/ar/
۵) https://developer.apple.com/arkit/
۶) https://vrtodaymagazine.com/vr-design-apps/
۷) https://medium.com/google-design/from-product-design-to-virtual-reality-be46fa793e9b

نویسنده: حسین میرزاده

#واقعیت_افزوده #واقعیت_مجازی #چشم_انداز
@Dexign فلسفه دیزاین


______
ری‌اکت Hooks با ایده حل مشکلاتی که کاربران با ری اکت داشتند معرفی شد. مانند حل مشکل کامپوننت‌های خیلی بزرگ و صعب‌الدیباگ اما آیا واقعا ری‌اکت Hooks این مشکلات را حل می‌کند؟ ری‌اکت Hooks قرار است چه تغییری برای ما ایجاد کند؟
این مقاله توضیح می‌دهد که ری‌اکت هوکس چه تغییراتی داشته است و چه مشکلاتی را حل می‌کند. در ابتدای مقاله هم ویدیو یک ساعته معرفی Hooks در کنفرانس ری اکت وجود دارد که می‌توانید آن را تماشا کنید.

https://medium.com/@dan_abramov/making-sense-of-react-hooks-fdbde8803889

#مریم_کمالی (http://ow.ly/9Wa430mFGeK)

کانال تلگرام:
@SoftwarePhilosophy

___
Forwarded from DotNetZoom (محمد جواد ابراهیمی)
پروژه gRPC ؛ نسل بعدی RESTful !

قبل از اینکه ببینیم gRPC چیه بهتره بدونم اصلا RPC چیه؟ RPC که مخفف Remote Procedure Call هست یه پروتکل واسه فراخوانی یه سرویس از یه برنامه داخل یه برنامه دیگه هست. یعنی برنامه A برای اینکه یه فانکشنی داخل برنامه B روی بتونه فراخوانی کنه از این پروتکل استفاده میکنه

پروژه gRPC درواقع یک فریمورک RPC سریع و قدرتمند هست که توسط گوگل و همکاری چندتا از شرکت های بزرگ دنیا درست شده.
توسط این فریمورک، کلاینت میتونه با سرور ارتباط برقرار کنه، یه API رو فراخوانی کنه و دیتای لازم بینشون رد و بدل بشه، چیزی مشابه RESTful ولی خیلی سریع تر، بهینه تر و ایمن تر؛ به دلایل زیر:

🔸 پروتکل gRPC به صورت پیشفرض واسه سریالایز کردن اطلاعات و پیام هایی که رد و بدل میشه از ProtocolBuffer استفاده میکنه که یه مکانیزم فوق سریع و قدرتمند برای سرایلایز کردن دیتا هست (یه کتابخانه با همین نام توسط گوگل نوشته شده و wrapper دات نتیش هم اسمش protobuf-net هست)
فرمت اطلاعات توی ProtocolBuffer به صورت باینری هست و از این بابت حجم اطلاعات کاهش پیدا میکنه در نتیجه اطلاعات قبل از ارسال فشرده میشن و ترافیک کمتر و درنتیجه سرعت بیشتری رو خواهیم داشت

🔹 یکی دیگه از خوبی های gRPC اینه که Schema (ساختار) متد های قابل فراخوانی سمت سرور به همراه پارامتر های ورودی و خروجی و ساختارشون رو برای کلاینت مشخص میکنه (مثل فایل swagger.json توی پروتکل Open API و ابزار Swagger)
یعنی کلاینت دقیقا میدونه چه کلاس ها و چه متد های در سمت سرور برای فراخوانی وجود داره و هر متد هم چه پارامتر هایی میگیره، ساختارشون چیه و چه خروجی ایی میده

🔸 نکته مثبت دیگه ای که داره اینکه قابلیت Bi-directional Streaming داره، یعنی در عین حال که کلاینت داره به سرور جریانی از داده ها (Stream) رو ارسال میکنه، همون لحظه سرور هم میتونه جریانی از داده ها رو برای کلاینت ارسال کنه (ارسال و دریافت همزمان اطلاعات) و این یعنی "ارتباط کاملا دو طرفه Stream ایی"

🔹 همچنین gRPC از پروتکل HTTP2 استفاده میکنه که هم سریعتر و هم ایمن تر از ورژن های قبلی HTTP هست

🔸 این پروتکل ارتباطی کاملا مستقل از زبان برنامه نویسی سمت کلاینت و سرور عمل میکنه درنتیجه مثلا کلاینت شما میتونه با Java نوشته بشه و سرور شما با سی شارپ یا هر زبان دیگه

اطلاعات بیشتر:
https://grpc.io
https://github.com/grpc/grpc
_______________
@IranAspMvc
#پست_مجدد این پست تا به حال بیش از ۲۶۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد
Forwarded from Software Philosophy
یکی از مهمترین کارهایی که یک معمار نرم‌افزار انجام می‌‌دهد تشخیص و خلق مفهومی به نام «فضا» است. اگر در نرم‌افزاری فضاها به درستی ساخته نشوند، برنامه نویسان دچار سردرگمی می‌شوند و عمدتا کدهای تکراری خواهند نوشت. ساخت فضاهای درست توسط معمار نرم‌افزار احتمال نوشته شدن کدهای تکراری یا اضافی را کم می‌کند.

در لینک زیر مفهوم فضا در معماری نرم‌افزار توضیح داده شده
http://mehrandvd.me/2015/09/16/software-architect-its-all-about-spaces/
Forwarded from فلسفه دیزاین
کاربرانی هوشیار و بدور از اعتیاد

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

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

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

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

مقاله امروز، درباره مفاهیمی مثل «خوانا و صریح» بودن متون طرح یا اپلیکیشن، ایجاد احساس همیاری و همدلی در کاربر و استفاده درست از جلوه‌های بصری در جهت تربیت کاربرانی «آگاه و هوشیار» بجای کاربرانی «پرکار و معتاد» است.

مقاله امروز را از دست ندهید:

http://bit.ly/dxgn482


(زمان حدودی مطالعه، ۹ دقیقه)

نویسنده: آرش اصغری

@Dexign فلسفه دیزاین
#تجربه_کاربری #اعتیاد


ـــــــ
#پست_مجدد این پست تا به حال بیش از ۶۴۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد
Forwarded from Software Philosophy
یکی از مباحثی که همیشه در تشکیل تیم‌های نرم‌افزاری مطرح است، انتخاب زبان برنامه‌نویسی و یا تکنولوژی‌های مورد استفاده است. مقایسه محصولات موفق و نا موفق نشان می‌دهد هیچکدام از آنها صرفا با یک تکنولوژی و یا یک زبان خاص نوشته نشده‌اند. برای مثال سیستم‌های موفق زیادی وجود دارند که با Java و یا C# نوشته شده‌اند. همچنین سیستم‌های بی کیفیت زیادی نیز وجود دارد که با Java و یا C# نوشته شده‌اند. این حقیقت نشان می‌دهد دلیل موفقیت یا شکست سیستم‌ها نمی‌تواند زبان برنامه‌نویسی باشد. مقاله زیر توضیح می‌دهد که چطور طرز فکر برنامه‌نویس‌ها موفقیت و یا شکست یک سیستم را رقم می‌زند.

http://mehrandvd.me/2015/10/15/software-quality-comes-from-people-not-languages/

#مهران_داودی
https://ir.linkedin.com/in/mehrandvd


کانال تلگرام:
@SoftwarePhilosophy

___
در سال 2004 ایده‌ای مبنی بر اتومات کردن تست‌ها در محیط وب توسط جیسون هوگینز مطرح شد که به طور اتومات فرایند مدیریت اکشن‌ها را در مرورگر کنترل می‌کرد. این شیوه بعدا با نام JavaScriptTestRunner معروف شد.
این برنامه نقطه آغاز برنامه‌ای شد که امروزه آن را با نام سلنیوم می‌شناسیم. سلنیوم در حقیقت مجموعه‌ای open source از ابزارهاست که به ما کمک می‌کنند برنامه‌های وب را در مرورگرها و سیستم‌های عامل به صورت اتومات تست کنیم .
مقاله زیر یک متال از استفاده سلنیوم با C# و dotnet core است که مطالعه آن خالی از لطف نیست:

https://blankstechblog.com/2019/05/23/cross-platform-selenium-with-dotnet-core/


https://github.com/andyrblank/Selenium-C-Sharp-Example

#شهریار_انتظام (http://ow.ly/qDN430nPiCg)

کانال تلگرام:
@SoftwarePhilosophy

___
Forwarded from DotNetZoom (محمد جواد ابراهیمی)
یک تغییر مهم در ASP.NET Core 3.0 Preview 4

تغییرات این ورژن بیشتر مربوط به blazor بود که میتونین توی لینک ماکروسافت بخونینش ولی یه تغییر کوچیک اما مهم هم بین شون بود

از این پس به جای متد AddMvc توی ConfigureServices کلاس Startup سه تا متد دیگه اومده که بسته به نیازمون باید ازش استفاده کنیم.
- AddControllers
- AddControllersWithViews
- AddRazorPages
البته متد AddMvc توی این نسخه حذف نمیشه ولی احتمالش هست توی ورژن های بعدی حذف بشه.

🔸 اگه فقط میخواین API بنویسین یعنی به Controller نیاز دارین ولی به View یا Page نیاز ندارید باید از متد AddControllers استفاده کنید (پروژه Web API)
public void ConfigureServices(IServiceCollection services)
{
services.AddControllers();
}

این متد موارد زیر رو اضافه میکنه :
- Controllers
- Model Binding
- API Explorer (OpenAPI integration)
- Authorization [Authorize]
- CORS [EnableCors]
- Data Annotations validation [Required]
- Formatter Mappings (translate a file-extension to a content-type)

موارد زیر قبلا توی AddMvc اضافه میشد ولی توی متد بالا دیگه اضافه نمیشه :
- Antiforgery
- Temp Data
- Views
- Pages
- Tag Helpers
- Memory Cache


🔹 اگه یه سایت MVC به صورت معمولی میخواین بنویسین یعنی به هم به Controller و هم به View نیاز دارید باید از متد AddControllersWithViews استفاده کنید (پروژه MVC)
public void ConfigureServices(IServiceCollection services)
{
services.AddControllersWithViews();
}

این متد موارد زیر رو اضافه میکنه :
- Controllers
- Model Binding
- API Explorer (OpenAPI integration)
- Authorization [Authorize]
- CORS [EnableCors]
- Data Annotations validation [Required]
- Formatter Mappings (translate a file-extension to a content-type)
- Antiforgery
- Temp Data
- Views
- Tag Helpers
- Memory Cache

موارد زیر قبلا توی AddMvc اضافه میشد ولی توی متد بالا دیگه اضافه نمیشه :
- Pages


🔸 اگه یه سایت MVC به صورت Razor Pages میخواین بنویسین یعنی به هم به Controller و هم به Page نیاز دارید باید از متد AddRazorPages استفاده کنید (پروژه Razor Pages)
public void ConfigureServices(IServiceCollection services)
{
services.AddRazorPages();
}

این متد موارد زیر رو اضافه میکنه :
- Pages
- Controllers
- Model Binding
- Authorization [Authorize]
- Data Annotations validation [Required]
- Antiforgery
- Temp Data
- Views
- Tag Helpers
- Memory Cache

موارد زیر قبلا توی AddMvc اضافه میشد ولی توی متد بالا دیگه اضافه نمیشه :
- API Explorer (OpenAPI integration)
- CORS [EnableCors]
- Formatter Mappings (translate a file-extension to a content-type)


🔹 هدف این کار اینه که متد هایی متمرکز و بهینه شده (بدون موارد اضافه) برای هر کاربرد وجود داشته باشه تا با استفاده از اونها به جای AddMvc کلی سربار اضافه به پروژه تحمیل نکنیم

اطلاعات بیشتر:
https://devblogs.microsoft.com/aspnet/asp-net-core-updates-in-net-core-3-0-preview-4/
___________
@IranAspMvc
#پست_مجدد این پست تا به حال بیش از ۳۴۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد
Forwarded from Software Philosophy
مفاهیم Covariance و Contravariance یکی از مباحث مهم در زبان‌های برنامه‌نویسی مدرن محسوب می‌شود. تسلط بر این مفاهیم به طراحان فریم‌ورک‌ها و پلتفرم‌ها کمک می‌کند تصمیم‌های مناسب‌تری در طراحی کلاس‌ها داشته باشند.
از آنجایی این مفاهیم انتزاعی هستند، معمولا فهم آنها در وهله اول سخت به نظر می‌رسد. مقاله زیر با چند مثال قابل لمس این مفاهیم را به زبان ساده‌تری توضیح داده تا فهم آن لذت‌بخش‌تر و آسان‌تر شود.

http://mehrandvd.me/2016/06/18/covariant-and-contravariant/

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

کانال تلگرام:
@SoftwarePhilosophy



___
Forwarded from فلسفه دیزاین
رُک باش، کلیشه‌ها را بشکن

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

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

چیزی که واقعا منظورمان است:
"مسیری را که انتخاب کردی را دوست ندارم"

یک پادگان را در نظر بگیرید. دستورات همیشه منظم، دقیق و بدون ابهام به صورت صریح بیان می‌شود. اگر آن وظیفه انجام نشود و یا ناقص انجام شود، لااقل خیالمان ازین بابت راحت است که ابهامی در تفهیمِ وظیفه‌ی محوّله نبوده است و باید جایی دیگر، عیب‌یابی شود.

فضای دیزاینری هم مستثنی از صداقت و صراحت نباید باشد. چون در آخر نتیجه‌ای جز بیراهگی، هزینه‌های گزاف و روابط بد اعضای تیم نخواهد داشت.

در دو مقاله‌ی‌ زیر با جزئیات بیشتر این شرایط نامفهوم و کلیشه‌هایی که عادتمان شده است و خودمان از آن‌ها بی‌خبریم آشنا می‌شویم و به تاثیرات مخرب آن پی می‌بریم:

۱- http://bit.ly/dxgn485-1

۲- http://bit.ly/dxgn485-2

(زمان حدودی مطالعه، ۱۰ دقیقه)

نویسنده: حسین میرزاده

#صداقت #کلیشه #محیط_کار
@Dexign فلسفه دیزاین


ــــــــ
و اینک ۹ نکته پرفورمنسی برای Azure App Service

سرویس Azure App Service مهمترین سرویس Azure برای هاستینگ اپلیکیشن‌ها است که امکانات scaling زیادی دارد. هر App Service جلوی خود یک Load Balancer دارد تا بتواند ترافیک را پخش و بالانس کند.

در مقاله زیر از Telerik، اسکات آلن ۹ نکته پرفورمنسی برای کار با App Service را توضیح داده که کمک می‌کنند اصطلاحا Even Faster شوید!!!

ما در «ملک‌رادار» دو تا از این تنظیمات رو انجام نداده بودیم که در حال بررسی هستیم تا اونها رو هم فعال کنیم.

https://www.telerik.com/blogs/nine-performance-tips-for-azure-app-services

#مهران_داودی (http://ow.ly/GwIl309lFEm)

کانال تلگرام:
@SoftwarePhilosophy

___
Forwarded from DotNetZoom (محمد جواد ابراهیمی)
❇️ بررسی قابلیت Endpoint Routing

🔸 مکانیزم مسیریابی به این صورته که ما Route هامون رو توی میدلور MVC توسط متد UseMvc تعریف میکنیم
و زمانی که یه Request به میدلور MVC میرسه، این میدلور بر اساس اطلاعات Url و Route های تعریف شده، اولین Route ایی که همخوانی داشته باشه رو انتخاب میکنه و مقادیر مسیر یابی (RouteValues) رو استخراج میکنه و بدین ترتیب میفهمه که کدوم Controller و Action رو باید فراخوانی کنه

🔹 توی Pipeline چون میدلور ها به صورت ترتیبی اجرا میشن تا زمانی که درخواست ما به میدلور MVC نرسه ما نمیتونیم از RouteValues استفاده کنیم
مشکل جایی پیش میاد که مثلا نیاز داریم واسه وبسایت های چند زبانه که بر اساس Url کار میکنند (مثلا fa/home/index) ما نیاز داریم قبل از رسیدن به میدلور MVC، زبان جاری (همون fa) رو توسط سیستم مسیریابی بخونیم و Culture برنامه رو تغییر بدیم ولی تا زمانی که به میدلور MVC نرسیم این کار امکان پذیر نیست

🔸 یک مثال دیگر آن استفاده از خاصیت EnableCorsAttribute (است که بر خلاف app.UseCors که مکانیزم CORS را به صورت سراسری اعمال میکند) میتوان آن را بر روی یک Action خاص اعمال کرد
از آنجایی که در مکانیزم مسیریابی قبلی، سیستم Routing بسیار وابسته به MVC است ما نمی تونیم قبل از رسیدن به میدلور MVC جلوی درخواست های غیر مجاز رو بگیریم، چرا که به Routing درسترسی نداریم و نمیدونیم کدوم Controller و Action قراره فراخوانی بشه

🔹 توی مکانیزم Endpoint Routing اما، وقتی یه درخواست میاد، همون ابتدا مشخص میشه که به کدوم Route مپ شده درنتیجه بقیه میدلور های قبل از میدلور MVC هم میتونن از سیستم Routing استفاده کرده و اطلاعات داخل Url رو درک کنن

🔸 این قابلیت در ASP Core 2.2 اوایل با نام Dispatcher معرفی شد که بعدا به Endpoint Routing تغییر نام پیدا کرد و به صورت پیشفرض توسط SetCompatibilityVersion ورژن Version_2_2 به بالا فعال میشه

🔹 برای استفاده از Endpoint Routing باید میدلور UseEndpointRouting رو اضافه کنید. کار این midlleware تشخیص Endpoint مورد نظر براساس Url درخواستی و Route های تعریف شده است و پس از آن شما میتوانید از مقادیر مسیریابی (RouteValues) استفاده کنید (حتی قبل از رسیدن به محل تعریف Route ها)

نحوه استفاده از این قابلیت در ASPNET Core 2.2 به صورت زیر است
// ASP.NET Core 2.2
public void Configure(IApplicationBuilder app)
{
app.UseEndpointRouting();

app.OtherMiddleware(); // Access to route values

app.UseMvc();
}

نکته : در ASPNET Core 3.0 متد UseEndpointRouting به UseRouting تغییر نام پیدا کرد و نیز تعریف Route (بهتره بگیم Endpoint ها) به شکل زیر تغییر پیدا کرده
// ASP.NET Core 3.0
public void Configure(IApplicationBuilder app)
{
app.UseRouting();

app.OtherMiddleware();

app.UseEndpoints(endpoints =>
{
// Mapping of endpoints goes here:
endpoints.MapControllers()
endpoints.MapRazorPages()
endpoints.MapHub<MyChatHub>()
endpoints.MapGrpcService<MyCalculatorService>()
});
}

برای غیر فعال کردن قابلیت Endpoint Routing میتوانید توسط MvcOptions.EnableEndpointRouting = false آن را غیرفعال کنید.

لینک مقاله در دات نت تیپس:
https://www.dotnettips.info/post/3031
_______________
@IranAspMvc
#پست_مجدد این پست تا به حال بیش از ۳۲۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد
Forwarded from Software Philosophy
همیشه هر چیز خوبی، می‌تواند بد استفاده شود و نتیجه عکس دهد. این قضیه در مورد تکنولوژی هم صادق است. مقاله زیر توضیح می‌دهد که چه عادت‌های اشتباهی هنگام کار با LINQ می‌تواند شما را به اشتباه بیندازد و باعث ایجاد کد بد شود.
یکی از خطرناک‌ترین ویژگی‌های LINQ این است که وقتی با آن کار می‌کنید احساس می‌کنید خیلی باهوشید که غالبا باعث می‌شود کد احمقانه و پیچیده‌ای با آن بنویسید. فهمیدن مفهوم Provider ها نیز مسئله مهمی است که باید با آن آشنا باشید.
مقاله زیر این نکات را شرح می‌دهد.

http://mehrandvd.me/2016/03/28/linq-the-bad-parts/

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

کانال تلگرام:
@SoftwarePhilisophy



___
#پست_مجدد این پست تا به حال بیش از ۱۳۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد
Forwarded from Software Philosophy
در معماری نرم افزار گاهی نیاز است الگوهایی که دارای بیشترین قابلیت تست و همچنین نسبت به تغییرات خارجی دچار کمترین تغییرات هستند مورد استفاده قرار بگیرند . معماری Hexagonal(یا Ports and Adapter) یکی از این الگوهاست که مکانیزم‌هایی را برای تحقق این هدف بر مبنای تفکر DDD بیان می‌کند . لینک زیر در خصوص این معماری توضیحات مناسبی را ارائه می‌دهد :

https://blog.ndepend.com/hexagonal-architecture/

#شهریار_انتظام (http://ow.ly/qDN430nPiCg)

کانال تلگرام:
@SoftwarePhilosophy

___