نظرات مطالب
اعتبارسنجی مبتنی بر JWT در ASP.NET Core 2.0 بدون استفاده از سیستم Identity
یک نکته: روش تعیین اعتبار دستی یک JWT
اگر خواستید رشته‌ی JWT دریافتی را در سمت سرور و بر اساس تنظیمات ابتدایی برنامه، بدون نیاز به تکرار آن‌ها و به صورت دستی اعتبارسنجی کنید، روش انجام کار به صورت زیر است:
public class TokenFactoryService
{
    private readonly JwtBearerOptions _jwtBearerOptions;

    public TokenFactoryService(IOptionsSnapshot<JwtBearerOptions> jwtBearerOptions)
    {
        if (jwtBearerOptions == null)
        {
            throw new ArgumentNullException(nameof(jwtBearerOptions));
        }

        _jwtBearerOptions = jwtBearerOptions.Value ?? throw new ArgumentNullException(nameof(jwtBearerOptions));
    }

    // From: https://github.com/dotnet/aspnetcore/blob/a450cb69b5e4549f5515cdb057a68771f56cefd7/src/Security/Authentication/JwtBearer/src/JwtBearerHandler.cs
    public bool ValidateJwt(string token)
    {
        foreach (var validator in _jwtBearerOptions.SecurityTokenValidators)
        {
            try
            {
                if (validator.CanReadToken(token))
                {
                    validator.ValidateToken(token, _jwtBearerOptions.TokenValidationParameters, out _);
                }
            }
            catch
            {
                return false;
            }
        }

        return true;
    }
}
نظرات مطالب
پردازش‌های Async در Entity framework 6
- Task.Factory.StartNew و یا نمونه‌ی جدید آن یعنی Task.Run، نباید در اکشن متدهای MVC حضور داشته باشند. چون هر اکشن متد، در یک ترد جداگانه اجرا می‌شود و متدهای یاد شده هم یک ترد مجزای دیگر را ایجاد می‌کنند. بنابراین با اینکار، قابلیت پاسخ‌دهی برنامه را به نصف کاهش می‌دهید (نیاز به یک ترد برای اجرای اکشن متد + یک ترد برای اجرای Task.Run). هدف اصلی از اعمال async، عدم استفاده از یک ترد جدید است و آزاد سازی ترد جاری تا قدرت پاسخ‌دهی برنامه افزایش یابد. همچنین اجرای یک Task، در تردی دیگر، دسترسی آن‌را به HttpContext قطع می‌کند که با اعمال async واقعی، چنین مشکلی وجود ندارد و همه چیز طبیعی به نظر می‌رسد.
- روش ارسال Taskهای Async به یک متد به این صورت است: « یک نکته‌ی تکمیلی: امضای نگارش‌های Task دار و Async این متدها» 
+ اگر هدفتان لاگ کردن خطاها است، در MVC استفاده از روش‌های کار با filterها، قابلیت انجام چنین کاری را بدون تکرار کد، میسر می‌کنند.
نظرات مطالب
یکپارچه سازی Angular CLI و ASP.NET Core در VS 2017
برای تکرار مجدد: ساختار مدیریت پروژه‌های قدیمی MVC 5 در VS مانند پروژه‌های VSCode یا ASP.NET Core (در همان VS با همان نگارش) نیستند. یعنی هرفایلی که در فایل csproj ارجاعی نداشته باشد، در IDE نمایش داده نمی‌شود (اما در پروژه‌های VSCode و یا پروژه‌های جدید ASP.NET Core، به محض اضافه شدن یک فایل جدید به پوشه‌ی پروژه، این فایل در IDE هم نمایان می‌شود). بنابراین روی دکمه‌ی show all files در solution explorer کلیک کنید و فایل‌های جدید را include کنید (مانند قبل و تمام پروژه‌های دیگری از این دست).


یک نکته: علت اینکه پروژه‌های ASP.NET Core به این صورت پویا عمل می‌کنند، وجود NET Core CLI. هست. این CLI هم شبیه به Angular-CLI یک ابزار خط فرمان است که کار ایجاد یک پروژه‌ی جدید تا ساخت و توزیع برنامه را مدیریت می‌کند و در حقیقت VS فقط این فرامین خط فرمان را در پشت صحنه اجرا می‌کند. بنابراین بهتر است از ساختار پروژه‌ای استفاده کنید که اساسا برای ابزارهای CLI طراحی شده‌است.

نظرات مطالب
#Defensive Code in C - قسمت سوم
-طبق ساده‌ترین اصول برنامه نویسی و طراحی نرم افزار هر متد باید جهت انجام دادن فعالیت‌های خود  قبل از انجام عملیات داده‌های ورودی را Validate کند و در صورتی که دیتای ورودی با دیتای مورد انتظار سنخیتی نداشت خطای لازم را صادرکند.
-این مسئله باید بر روی متد هایی که بر روی داده‌ها اعمالی را انجام داده یا متد هایی که فرآیندهای بیزینسی را پیگیری می‌کنند انجام شود
-به نظر شما متدی که داده‌های مربوط به تنها  کاری که انجام می‌دهد را اعتبار سنجی کند، اصل SRP را نقض کرده است!؟
-شما می‌توانید در پروژه‌های اصلی کد‌های مربوط به اعتبار سنجی(اعتبارسنجی‌های استاندارد) را در قالب یک ساختار کلاس بندی شده یا بصورت Aspect در متد‌های خود استفاده کنید تا از تکرار کدها جلوگیری کنید.
- در بالا هم ذکر کردم که این متد فقط یک عمکرد بیزینسی را انجام می‌دهد، و قسمت مربوط به اعتبار سنجی داده‌های ورودی یک مسئولیت جدید محسوب نمی‌شود.
-اینکه پارامتر متد به صورت string در نظر گرفته شده اند به خاطر ذکر مثال می‌باشد، این مسئله هم کاملا بدیهی است که در نظرگرفتن این پارامتر بصورت decimal اعتبار سنجی‌های اضافی را از بین می‌برد.
نظرات مطالب
ساختار پروژه های Angular
تشکر.شما در مورد مسیر یابی هم قطعه کدی قرار دادید که میشود وابستگی‌ها و ... را تزریق کرد.منتها اگر ما بیش از 100 مسیر داشته باشیم باید چه کنیم؟ یعنی به ازای هر مسیر باید این قطعه کد تکرار شود :
$routeProvider.when('/about', {templateUrl:'views/about.html', resolve:{deps:function($q, $rootScope)
{
    var deferred = $q.defer();
    var dependencies =
    [
        'controllers/AboutViewController.js',
        'directives/some-directive.js'
    ];
  
    //*نکته اول 
    $script(dependencies, function()
    {
        // *نکته دوم
        $rootScope.$apply(function()
        {
            deferred.resolve();
        });
    });
  
    return deferred.promise;
}}})
راه حل پویایی وجود دارد؟
مثلا شما در ساختار سوم بیان کردید که فایل‌های مربوط به هر قسمت در کنار هم باشند. اعم از کنترلر و دایرکتیوها و فیلترها و ... .
آیا میشود برای هر قسمت مثل product , user ,cart ، یک ماژول app جدا نوشت و در آن طبق مثال شما مسیریابی را تولید کرد؟ یعنی چندین ماژول انگولار app.js برای یک پروژه نوشت؟استاندارد است؟ بدین صورت دیگر نگران تعداد مسیرهای زیاد نیستیم و مشخص میشود که مسیریابی هر قسمت در کنار آن وجود دارد.
امکان پذیر است؟ اگر نیست شما چه راهی برای این کار دارید. ممنون
نظرات مطالب
ASP.NET MVC #11
در قسمت آخر مطلبتون یک ModelBinder  سفارشی برای DateTime نوشته شده که روش خوب و مناسبی هست برای جلوگیری از تکرار کد اضافی. اما یک مشکلی که من دارم اینه این روش شما برای گرفتن اطلاعات از کلاینت درست عمل میکنه اما مشکل اینجاست اگر من بخوام این فیلد تاریخ رو به کاربر نشون بدم چه کاری باید انجام بدم؟یعنی من این فیلد رو از دیتابیس خوندم چطور میشه اونو به مقدار شمسی تبدیل کنم و به کاربر نشون بدم ! چون مقدار تاریخ شمسی برای یک DateTime ‌قابل قبول نیست(راهی ک من برای حل مشکل داشتم این بود که یک فیلد String در viewmodel‌قرار میدادم و مقادیر اونو وقتی اطلاعات از سمت کاربر میومد به مقدار میلادی تبدیل می‌کردم و در فیلد مربوطه قرار میدادم و وقتی اطلاعات رو از دیتابیس لود میکردم مقدار فیلد تاریخ رو به شمسی تبدیل می‌کردم و در فیلد  string میذاشتم.)
نظرات مطالب
چند نکته کاربردی درباره Entity Framework
- سورس آزمایش به عمد ارسال شد، تا بتونید خودتون اجراش کنید و اندازه گیری کنید. این‌ها چشم بندی نبوده یا نظر شخصی نیست. یک سری اندازه گیری است.
- توضیح دادم در انتهای همان آزمایش. برای تکرار مجدد: چون یکبار رفت و برگشت کمتری داره به دیتابیس. چون تغییر State یک شیء و ورود آن به سیستم ردیابی، خیلی سریعتر است از واکشی اطلاعات از بانک اطلاعاتی. اما در مورد لیستی از اشیاء، توسط context.Factors سیستم EF دسترسی به IDها پیدا می‌کنه (در هر دو حالت متصل و منقطع). اگر سیستم ردیابی خاموش شود، برای اتصال مجدد این‌ها زمان خواهد برد (چون IDهای دریافت شده از بانک اطلاعاتی ردیابی نمی‌شوند)، اما در حالت متصل، همان بار اولی که کوئری گرفته شده، همانجا اتصال هم برقرار شده و در حین به روز رسانی اطلاعات می‌داند چه تغییراتی رخ داده و چگونه سریعا باید محاسبات رو انجام بده. اما در حالت منقطع توسط متد DetectChanges تازه شروع به اتصال و محاسبه می‌کند.
نظرات مطالب
معماری لایه بندی نرم افزار #3
شاهین جان، من با حذف لایه مخزن مخالف هستم. زیرا:

ما لایه ای به نام "لایه مخزن" را میسازیم تا در نهایت کلیه متدهایی که برای حرف زدن با داده هامون را نیاز داریم داشته باشیم. حالا این اطلاعات ممکنه از پایگاه داده یا جاهای دیگه جمع آوری بشوند (و الزاما توسط EF قابل دسترسی و ارائه نباشند)

همچنین گاهی نیاز هست که بر مبنای چند متد که EF به ما میرسونه (مثلا چند SP) یک متد کلی‌تر را تعریف کنیم (چند فراخوانی را در یک متد مثلا متد X در لایه مخزن انجام دهیم) و در لایه بالاتر آن متد را صدا بزنیم (بجای نوشتن و تکرار پاپی همه کدهای نوشت شده در متد X)

علاوه بر این در لایه مخزن میشه چند ORM را هم کنار هم دید (نه فقط EF) که همونطور که آقای خوشبخت در کامنت‌ها نوشتند گاهی نیاز میشه.

بنابراین:
من وجود لایه مخزن را ضروری میدونم.

(فراموش نکنیم که هدف از این آموزش تعریف یک الگوی معماری مناسب برای پروژه‌های بزرگ هست و الا بدون خیلی از اینها هم میشه برنامه ساخت. همونطور که اکثرا بدون این ساختارها و خیلی ساده‌تر میسازند)

نظرات مطالب
معماری لایه بندی نرم افزار #3

- من در عمل تفاوتی بین لایه مخزن و سرویس شما مشاهده نمی‌کنم. یعنی لایه مخزن داره GetAll می‌کنه، بعد لایه سرویس هم داره همون رو به یک شکل دیگری بر می‌گردونه. این تکرار کد نیست؟ این دو یکی نیستند؟

عموما در منابع لایه مخزن رو به صورت روکشی برای دستورات مثلا EF یا LINQ to SQL معرفی می‌کنند. فرضشون هم این است که این روش ما رو از تماس مستقیم با ORM برحذر می‌داره (شاید فکر می‌کنند ایدز می‌گیرند اگر مستقیم کار کنند!). ولی عرض کردم این روکش در واقعیت فقط شاید با EF یا L2S قابل تعویض باشه نه با ORMهای دیگر با روش‌های مختلف و بیشتر یک تصور واهی هست که جنبه عملی نداره. بیشتر تئوری هست بدون پایه تجربه دنیای واقعی. ضمن اینکه این روکش باعث میشه نتونید از خیلی از امکانات ORM مورد استفاده درست استفاده کنید. مثلا ترکیب کوئری‌ها یا روش‌های به تاخیر افتاده و امثال این.

- پس در عمل شما Request ViewModel و Response ViewModel تعریف کردید.

نظرات مطالب
با ASP.MVC چه مزایایی را به دست خواهیم آورد
ممنون از راهنمایی شما. هنوز تصمیم قطعی گرفته نشده. در حقیقت چند تستی که در خصوص سیلورلایت انجام دادم کمی من رو ناامید کرد. چون بستر ارتباطی اینترنت و اینترانت هست پس حجم داده‌های ارسال شده به کاربر باید حداقل مقدار ممکن باشد که در مورد سیلورلایت با یک صفحه ساده و 4 عدد کنترل telerik حجم فایل xap به 2 مگ رسد؟! این یعنی فاجعه.
بین سیلورلایت و MVC تردید داشتیم تا حدی جواب سوالم رو گرفتم.
منظورم از سریعتر و راحت‌تر بیشتر تاکید بر روی امکان استفاده مجدد از یک کار تکراری در قسمتهای مختلف برنامه هست. مثلا نمایش لیست مقادیر بر اساس خصوصیات یک یا چند entity با شرطی خاص که ممکن هست بارها بارها در صفحات تکرار بشه. نگرانی من بیشتر در خصوص حذف کارهای تکراری برای برنامه نویس‌های معمولی هست.
و هنوز هم شک دارم IIS بتونه 10000 کاربر همزمان رو جوابگو باشه. آیا شما تجربه عملی با این حجم کاربر دارید؟