مطالب
انتقال دائمی آدرس ها (Permanent Ridirect) در ASP.NET Webform
یکی از مسائلی که همیشه برای وب سایت، از نظر موتور‌های جستجو بسیار مهم است، مقوله SEO Friendly بودن آدرس‌هاست. خوشبختانه در ASP.NET MVC این مقوله به خوبی پوشش داده شده است. برای مثال این قابلیت در ASP.NET Webforms توسط بسته نرم افزاری به نام ASP.NET FriendlyUrls توسط تیم توسعه دهنده ASP.NET ارائه شده است. در این زمینه قبلا آقای کاویانی در همین سایت در صفحه مروری بر قابلیت جدید ASP.NET FriendlyUrls  به این مقوله پرداخته‌اند و با مثال، نحوه‌ی استفاده از این بسته‌ی نرم افزاری را آموزش داده‌اند.
یکی از مسائلی که در ASP.NET Webforms با آن مواجه بودیم انتقال دائمی آدرس‌های صفحات یا همان Permanent Redirect بود.
در واقع زمانیکه شما در حالت عادی از بسته‌ی نرم افزاری مذکور استفاده می‌کنید، این افزونه باعث SEO Friendly شدن آدرس‌های صفحات شما می‌گردد. با در نظر گرفتن اینکه شما مطلب مروری بر قابلیت جدید ASP.NET FriendlyUrls  را مطالعه کرده اید، به فرض مثال کد زیر:
public static class RouteConfig
    {
        public static void RegisterRoutes(RouteCollection routes)
        {
            routes.EnableFriendlyUrls();
            routes.MapPageRoute("Sitemap", "sitemap.xml", "~/sitemap.aspx");
        }
    }
و رجیستر کردن آن در RouteTable سایت به صورت زیر در فایل Global
protected void Application_Start(object sender, EventArgs e)
{
     RouteConfig.RegisterRoutes(RouteTable.Routes);
}
باعث می‌شود که با زدن آدرس https://www.dntips.ir/sitemap.xml آدرس https://www.dntips.ir/sitemap.aspx لود شود؛ اما در نوار آدرس، همان آدرس sitemap.xml باقی خواهد ماند.
در این روش در صورتیکه کاربر آدرس https://www.dntips.ir/sitemap.aspx را در مرورگر خود تایپ کند باز هم سایت کار می‌کند (آدرس مورد نظر در دسترس است) و فاجعه زمانی شروع می‌شود که موتور جستجو، با محتوی تکراری در سایت در دو آدرس مختلف مواجه شود (پست آقای نصیری را در بهبود SEO در ASP.NET MVC  بررسی کنید) .
یا زمانیکه شما صفحات قدیمی دارید و می‌خواهید آنها را به آدرس‌های جدید منتقل کنید. برای رفع این مشکل طوری‌که هر زمان آدرس قدیمی هم وارد سیستم مسیریابی سایت شود به صورت اتوماتیک به آدرس جدید به صورت دائم منتقل شود، می‌توانید کد بالا را به صورت زیر اصلاح نمایید:
public static void RegisterRoutes(RouteCollection routes)
 {
            routes.EnableFriendlyUrls(new FriendlyUrlSettings()
            {
                AutoRedirectMode = RedirectMode.Permanent,
                ResolverCachingMode = ResolverCachingMode.Dynamic
            });
            routes.MapPageRoute("Sitemap", "sitemap.xml", "~/sitemap.aspx");
}
با این تنظیمات، سیستم مسیریابی ملزم به انتقال دائمی آدرس، به آدرس جدید خواهد شد. یعنی شما حتی اگر آدرس https://www.dntips.ir/sitemap.aspx را وارد نمایید مسیریاب سایت برای آدرس مورد نظر، وضعیت 301 Moved Permanently را مقدار دهی کرده و فقط آدرس https://www.dntips.ir/sitemap.xml به عنوان آدرس اصلی در نظر گرفته خواهد شد.
مطالب
روش‌هایی برای بهبود تجربه‌ی کاربری صفحات لاگین و ثبت نام
عموما زمانیکه به طراحی صفحه‌ی لاگین و یا ثبت نام می‌رسیم، ورودی کلمه‌ی عبور را با "type="password علامتگذاری می‌کنیم و ... همین! فارغ از اینکه در سال‌های اخیر، مرورگرها چه امکانات قابل توجهی را در جهت غنی سازی همین یک ورودی ویژه، تدارک دیده‌اند تا کار ثبت نام و یا ورود به یک سایت و برنامه را ساده‌تر و امن‌تر کنند.


کمک به مرورگر، در جهت تمایز بین صفحات ورود و ثبت نام

مرورگرهای جدید قادرند برای صفحه‌ی لاگین، پر کردن خودکار فیلدهای نام کاربری و کلمه‌ی عبور و برای صفحه‌ی ثبت نام، تولید خودکار کلمات عبور قوی، به همراه به‌خاطر سپاری آن‌را ارائه دهند. برای فعال سازی یک چنین قابلیت‌های ویژه‌ای، نیاز است تا یک سری ویژگی را به فیلدهای ورود کلمات عبور اضافه کرد:
الف) نیاز است autocomplete را به نحو صحیحی مقدار دهی کرد:
- اگر مقدار آن مساوی new-password درنظر گرفته شود، یعنی صفحه‌ی جاری، صفحه‌ی ثبت نام است و نیاز است تا تولید کننده‌ی خودکار کلمات عبور مرورگر و بخاطر سپاری آن فعال شوند.


- اگر مقدار آن مساوی current-password درنظر گرفته شود، یعنی صفحه‌ی جاری، صفحه‌ی لاگین است و کاربر نیاز دارد تا کلمه‌ی عبوری را که پیشتر در حین ثبت نام و یا حتی لاگین موفق قبلی وارد کرده‌است، بتواند به سادگی از طریق password manager مرورگر دریافت کند.


ب) بنابراین تا اینجا روش تمایز بین فیلدهای پسورد صفحات لاگین و ثبت نام مشخص شد. اما در مورد نام کاربری چطور؟
برای این حالت فقط کافی است مقدار autocomplete را به username تنظیم کرد تا مرورگر بداند که چگونه باید اطلاعات password manager خودش را به صورت خودکار تامین کند. البته "autocomplete="username در اصل برای معرفی ایمیل‌ها طراحی شده‌است، اما در استفاده‌های برنامه‌های کاربردی ما، جهت معرفی مقدار نام کاربری که کاربر قرار است توسط آن به برنامه وارد شود، کفایت می‌کند.


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

عنوان شد که اگر مقدار autocomplete در صفحات ثبت نام، به مقدار new-password تنظیم شود، یک چنین فیلد ورودی به صورت خودکار به همراه قابلیت ویژه‌ی «تولید کننده‌ی خودکار کلمات عبور مرورگر» نیز خواهد بود. می‌توان این ابزار توکار مرورگرها را نیز سفارشی سازی کرد و بر روی نحوه‌ی تولید کلمات عبور آن تاثیر گذاشت:
<input type="password" autocomplete="new-password" 
  passwordrules="required: upper; required: lower; required: digit; 
                 minlength: 25; allowed: [-().&@?'#,/&quot;+]; max-consecutive: 2">
برای اینکار از ویژگی passwordrules استفاده می‌شود. برای مثال تنظیمات فوق به این معنا هستند:
- کلمه‌ی عبور تولیدی توسط مرورگر باید حداقل به همراه یک عدد، یک حرف بزرگ و یک حرف کوچک باشد.
- حداقل 25 حرف باشد.
- استفاده‌ی از حروف ویژه‌ی -().&@?'#,/"+ در آن مجاز است.
- حداکثر تعداد حروف مشابه متوالی آن باید 2 حرف باشد.


نیاز به خاموش کردن تصحیح‌های هوشمند مرورگرها

مرورگرها می‌توانند برای مثال حروف ابتدای عبارت وارد شده را به صورت خودکار تبدیل به کلمات بزرگ کنند و یا حتی با استفاده از واژه نامه‌ها، اطلاعات ورودی را تصحیح کنند. یک چنین قابلیتی نباید برای فلیدهای کلمات عبور فعال باشد. به همین جهت ضروری است این فلیدها با ویژگی‌های "autocapitalize="off و "autocorrect="off مزین شوند.


کمک به مرورگرها در جهت تعویض کلمات عبور ضعیف و فاش شده‌!

برای نمونه مرورگر کروم به همراه قسمتی است که بر اساس password manager توکار خودش و اطلاعات فاش شده‌ی بر روی اینترنت، عنوان می‌کند که کدامیک از کلمات عبور شما دیگر امن نیستند و بهتر است آن‌ها را عوض کنید. این صفحه را می‌توانید در آدرس ویژه‌ی chrome://settings/passwords مرورگر کروم مشاهده کنید.


نکته‌ی مهم اینجا است که این مرورگر، دکمه‌ی Change password و لینکی را نیز به سایت و برنامه‌ی مدنظر، برای تعویض کلمه‌ی عبور ارائه می‌دهد و این لینک، قالب ثابت و ویژه‌ای دارد: https://example.com/.well-known/change-password
یعنی هموار کاربر را به آدرس ثابت well-known/change-password. در سایت شما هدایت می‌کند و در این حالت بهتر است یک route ویژه‌ی خاص آن‌را تعریف کرده و کاربر را به صورت خودکار به صفحه‌ی اصلی تعویض کلمه‌ی عبور، برای مثال به آدرس فرضی https://example.com/settings/change-password به صورت خودکار هدایت کنید.

یک نمونه مثال این هدایت خودکار در یک برنامه‌ی ASP.NET Core به صورت زیر است:
app.UseEndpoints(endpoints =>
{
  // TODO: Add it to your app!
  // Improves chrome://settings/passwords page by managing `Change password` button next to a password.
  endpoints.MapGet("/.well-known/change-password",
                   context =>
                   {
                     // `/.well-known/change-password` address will be called by the `Change password` button of the Chrome.
                     // Now our Web-API app redirects the user to the `/change-password` address of the App.
                      context.Response.Redirect("/change-password", true);
                      return Task.CompletedTask;
                    });
  endpoints.MapRazorPages();
  // ...
});
اشتراک‌ها
پیاده سازی websockets در NetCore

تعریف وب سوکت : یه پروتکلی هست بر مبنای TCP که یک ارتباط دو طرفه  بین کلاینت و سرور ایجاد میکنه 
کاربرد وب سوکت : بیشتر در چت و وب کنفرانس‌ها و در برنامه هایی که نیاز به ارتباط تنگاتنگ بین سرور و کلاینت هست یا مثلا تو یه قسمتی از برنامه برای چک کردن پست ، اطلاعیه و پیغام جدید و یا در بازی‌های تحت وب 

تفاوت عمده ای که وب سوکت با HTTP داره در اینه که در HTTP سرور بعد از ارسال response کانکشن موجود رو قطع میکنه ,ولی در وب سوکت بعد از پاسخ سرور کانکشن موجود همچنان برقرار هست و این کمک میکنه که هر وقت دیتای جدیدی بود باز به کلاینت ارسال کنه 



پیاده سازی websockets در NetCore
نظرات مطالب
ASP.NET MVC #13
با سلام آقای نصیری.
حق با شماست ولی نمی‌دانم چرا اسکریپت‌ها درست لود نمی‌شوند.
من هر وقت بر روی لینک اسکریپت‌ها در web developers کلیک میکنم به جای باز کردن محتوای فایل js دوباره همان صفحه لاگین را نشان می‌دهد و آدرسی شبیه این ایجاد می‌کند:
http://localhost:2215/Account/LogOn?ReturnUrl=%2fScripts%2fjquery-1.7.1.js
البته من اعتبارسنجی اجباری در تمام صفحات استفاده کردم:
<authorization>
      <deny users="?" />
    </authorization>
بسیار متشکرم.
نظرات مطالب
طرحبندی صفحات وب با بوت استرپ 4 - قسمت سوم
یک نکته‌ی تکمیلی: معادل‌های pull-left و pull-right بوت استرپ 3 در نگارش 4 آن

بجای pull-right می‌توان از float-right و بجای pull-left از float-left استفاده کرد.
<div class="clearfix">
  <span class="float-left">Float left</span>
  <span class="float-right">Float right</span>
</div>
اگر پاسخ نگرفتید، روش flexbox توضیح داده شده مانند d-flex justify-content-end را آزمایش کنید.
<div class="col-lg-6 d-flex justify-content-end">
روش دیگر آن استفاده از auto margins است؛ مانند ml-auto:
<ul class="nav">
   <li><a href class="nav-link">Link</a></li>
   <li><a href class="nav-link">Link</a></li>
   <li class="ml-auto"><a href class="nav-link">Right</a></li>
</ul>
نظرات مطالب
نمایش تعداد کل صفحات در iTextSharp
به این صورت قابل انجام است:
using System;
using System.IO;
using iTextSharp.text;
using iTextSharp.text.pdf;

namespace iTextSharpTests
{
    public class PdfWriterPageEvents : PdfPageEventHelper
    {
        PdfContentByte _pdfContentByte;
        // عدد نهایی تعداد کل صفحات را در این قالب قرار خواهیم داد
        PdfTemplate _template;
        Font _font;
        public override void OnOpenDocument(PdfWriter writer, Document document)
        {
            FontFactory.Register(Environment.GetEnvironmentVariable("SystemRoot") + "\\fonts\\tahoma.ttf");
            _font = FontFactory.GetFont("Tahoma", BaseFont.IDENTITY_H, embedded: true, size: 9);
            _pdfContentByte = writer.DirectContent;
            _template = _pdfContentByte.CreateTemplate(50, 50);
        }

        public override void OnEndPage(PdfWriter writer, Document document)
        {
            base.OnEndPage(writer, document);

            var pageSize = document.PageSize;
            var text = "صفحه " + writer.PageNumber + " از ";
            var textLen = _font.BaseFont.GetWidthPoint(text, _font.Size);
            var center = (pageSize.Left + pageSize.Right) / 2;

            ColumnText.ShowTextAligned(
                _pdfContentByte,
                Element.ALIGN_RIGHT,
                new Phrase(text, _font),
                center,
                pageSize.GetBottom(25),
                0,
                PdfWriter.RUN_DIRECTION_RTL,
                0);

            //در پایان هر صفحه یک جای خالی را مخصوص تعداد کل صفحات رزرو خواهیم کرد
            _pdfContentByte.AddTemplate(_template, center - textLen, pageSize.GetBottom(25));
        }
        public override void OnCloseDocument(PdfWriter writer, Document document)
        {
            base.OnCloseDocument(writer, document);
            _template.BeginText();
            _template.SetFontAndSize(_font.BaseFont, _font.Size);
            _template.SetTextMatrix(0, 0);
            //درج تعداد کل صفحات در تمام قالب‌های اضافه شده
            _template.ShowText((writer.PageNumber - 1).ToString());
            _template.EndText();
        }
    }

    public class AddTotalNoPages
    {
        public static void CreateTestPdf()
        {
            using (var pdfDoc = new Document(PageSize.A4))
            {
                var pdfWriter = PdfWriter.GetInstance(pdfDoc, new FileStream("tpn.pdf", FileMode.Create));
                pdfWriter.PageEvent = new PdfWriterPageEvents();
                pdfDoc.Open();


                pdfDoc.Add(new Phrase("Page1"));
                pdfDoc.NewPage();
                pdfDoc.Add(new Phrase("Page2"));
                pdfDoc.NewPage();
                pdfDoc.Add(new Phrase("Page3"));
            }

            System.Diagnostics.Process.Start("tpn.pdf");
        }
    }
}

نظرات مطالب
تغییرات بوجود آمده در Bundling and Minification -MVC4
در مورد سرعت صفحه عنوان کرده و گفته ممکن است URLهای دارای کوئری استرینگ در بعضی از کش سرورها، کش نشوند. این مورد قابل اندازه گیری و بررسی است. یعنی مطلب فوق صرفا یک حدس و گمان است که ممکن است درست باشد یا خیر.

نظرات مطالب
Protocol Buffers فرمتی برای تبادل دیتا
چند تا مساله را میگم و دیگه این بحث رو ادامه نمیدم به هیچ وجه (چون مساله‌ی مطرح شده هیچ ربطی به این مقاله‌ی خاص نداره و فقط چون این وبسایت بازدید کننده‌ی زیادی داره مجبورم کامل توضیح بدم که ما اشتباها خط غلط به کسی ندیم و گمراه نکنیم کسی رو ناخواسته)
1) موضوع این مقاله فقط و فقط protocol buffers بود و هیچ ربطی به هیچ زبان برنامه نویسی نداشت و وارد شدن به این مساله در اینجا اشتباه است، من حتی در این مقاله توضیح ندادم که با استفاده از grpc و protobuf مستقیما نمیتونیم از طریق browser درخواست بدیم، و وارد کردن این مساله و همینطور لایبری‌های مختلف جاوا اسکریپتی و سی شارپی جایگاهش در این نقاله نبود چون نگاه خیلی بالاتر از این بود تا اینکه به سطح بیاییم و بخواهیم راجع به یک کتابخونه خاص و یک زبان خاص و مقایسه بین آنها رو انجام بدیم!
2) از اینجا میتونید مشاهد کنید که حداقل به صورت رسمی (اینکه توی گوگل سرچ زده بشه و اولین نتیجه به عنوان سند در پاسخ داده بشه مورد قبول نیست، چون قطعا ممکنه به صورت غیر رسمی ابزار هایی باشه که مورد قبول در تولید یک سیستم روی پروداکشن نیست!) زبان‌های swift, rust , ... هنوز به صورت رسمی ساپورت نمیشند! پس اگر نگاهمون به عنوان توسعه دهنده فراتر از یک مثال hello-world باشه باید اینو مد نظر بگیریم.
3) تکنولوژی باید به ساختار و سیستم ما کمک کنه نه اینکه خودش bottleneck سیستم بشه، تکنولوژی جذابه ولی نکته‌ی مهم اینه که ما اول از همه به این مساله دقت کنیم که باید به عنوان برنامه نویس روی تکنولوژی سوار باشیم نه برعکس (بزرگترین مشکل وقتی پیش میاد که هیجان زده ابزارو تکنولوژی جدید آشنا بشیم و بخواهیم در سیستم استفاده کنیم! هیجان بیش از حد قاتل سسیستمه) با انتخاب اشتباهمون کل سازمان رو دچار مشکل نکنیم، مخصوصل وقتی با یک تکنولوژی آشنا میشیم وفور لایبری‌های مختلف نباید ما رو گمراه کنه!
4) وقتی دیدتون به عنوان توسعه دهنده از مونولوتیک خارج میشه و به مایکروسرویس نگاه میکنید حتما باید از زاویه‌ی خیلی بالاتری نگاه کنید، جایی که توقع میره همه‌ی سیستم بتونه به همدیگه به بهترین نحو بدون مشکل کار کنه پس انتخاب ابزار خیلی اهمیتش بالاتره از تکنولوژی جدید که شاید تازه هم باهاش آشنا شده باشید، api-gateway  به عنوان یک اصل برای معماری ماکروسرویس پذیرفته شده و حتی خیلی توصیه میشه
5) نگاه به سیستم‌های طراحی شده‌ی دنیا هم خیلی بهمون کمک میکنه حتی پروژه‌های بزرگی مثله etcd از gateway استفاده کرده اند چرا که سنگ بزرگ نشانه نزدنه و ریسک تغییرات خیلی بزرگ و بنیادین کل نرم افزار رو به چالش میشکه و علاوه بر اینکه هزینه‌ی زیاد learning curve برای کله تیم داره، ریسک شکست رو هم خیلی بالا میبره، شما فرض کنید که برنامه نویس فرانت اند که تا حالا تو عمرش به غیر از restful api چیز دیگه ای ندیده ناگهان با کلی ابزار جدید آشنا باید بشه که حتی ممکنه رسمی و صد در صد قابل اتکا هم نباشه، این خودش شروع fail شدن یک سیستم رو نتیجه میده!
در مقاله‌ی بعدی سعی میکنم مثال عملی با استفاده از زبان‌های برنامه نویسی مختلف بزنم و توضیحات جزئی‌تری بدم و موارد بیشتر رو فقط و فقط به خواننده که خودش قطعا توسعه دهنده هست و میتونه بالا و پایین رو ببینه میسپارم!
ممنون
مطالب
Globalization در ASP.NET MVC - قسمت پنجم
در قسمت قبل راجع به مدل پیش‌فرض پرووایدر منابع در ASP.NET بحث نسبتا مفصلی شد. در این قسمت تولید یک پرووایدر سفارشی برای استفاده از دیتابیس به جای فایل‌های resx. به عنوان منبع نگهداری داده‌ها بحث می‌شود.
قبلا هم اشاره شده بود که در پروژه‌های بزرگ ذخیره تمام ورودی‌های منابع درون فایل‌های resx. بازدهی مناسبی نخواهد داشت. هم‌چنین به مرور زمان و با افزایش تعداد این فایل‌ها، کار مدیریت آن‌ها بسیار دشوار و طاقت‌فرسا خواهد شد. درضمن به‌دلیل رفتار سیستم کشینگ این منابع در ASP.NET، که محتویات کل یک فایل را بلافاصله پس از اولین درخواست یکی از ورودی‌های آن در حافظه سرور کش می‌کند، در صورت وجود تعداد زیادی فایل منبع و با ورودی‌های بسیار، با گذشت زمان بازدهی کلی سایت به شدت تحت تاثیر قرار خواهد گرفت.
بنابراین استفاده از یک منبع مثل دیتابیس برای چنین شرایطی و نیز کنترل مدیریت دسترسی به ورودی‌های آن به صورت سفارشی، می‌تواند به بازدهی بهتر برنامه کمک زیادی کند. درضمن فرایند به‌روزرسانی مقادیر این ورودی‌ها در صورت استفاده از یک دیتابیس می‌تواند ساده‌تر از حالت استفاده از فایل‌های resx. انجام شود.
 
تولید یک پرووایدر منابع دیتابیسی - بخش اول
در بخش اول این مطلب با نحوه پیاده‌سازی کلاس‌های اصلی و اولیه موردنیاز آشنا خواهیم شد. مفاهیم پیشرفته‌تر (مثل کش‌کردن ورودی‌ها و عملیات fallback) و نیز ساختار مناسب جدول یا جداول موردنیاز در دیتابیس و نحوه ذخیره ورودی‌ها برای انواع منابع در دیتابیس در مطلب بعدی آورده می‌شود.
با توجه به توضیحاتی که در قسمت قبل داده شد، می‌توان از طرح اولیه‌ای به صورت زیر برای سفارشی‌سازی یک پرووایدر منابع دیتابیسی استفاده کرد:


اگر مطالب قسمت قبل را خوب مطالعه کرده باشید، پیاده سازی اولیه طرح بالا نباید کار سختی باشد. در ادامه یک نمونه از پیاده‌سازی‌های ممکن نشان داده شده است.
برای آغاز کار ابتدا یک پروژه ClassLibrary جدید مثلا با نام DbResourceProvider ایجاد کنید و ریفرنسی از اسمبلی System.Web به این پروژه اضافه کنید. سپس کلاس‌هایی که در ادامه شرح داده شده‌اند را به آن اضافه کنید.

کلاس DbResourceProviderFactory
همه چیز از یک ResourceProviderFactory شروع می‌شود. نسخه سفارشی نشان داده شده در زیر برای منابع محلی و کلی از کلاس‌های پرووایدر سفارشی استفاده می‌کند که در ادامه آورده شده‌اند.
using System.Web.Compilation;
namespace DbResourceProvider
{
  public class DbResourceProviderFactory : ResourceProviderFactory
  {
    #region Overrides of ResourceProviderFactory
    public override IResourceProvider CreateGlobalResourceProvider(string classKey)
    {
      return new GlobalDbResourceProvider(classKey);
    }
    public override IResourceProvider CreateLocalResourceProvider(string virtualPath)
    {
      return new LocalDbResourceProvider(virtualPath);
    }
    #endregion
  }
}
درباره اعضای کلاس ResourceProviderFactory در قسمت قبل توضیحاتی داده شد. در نمونه سفارشی بالا دو متد این کلاس برای برگرداندن پرووایدرهای سفارشی منابع محلی و کلی بازنویسی شده‌اند. سعی شده است تا نمونه‌های سفارشی در اینجا رفتاری همانند نمونه‌های پیش‌فرض در ASP.NET داشته باشند، بنابراین برای پرووایدر منابع کلی (GlobalDbResourceProvider) نام منبع درخواستی (className) و برای پرووایدر منابع محلی (LocalDbResourceProvider) مسیر مجازی درخواستی (virtualPath) به عنوان پارامتر کانستراکتور ارسال می‌شود.
 
نکته: برای استفاده از این کلاس به جای کلاس پیش‌فرض ASP.NET باید یکسری تنظیمات در فایل کانفیگ برنامه مقصد اعمال کرد که در ادامه آورده شده است.

کلاس BaseDbResourceProvider
برای پیاده‌سازی راحت‌تر کلاس‌های موردنظر، بخش‌های مشترک بین دو پرووایدر محلی و کلی در یک کلاس پایه به صورت زیر قرار داده شده است. این طرح دقیقا مشابه نمونه پیش‌فرض ASP.NET است.
using System.Globalization;
using System.Resources;
using System.Web.Compilation;
namespace DbResourceProvider
{
  public abstract class BaseDbResourceProvider : IResourceProvider
  {
    private DbResourceManager _resourceManager;
    protected abstract DbResourceManager CreateResourceManager();
    private void EnsureResourceManager()
    {
      if (_resourceManager != null) return;
      _resourceManager = CreateResourceManager();
    }
    #region Implementation of IResourceProvider
    public object GetObject(string resourceKey, CultureInfo culture)
    {
      EnsureResourceManager();
      if (_resourceManager == null) return null;
      if (culture == null) culture = CultureInfo.CurrentUICulture;
      return _resourceManager.GetObject(resourceKey, culture);
    }
    public virtual IResourceReader ResourceReader { get { return null; } }
    #endregion
  }
}
کلاس بالا چون یک کلاس صرفا پایه است بنابراین به صورت abstract تعریف شده است. در این کلاس، از نمونه سفارشی DbResourceManager برای بازیابی داده‌ها از دیتابیس استفاده شده است که در ادامه شرح داده شده است.
در اینجا، از متد CreateResourceManager برای تولید نمونه مناسب از کلاس DbResourceManager استفاده می‌شود. این متد به صورت abstract و protected تعریف شده است بنابراین پیاده‌سازی آن باید در کلاس‌های مشتق شده که در ادامه آورده شده‌اند انجام شود.
در متد EnsureResourceManager کار بررسی نال نبودن resouceManager_ انجام می‌شود تا درصورت نال بودن آن، بلافاصله نمونه‌ای تولید شود.

نکته: ازآنجاکه نقطه آغازین فرایند یعنی تولید نمونه‌ای از کلاس DbResourceProviderFactory توسط خود ASP.NET انجام خواهد شد، بنابراین مدیریت تمام نمونه‌های ساخته شده از کلاس‌هایی که در این مطلب شرح داده می‌شوند درنهایت عملا برعهده ASP.NET است. در ASP.NET درطول عمر یک برنامه تنها یک نمونه از کلاس Factory تولید خواهد شد، و متدهای موجود در آن در حالت عادی تنها یکبار به ازای هر منبع درخواستی (کلی یا محلی) فراخوانی می‌شوند. درنتیجه به ازای هر منبع درخواستی (کلی یا محلی) هر یک از کلاس‌های پرووایدر منابع تنها یک‌بار نمونه‌سازی خواهد شد. بنابراین بررسی نال نبودن این متغیر و تولید نمونه‌ای جدید تنها در صورت نال بودن آن، کاری منطقی است. این نمونه بعدا توسط ASP.NET به ازای هر منبع یا صفحه درخواستی کش می‌شود تا در درخواست‌های بعدی تنها از این نسخه کش‌شده استفاده شود.

در متد GetObject نیز کار استخراج ورودی منابع انجام می‌شود. ابتدا با استفاده از متد EnsureResourceManager از وجود نمونه‌ای از کلاس DbResourceManager اطمینان حاصل می‌شود. سپس درصورتی‌که مقدار این کلاس همچنان نال باشد مقدار نال برگشت داده می‌شود. این حالت وقتی پیش می‌آید که نتوان با استفاده از داده‌های موجود نمونه‌ای مناسب از کلاس DbResourceManager تولید کرد.
سپس مقدار کالچر ورودی بررسی می‌شود و درصورتی‌که نال باشد مقدار کالچر UI ثرد جاری که در CultureInfo.CurrentUICulture قرار دارد برای آن درنظر گرفته می‌شود. درنهایت با فراخوانی متد GetObject از DbResourceManager تولیدی برای کلید و کالچر مربوطه کار استخراج ورودی درخواستی پایان می‌پذیرد.
پراپرتی ResourceReader در این کلاس به صورت virtual تعریف شده است تا بتوان پیاده‌سازی مناسب آن را در هر یک از کلاس‌های مشتق‌شده اعمال کرد. فعلا برای این کلاس پایه مقدار نال برگشت داده می‌شود.

کلاس GlobalDbResourceProvider
برای پرووایدر منابع کلی از این کلاس استفاده می‌شود. نحوه پیاده‌سازی آن نیز دقیقا همانند طرح نمونه پیش‌فرض ASP.NET است.
using System;
using System.Resources;
namespace DbResourceProvider
{
  public class GlobalDbResourceProvider : BaseDbResourceProvider
  {
    private readonly string _classKey;
    public GlobalDbResourceProvider(string classKey)
    {
      _classKey = classKey;
    }
    #region Implementation of BaseDbResourceProvider
    protected override DbResourceManager CreateResourceManager()
    {
      return new DbResourceManager(_classKey);
    }
    public override IResourceReader ResourceReader
    {
      get { throw new NotSupportedException(); }
    }
    #endregion
  }
}
GlobalDbResourceProvider از کلاس پایه‌ای که در بالا شرح داده شد مشتق شده است. بنابراین تنها بخش‌های موردنیاز یعنی متد CreateResourceManager و پراپرتی ResourceReader در این کلاس پیاده‌سازی شده است.
در اینجا نمونه مخصوص کلاس ResourceManager (همان DbResourceManager) با توجه به نام فایل مربوط به منبع کلی تولید می‌شود. نام فایل در اینجا همان چیزی است که در دیتابیس برای نام منبع مربوطه ذخیره می‌شود. ساختار آن بعدا بحث می‌شود.
همان‌طور که می‌بینید برای پراپرتی ResourceReader خطای عدم پشتیبانی صادر می‌شود. دلیل آن در قسمت قبل و نیز به‌صورت کمی دقیق‌تر در ادامه آورده شده است.

کلاس LocalDbResourceProvider
برای منابع محلی نیز از طرحی مشابه نمونه پیش‌فرض ASP.NET که در قسمت قبل نشان داده شد، استفاده شده است.
using System.Resources;
namespace DbResourceProvider
{
  public class LocalDbResourceProvider : BaseDbResourceProvider
  {
    private readonly string _virtualPath;
    public LocalDbResourceProvider(string virtualPath)
    {
      _virtualPath = virtualPath;
    }
    #region Implementation of BaseDbResourceProvider
    protected override DbResourceManager CreateResourceManager()
    {
      return new DbResourceManager(_virtualPath);
    }
    public override IResourceReader ResourceReader
    {
      get { return new DbResourceReader(_virtualPath); }
    }
    #endregion
  }
}
این کلاس نیز از کلاس پایه‌ای BaseDbResourceProvider مشتق شده و پیاده‌سازی‌های مخصوص منابع محلی برای متد CreateResourceManager و پراپرتی ResourceReader در آن انجام شده است.
در متد CreateResourceManager کار تولید نمونه‌ای از DbResourceManager با استفاده از مسیر مجازی صفحه درخواستی انجام می‌شود. این فرایند شبیه به پیاده‌سازی پیش‌فرض ASP.NET است. در واقع در پیاده‌سازی جاری، نام منابع محلی همنام با مسیر مجازی متناظر آن‌ها در دیتابیس ذخیره می‌شود. درباره ساختار جدول دیتابیس بعدا بحث می‌شود.
در این کلاس کار بازخوانی کلیدهای موجود برای پراپرتی‌های موجود در یک صفحه از طریق نمونه‌ای از کلاس DbResourceReader انجام شده است. شرح این کلاس در ادامه آمده است. 

نکته: همانطور که در قسمت قبل هم اشاره کوتاهی شده بود، از خاصیت ResourceReader در پرووایدر منابع برای تعیین تمام پراپرتی‌های موجود در منبع استفاده می‌شود تا کار جستجوی کلیدهای موردنیاز در عبارات بومی‌سازی ضمنی برای رندر صفحه وب راحت‌تر انجام شود. بنابراین از این پراپرتی تنها در پرووایدر منابع محلی استفاده می‌شود. ازآنجاکه در عبارات بومی‌سازی ضمنی تنها قسمت اول نام کلید ورودی منبع آورده می‌شود، بنابراین قسمت دوم (و یا قسمت‌های بعدی) کلید موردنظر که همان نام پراپرتی کنترل متناظر است از جستجو میان ورودی‌های یافته شده توسط این پراپرتی بدست می‌آید تا ASP.NET بداند که برای رندر صفحه چه پراپرتی‌هایی نیاز به رجوع به پرووایدر منبع محلی مربوطه دارد (برای آشنایی بیشتر با عبارت بومی‌سازی ضمنی رجوع شود به قسمت قبل).

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

کلاس DbResourceManager
کار اصلی مدیریت و بازیابی ورودی‌های منابع از دیتابیس از طریق کلاس DbResourceManager انجام می‌شود. نمونه‌ای بسیار ساده و اولیه از این کلاس را در زیر مشاهده می‌کنید:
using System.Globalization;
using DbResourceProvider.Data;
namespace DbResourceProvider
{
  public class DbResourceManager
  {
    private readonly string _resourceName;
    public DbResourceManager(string resourceName)
    {
      _resourceName = resourceName;
    }
    public object GetObject(string resourceKey, CultureInfo culture)
    {
      var data = new ResourceData();
      return data.GetResource(_resourceName, resourceKey, culture.Name).Value;
    }
  }
}
کار استخراج ورودی‌های منابع با استفاده از نام منبع درخواستی در این کلاس مدیریت خواهد شد. این کلاس با استفاده نام منیع درخواستی به عنوان پارامتر کانستراکتور ساخته می‌شود. با استفاده از متد GetObject که نام کلید ورودی موردنظر و کالچر مربوطه را به عنوان پارامتر ورودی دریافت می‌کند فرایند استخراج انجام می‌شود.
برای کپسوله‌سازی عملیات از کلاس جداگانه‌ای (ResourceData) برای تبادل با دیتابیس استفاده شده است. شرح بیشتر درباره این کلاس و نیز پیاده سازی کامل‌تر کلاس DbResourceManager به همراه مدیریت کش ورودی‌های منابع و نیز عملیات fallback در مطلب بعدی آورده می‌شود.

کلاس DbResourceReader
این کلاس که درواقع پیاده‌سازی اینترفیس IResourceReader است برای یافتن تمام کلیدهای تعریف شده برای یک منبع به‌کار می‌رود، پیاده‌سازی آن نیز به صورت زیر است:
using System.Collections;
using System.Resources;
using System.Security;
using DbResourceProvider.Data;
namespace DbResourceProvider
{
  public class DbResourceReader : IResourceReader
  {
    private readonly string _resourceName;
    private readonly string _culture;
    public DbResourceReader(string resourceName, string culture = "")
    {
      _resourceName = resourceName;
      _culture = culture;
    }
    #region Implementation of IResourceReader
    public void Close() { }
    public IDictionaryEnumerator GetEnumerator()
    {
      return new DbResourceEnumerator(new ResourceData().GetResources(_resourceName, _culture));
    }
    #endregion
    #region Implementation of IEnumerable
    IEnumerator IEnumerable.GetEnumerator()
    {
      return GetEnumerator();
    }
    #endregion
    #region Implementation of IDisposable
    public void Dispose()
    {
      Close();
    }
    #endregion
  }
}
این کلاس تنها با استفاده از نام منبع و عنوان کالچر موردنظر کار بازخوانی ورودی‌های موجود را انجام می‌دهد.
تنها نکته مهم در کد بالا متد GetEnumerator است که نمونه‌ای از اینترفیس IDictionaryEnumerator را برمی‌گرداند. در اینجا از کلاس DbResourceEnumerator که برای کار با دیتابیس طراحی شده، استفاده شده است. همانطور که قبلا هم اشاره شده بود، هر یک از اعضای این enumerator از نوع DictionaryEntry هستند که یک struct است. این کلاس در ادامه شرح داده شده است.
متد Close برای بستن و از بین بردن منابعی است که در تهیه enumerator موردبحث نقش داشته‌اند. مثل منایع شبکه‌ای یا فایلی که باید قبل از اتمام کار با این کلاس به صورت کامل بسته شوند. هرچند در نمونه جاری چنین موردی وجود ندارد و بنابراین این متد بلااستفاده است.
در کلاس فوق نیز برای دریافت اطلاعات از ResourceData استفاده شده است که بعدا به همراه ساختار مناسب جدول دیتابیس شرح داده می‌شود.
 
نکته: دقت کنید که در پیاده‌سازی نشان داده شده برای کلاس LocalDbResourceProvider برای یافتن ورودی‌های موجود از مقدار پیش‌فرض (یعنی رشته خالی) برای کالچر استفاده شده است تا از ورودی‌های پیش‌فرض که در حالت عادی باید شامل تمام موارد تعریف شده موجود هستند استفاده شود (قبلا هم شرح داده شد که منبع اصلی و پیش‌فرض یعنی همانی که برای زبان پیش‌فرض برنامه درنظر گرفته می‌شود و بدون نام کالچر مربوطه است، باید شامل حداکثر ورودی‌های تعریف شده باشد. منابع مربوطه به سایر کالچرها می‌توانند همه این ورودی‌های تعریف‌شده در منبع اصلی و یا قسمتی از آن را شامل شوند. عملیات fallback تضمین می‌دهد که درنهایت نزدیک‌ترین گزینه متناظر با درخواست جاری را برگشت دهد).
 
کلاس DbResourceEnumerator
کلاس دیگری که در اینجا استفاده شده است، DbResourceEnumerator است. این کلاس در واقع پیاده سازی اینترفیس IDictionaryEnumerator است. محتوای این کلاس در زیر آورده شده است:
using System.Collections;
using System.Collections.Generic;
using DbResourceProvider.Models;
namespace DbResourceProvider
{
  public sealed class DbResourceEnumerator : IDictionaryEnumerator
  {
    private readonly List<Resource> _resources;
    private int _dataPosition;
    public DbResourceEnumerator(List<Resource> resources)
    {
      _resources = resources;
      Reset();
    }
    public DictionaryEntry Entry
    {
      get
      {
        var resource = _resources[_dataPosition];
        return new DictionaryEntry(resource.Key, resource.Value);
      }
    }
    public object Key { get { return Entry.Key; } }
    public object Value { get { return Entry.Value; } }
    public object Current { get { return Entry; } }
    public bool MoveNext()
    {
      if (_dataPosition >= _resources.Count - 1) return false;
      ++_dataPosition;
      return true;
    }
    public void Reset()
    {
      _dataPosition = -1;
    }
  }
}
تفاوت این اینترفیس با اینترفیس IEnumerable در سه عضو اضافی است که برای استفاده در سیستم مدیریت منابع ASP.NET نیاز است. همان‌طور که در کد بالا مشاهده می‌کنید این سه عضو عبارتند از پراپرتی‌های Entry و Key و Value. پراپرتی Entry که ورودی جاری در enumerator را مشخص می‌کند از نوع DictionaryEntry است. پراپرتی‌های Key و Value هم که از نوع object تعریف شده‌اند برای کلید و مقدار ورودی جاری استفاده می‌شوند.
این کلاس لیستی از Resource به عنوان پارامتر کانستراکتور برای تولید enumerator دریافت می‌کند. کلاس Resource مدل تولیدی از ساختار جدول دیتابیس برای ذخیره ورودی‌های منابع است که در مطلب بعدی شرح داده می‌شود. بقیه قسمت‌های کد فوق هم پیاده‌سازی معمولی یک enumerator است.

نکته: به جای تعریف کلاس جداگانه‌ای برای enumerator اینترفیس IResourceProvider می‌توان از enumerator کلاس‌هایی که IDictionary را پیاده‌سازی کرده‌اند نیز استفاده کرد، مانند کلاس <Dictionary<object,object یا ListDictionary.
 
تنظیمات فایل کانفیگ
برای اجبار کردن ASP.NET به استفاده از Factory موردنظر باید تنظیمات زیر را در فایل web.config اعمال کرد:
<system.web>
    ...
    <globalization resourceProviderFactoryType=" نام کامل اسمبلی مربوطه ,نام پرووایدر فکتوری به همراه فضای نام آن " />
    ...
</system.web>
روش نشان داده شده در بالا حالت کلی تعریف و تنظیم یک نوع داده در فایل کانفیگ را نشان می‌دهد. درباره نام کامل اسمبلی در اینجا شرح داده شده است.
مثلا برای پیاده‌سازی نشان داده شده در این مطلب خواهیم داشت:
<globalization resourceProviderFactoryType="DbResourceProvider.DbResourceProviderFactory, DbResourceProvider" />

در مطلب بعدی درباره ساختار مناسب جدول یا جداول دیتابیس برای ذخیره ورودهای منابع و نیز پیاده‌سازی کامل‌تر کلاس‌های مورداستفاده بحث خواهد شد.

منابع: