‫۶ سال و ۵ ماه قبل، شنبه ۱۱ فروردین ۱۳۹۷، ساعت ۱۲:۳۵
- هدف اصلی مطلب جاری، تزریق HttpContext در سرویس‌های برنامه است و نه در کنترلرها. از این جهت که در کنترلرها همیشه توسط this.HttpContext دسترسی به آن وجود دارد و نیازی به تزریق سرویس آن در اینجا نیست.
- در جائیکه دسترسی به this.HttpContext وجود دارد، روش دیگر دسترسی به سرویس‌ها به صورت زیر است (البته همیشه تزریق در سازنده‌ها مقدم هستند؛ مگر در موارد ضروری):
var serviceT = this.HttpContext.RequestServices.GetService<T>();
‫۶ سال و ۵ ماه قبل، پنجشنبه ۹ فروردین ۱۳۹۷، ساعت ۲۲:۵۰
- سطوح بالا و پایین در اینجا بر اساس رابطه‌ی  Presentation Layer-->BLL-->DAL-->Database مشخص می‌شوند (پایین‌ترین سطح بانک اطلاعاتی است و بالاترین سطح، همانی‌است که کاربر با آن تعامل دارد یا لایه‌ی نمایشی). در اینجا DAL بر اساس اینترفیس IUnitOfWork، امکان دسترسی به بانک اطلاعاتی را به صورت کنترل شده، در اختیار BLL (یا همان لایه سرویس در اینجا) قرار می‌دهد (مانند همان IUnitOfWork‌های تزریق شده‌ی در سازنده‌ی کلاس‌های لایه سرویس). سپس BLL هم منطق تجاری تعریف شده‌ی در آن‌را توسط اینترفیس‌هایی در اختیار بالاترین سطح سیستم که لایه نمایش هست (کنترلرها و قسمت MVC)  قرار خواهد داد. پیاده سازی‌های این‌ها هم توسط سیستم تزریق وابستگی‌ها تامین می‌شود و عموما اینترفیس‌های هر لایه هم در همان لایه تعریف می‌شوند و سپس در اختیار لایه‌های بالاتر قرار می‌گیرند. یعنی لایه‌های مختلف از جزئیات پیاده سازی‌های یک‌دیگر مطلع نیستند و فقط با اینترفیس‌ها کار می‌کنند که سهولت نوشتن آزمون‌های واحد را سبب خواهند شد و همچنین امکان تعویض ساده‌تر پیاده سازی‌ها در صورت نیاز، بدون نیاز به تغییرات جزئیات کدنویسی لایه‌ای خاص (اصل باز بودن برای توسعه و بسته بودن برای تغییر).
- همچنین از آنجائیکه ما در یک دنیای محض زندگی نمی‌کنیم، نیاز خواهید داشت از
IUnitOfWork گاهی از اوقات در لایه نمایشی هم استفاده کنید تا بتوانید یک تراکنش حاصل از چند موجودیت و چند کلاس لایه سرویس را در پایان کار درخواست رسیده (فقط یک تراکنش به ازای کل تعاملات یک درخواست)، به بانک اطلاعاتی اعمال کنید. بنابراین internal تعریف کردن آن در دنیای واقعی میسر نیست. حتی برای تعریف سیم‌کشی‌های تزریق وابستگی‌های اولیه‌ی آن هم نباید internal تعریف شود. همچنین باز هم یک برنامه‌ی واقعی الزاما تمام نیازهای تجاری‌اش در لایه سرویس قرار نمی‌گیرد. مثلا نیاز خواهید داشت با میان‌افزارها، اکشن فیلترها و غیره هم کار کنید که این‌ها محل قرارگیری استاندارد و مشخصی ندارند و هر جائی قابل تعریف هستند.
‫۶ سال و ۵ ماه قبل، پنجشنبه ۹ فروردین ۱۳۹۷، ساعت ۱۷:۲۴
لایه سرویس، استفاده کننده‌ی از IUnitOfWork است و امکانات آن‌را پس از کپسوله کردن در اختیار سایر لایه‌های برنامه قرار می‌دهد (اینجا است که معکوس کردن وابستگی‌ها رخ می‌دهد). پیشترها به این لایه‌ها DAL (Data Access Layer) و BLL (Business Logic Layer) گفته می‌شد؛ این لایه‌ها یکی نیستند و در یک سطح قرار نمی‌گیرند. کار لایه DAL، اتصال و کار مستقیم با بانک اطلاعاتی است. خارج از امکانات ارائه شده‌ی توسط این لایه، لایه دیگری حق تعامل مستقیم با بانک اطلاعاتی را ندارد (بنابراین اگر دیدید که Context را مستقیما داخل یک کنترلر (که در لایه نمایشی یا Presentation Layer قرار دارد) فراخوانی کردند، چنین برنامه‌ای لایه بندی صحیحی ندارد؛ کل کنترلرها و ویووهای مرتبط با آن‌ها در لایه نمایشی قرار می‌گیرند. کار الگوی MVC صرفا نظم بخشی به لایه نمایشی است). منطق‌هایی که از DAL برای ارائه‌ی سرویس‌هایی به قسمت‌های مختلف برنامه پیاده سازی می‌شوند، در BLL قرار می‌گیرند و در نهایت جریان اطلاعات در اینجا به این صورت است:
 Presentation Layer-->BLL-->DAL-->Database
برای اطلاعات بیشتر نظرات مطلب «EF Code First #12» را مطالعه کنید.
‫۶ سال و ۶ ماه قبل، دوشنبه ۶ فروردین ۱۳۹۷، ساعت ۲۲:۳۷
در ضمن ویومدل‌ها در لایه سرویس و پروژه دیگری میباشد.

این مورد را باید اضافه کنید تا آن اسمبلی و یا اسمبلی‌های دیگر را هم اسکن کند؛ وگرنه میدان دید scan.TheCallingAssembly فقط محدود به اسمبلی جاری هست:
scan.AssemblyContainingType<SomeTypeInThatAssembly>();
‫۶ سال و ۶ ماه قبل، دوشنبه ۶ فروردین ۱۳۹۷، ساعت ۲۱:۱۶
یک نکته‌ی تکمیلی

قسمت «دریافت فایل PDF» از نکته‌ی «HTML5 download attribute » استفاده می‌کند.
<a href="computer.png" download="PC.png">
  Download File
</a>
- استفاده از ویژگی استاندارد download سبب می‌شود که کاربر بجای مرور آدرس، آن‌را دریافت کند.
- اگر این ویژگی به نامی هم مزین شود، این نام، نام فایل دریافتی خواهد بود.
‫۶ سال و ۶ ماه قبل، شنبه ۴ فروردین ۱۳۹۷، ساعت ۲۳:۲۰
یک نکته‌ی تکمیلی: امضای نگارش‌های Task دار و Async این متدها

در حالت اول، Task فراخوانی شده یک خروجی را باز می‌گرداند و در حالت دوم، خروجی آن void است:
    private async Task<T> doSomethingAsync<T>(Func<Task<T>> task)
    {
        var result = default(T);
        try
        {
            result = await task();
        }
        catch (Exception ex)
        {
            // todo: log
        }
        return result;
    }

    private async Task doSomethingAsync(Func<Task> task)
    {
        await task();
    }
با یک چنین کاربردهای نمونه‌ای
    public async Task ExampleAsync()
    {
        await doSomethingAsync<string>(() => Task.FromResult("...."));
        await doSomethingAsync(() => Task.Delay(1000));
    }
‫۶ سال و ۶ ماه قبل، جمعه ۳ فروردین ۱۳۹۷، ساعت ۱۶:۴۳
یک تاریخچه‌ی ضروری

- این مطلب با مباحث ASP.NET Identity 2.x به طور کامل جایگزین شده‌است.
- ASP.NET Identity 2.x دیگر در فاز توسعه‌ی اصلی قرار ندارد:
Identity 2.0 is no longer under primary development. No new features will be added, only bugs will be considered
 مخزن کد انتقالی آن از CodePlex در اینجا قرار دارد.
- نگارش جدید و فعال آن صرفا ASP.NET Core Identity است و مخزن کد آن هم در اینجا است.