C# Programming Guide

C# Programming Guide

Photo

به شخصه اصلا توی پروژه ها و پکیج هایی که خیلی پرفورمنس توشون مهمه از این روش استفاده نمی کنم (اعتبار سنجی ویدئوی بالا) و توصیه میکنم شما هم اگر پکیجی دارید که کارش اینه از این روش های مدیریت اعتبار سنجی ورودی ها استفاده نکنید (خیلی هم این نوع اعتبار سنجی ها مرسومه و کسی فکر بهتری براش نداره)
پترنی که من توی این شرایط ساختم و ازش استفاده میکنم:

شما باید فرض رو بر این بگیرید که همه چیز درسته و طبق معمول داده های ورودی اشتباه نیست، وقتی چیزی اشتباه میشه یعنی داده های ورودی بنابه هر دلیلی اشتباه وارد شده که احتمالا یا از باگ هست یا کاربر داده های ورودی رو اشتباه فرستاده.
اما چطوری به برنامه نویس بگیم که به پکیج ما داده ی ورودی اشتباهی وارد کرده و خطای درستی بهش نشون بدیم تا مشکل یابی براش سریع و راحت باشه؟
این پترن این شکلی کار میکنه که کلاس های شما و هسته ی بیزینسی اون داده های خام و لاجیک مخصوص به خودشون رو دارن، بدون اینکه اعتبار سنجی ای توش باشه و بدون اینکه حتی try و catch توش گذاشته باشید. بنابراین توی لاجیک اصلی برنامه فرض بر اینه که همه چیز درسته.
در قسمتی از پروژه یک try و catch کلی دارید که به محض خوردن به Exception کلاس های اعتبار سنجی رو اجرا میکنن و خطای اعتبار سنجی صحیحی رو به برنامه نویس نشون میدن. حتی میتونید مدیریت این Try catch ها رو به خود برنامه نویس بسپارید.
اینکار باعث میشه فقط در صورتی که به exception خوردید اعتبار سنجی ها اتفاق بیوفته و خطای درستی به کاربر نشون داده بشه.
به این نکته ی مهم توجه کنید مثلا در سریالایز کردن یا دیسریالایز کردن یک داده ی json ممکنه میلیون ها پردازش در لحظه داشته باشید که ممکنه در ماه هم به یک استثنا نخورید. ولی وقتی اعتبار سنجی رو داخل منطق اصلی بذارید به ازای میلیون ها پردازش شما اونا رو انجام دادید.
چقدر سربار الکی ایجاد شده در حالی که با استفاده از این پترن همه‌ی اون سربار رو از بین بردید.
اینجاست که پکیجی مثل BinaryGo نسبت به بقیه پرفورمنس بالاتری داره چون از این پترن استفاده میکنه (البته هنوز این پترن رو تکمیل نکردم و در نظر دارم که یک پکیج براش بسازم)
نکته: این پترن توی همه ی پروژه ها توصیه نمیشه فقط پروژه هایی که تمرکزشون روی پرفورمنسه خیلی مهمه.

www.tg-me.com/jp/telegram/com.CsharpTips/352

250 viewsedited  May 9, 2022 at 07:23

به شخصه اصلا توی پروژه ها و پکیج هایی که خیلی پرفورمنس توشون مهمه از این روش استفاده نمی کنم (اعتبار سنجی ویدئوی بالا) و توصیه میکنم شما هم اگر پکیجی دارید که کارش اینه از این روش های مدیریت اعتبار سنجی ورودی ها استفاده نکنید (خیلی هم این نوع اعتبار سنجی ها مرسومه و کسی فکر بهتری براش نداره)
پترنی که من توی این شرایط ساختم و ازش استفاده میکنم:

شما باید فرض رو بر این بگیرید که همه چیز درسته و طبق معمول داده های ورودی اشتباه نیست، وقتی چیزی اشتباه میشه یعنی داده های ورودی بنابه هر دلیلی اشتباه وارد شده که احتمالا یا از باگ هست یا کاربر داده های ورودی رو اشتباه فرستاده.
اما چطوری به برنامه نویس بگیم که به پکیج ما داده ی ورودی اشتباهی وارد کرده و خطای درستی بهش نشون بدیم تا مشکل یابی براش سریع و راحت باشه؟
این پترن این شکلی کار میکنه که کلاس های شما و هسته ی بیزینسی اون داده های خام و لاجیک مخصوص به خودشون رو دارن، بدون اینکه اعتبار سنجی ای توش باشه و بدون اینکه حتی try و catch توش گذاشته باشید. بنابراین توی لاجیک اصلی برنامه فرض بر اینه که همه چیز درسته.
در قسمتی از پروژه یک try و catch کلی دارید که به محض خوردن به Exception کلاس های اعتبار سنجی رو اجرا میکنن و خطای اعتبار سنجی صحیحی رو به برنامه نویس نشون میدن. حتی میتونید مدیریت این Try catch ها رو به خود برنامه نویس بسپارید.
اینکار باعث میشه فقط در صورتی که به exception خوردید اعتبار سنجی ها اتفاق بیوفته و خطای درستی به کاربر نشون داده بشه.
به این نکته ی مهم توجه کنید مثلا در سریالایز کردن یا دیسریالایز کردن یک داده ی json ممکنه میلیون ها پردازش در لحظه داشته باشید که ممکنه در ماه هم به یک استثنا نخورید. ولی وقتی اعتبار سنجی رو داخل منطق اصلی بذارید به ازای میلیون ها پردازش شما اونا رو انجام دادید.
چقدر سربار الکی ایجاد شده در حالی که با استفاده از این پترن همه‌ی اون سربار رو از بین بردید.
اینجاست که پکیجی مثل BinaryGo نسبت به بقیه پرفورمنس بالاتری داره چون از این پترن استفاده میکنه (البته هنوز این پترن رو تکمیل نکردم و در نظر دارم که یک پکیج براش بسازم)
نکته: این پترن توی همه ی پروژه ها توصیه نمیشه فقط پروژه هایی که تمرکزشون روی پرفورمنسه خیلی مهمه.

BY C# Programming Guide