.NET Tips | جستجوها: نتایج مشابه «غیرفعال سازی کش مرورگر در مورد تصاویر ایستا»، صفحه: ۱۰۰

مطالب

بررسی تصویر امنیتی (Captcha) سایت - قسمت اول

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

تصویر آشنای کاربران سایت برای ورود به قسمت مدیریت که در صفحه مورد نظر از تصویر امنیتی استفاده شده است:

با توجه به آدرس لینک تصویر مشخص است که برای تولید این تصویر از هندلر استفاده شده و با توجه به پارامترهایی که به آن داده شده تصویر مورد نظر را ایجاد میکند و با فرمت مشخصی بر میگرداند:

https://www.dntips.ir
/CaptchaImage/Show?
text=H2yL5iOXIuu0dsBvu%2F405AnXkeacis3dMQ%2FHXAH8h4A%2BjwDM0f7%2FRZMHvBG5pXYJ
&foreColor=%231B0172
&fontSize=12
&fontName=Tahoma

پارامتر‌های پاس داده شده به ترتیب ذیل برای اهدافی قرار داده شده اند:

نام	مورد استفاده	مقدار
text	متنی که بصورت کد شده حاوی متن مورد استفاده تصویر امنیتی است	H2yL5iOXIuu0dsBvu%2F405AnXkeacis3dMQ%2FHXAH8h4A%2BjwDM0f7%2FRZMHvBG5pXYJ
foreColor	رنگ مربوط به نوشته‌های تصویر	%231B0172
fontSize	سایز فونت	12
fontName	نام فونت	Tahoma

بنظر اهم پارامتر مورد نیاز همان متن است که بصورت کد شده در بالا به آن اشاره شد. برای این منظور باید کلاسی تهیه شود که حاوی متدهای:
1- انتخاب یه عدد تصادفی از بین دامنه ای که به آن داده میشود.
    برای مثال یه عد از بین 100 تا 9999 که بصورت تصادفی انتخاب میشود
2- تبدیل به معادل حرفی آن
    برای مثال از عدد "7062" به حروف آن یعنی "هفت هزار و شصت و دو" استخراج شود
3- کد کردن حرف تولید شده
    حرف "هفت هزار و شصت و دو" را کد کرده و بصورت متنی شبیه
    "H2yL5iOXIuu0dsBvu%2F405AnXkeacis3dMQ%2FHXAH8h4A%2BjwDM0f7%2FRZMHvBG5pXYJ "
    تبدیل کند
4- دیکد کردن و استخراج
    البته این مورد با توجه به استفاده ای که ما داریم نیازی به پیاده سازی نیست

در کنار تصوریر امنیتی از یک فیلد مخفی نیز برای نگهداری مقدار کد شده برای مقایسه با ورودی کاربر استفاده شده که در قسمت بعد ضمن ایجاد نمونه کاربردی بیشتر با قسمتهای مختلف آن آشنا میشویم.

‫۱۱ سال و ۱۲ ماه قبل، دوشنبه ۲۹ آبان ۱۳۹۱، ساعت ۰۱:۰۰

علیرضا نعیمی

نظرات مطالب

ارتقاء به ASP.NET Core 1.0 - قسمت 15 - بررسی تغییرات Caching

توی متد DisableBrowserCache به همون صورت هست که گفتید، ولی در خروجی فقط مقدار "no-cache" نمایش داده میشه. مقدار Expires رو هم تغییر دادم ولی باز در خروجی -1 نمایش داده شد. هر بار هم متد DisableBrowserCache اجرا میشه. مقدار Order فیلتر رو بصورت منفی هم تنظیم کردم ولی فایده ای نداشت. داره از جای دیگه تنظیم میشه. بیس پروژه هم DNTIdentity هست.

‫۶ سال و ۸ ماه قبل، جمعه ۲۷ بهمن ۱۳۹۶، ساعت ۱۸:۳۹

وحید نصیری

نظرات مطالب

جلوگیری از ارسال Spam در ASP.NET MVC

با تشکر از شما. چند نکته از لاگ‌های استخراج شده‌ی سایت جاری:
- این برنامه‌ها، user agent‌های متفاوتی را به ازای هر درخواست ارسال می‌کنند (عموما). بنابراین مورد دوم هم علاوه بر مورد سوم نباید بکار گرفته شود.
- دو نوع هش در حالت کلی وجود دارند. هش‌های سریع و هش‌های امن. هش‌های امن سعی می‌کنند این تضمین را ارائه دهند که به ازای یک ورودی مشخص، خروجی منحصربفردی را تولید کنند؛ اما ... با قیمت کندتر بودن عملیات هش. هش‌های سریع، مانند xxHash، برای یک چنین مواردی که نیاز هست کلید کش تولید شود بکار گرفته می‌شوند. الزاما مانند هش‌های امن سعی در تولید خروجی‌های منحصربفردی نمی‌کنند، اما تا این اندازه دقیق هستند که در بانک‌های اطلاعاتی key-value store فوق سریعی مانند Redis از آن‌ها استفاده می‌شود. بنابراین در یک چنین مواردی مانند سناریوی جاری بهتر است از هش‌های سریع استفاده شود. البته اگر آدرس صفحه و همچنین UA را حذف کنیم، نیازی به هش کردن نخواهد بود؛ چون IP را می‌توان بعنوان کلید درنظر گرفت.
- بررسی UA از دیدگاه دیگری به صورت جداگانه می‌تواند مفید باشد. تشخیص بات‌های شناخته شده و بستن دسترسی آن‌ها.

‫۸ سال و ۱۰ ماه قبل، پنجشنبه ۱۹ آذر ۱۳۹۴، ساعت ۱۴:۲۸

محسن نجف زاده

مطالب

Accord.NET #3

در مطلب قبل یک مثال مفهومی درباره کاربرد SVM بیان شد و دیدیم که این الگوریتم، یک روش دودویی است و عموما برای زمانی به کار می‌رود که مجموعه داده ما شامل دو کلاس باشد.
اگر بخواهیم نوع چهار میوه (سیب، گلابی، موز، پرتغال) را که از خط سورتینگ عبور می‌کنند، تشخیص دهیم و یا اینکه بخواهیم تشخیص اعداد دست نویس را داشته باشیم و یا اینکه حتی مطالب این وب سایت را که شامل چندین برچسب هستند، طبقه بندی کنیم، آیا در این تشخیص‌ها SVM به ما کمک می‌کند؟ پاسخ مثبت است.
در فضای نام یادگیری ماشین Accord.NET دو تابع خوب MulticlassSupportVectorLearning و MultilabelSupportVectorMachine برای این گونه از مسائل تعبیه شده است. زمانیکه مسئله‌ی ما شامل مجموعه داده‌هایی بود که در چندین کلاس دسته بندی می‌شوند (مانند دسته بندی میوه، اعداد و ...) روش Multiclass و زمانیکه عناصر مجموعه داده ما به طور جداگانه شامل چندین برچسب باشند (مانند دسته بندی مطالب با داشتن چندین تگ، ...) روش Multilabel ابزار مفیدی خواهند بود. (+)

با توجه به دودویی بودن ماشین بردار پشتیبان، دو استراتژی برای به کارگیری این الگوریتم برای دسته بندی‌های چند کلاسه وجود دارد:

روش یک در مقابل همه - One-against-all : در این روش عملا همان روش دودویی SVM را برای هر یک از کلاس‌ها به صورت جداگانه بررسی می‌کنیم. مثلا برای تشخیص میوه، یک بار دو کلاس سیب و غیر سیب (مابقی) بررسی می‌شوند و به همین ترتیب برای سایر کلاس‌ها و در مجموع صفحات ابرصفحه جدا کننده بین هر کلاس در مقابل سایر کلاس‌ها ایجاد می‌شود.

روش یک در مقابل یک - One-against-one (*) : در این روش هر کلاس، با هر یک از کلاس‌های دیگر به صورت تک تک بررسی می‌شود و صفحات ابرصفحه جدا کننده مابین هر جفت کلاس متفاوت ایجاد می‌شود. (بیشتر در +)

*روش "یک در مقابل یک" یا One-against-one اساس کار دسته بندی MulticlassSupportVectorMachine در فضای نام Accord.MachineLearning است.

یک مثال کاربردی : هدف در این مثال دسته بندی اعداد فارسی به کمک MulticlassSupportVectorMachine است.

به معرفی ابزار کار مورد نیاز می‌پردازیم.

1.مجموعه ارقام دستنویس هدی: مجموعه ارقام دستنویس هدی که اولین مجموعه‌ی بزرگ ارقام دستنویس فارسی است، مشتمل بر ۱۰۲۳۵۳ نمونه دستنوشته سیاه سفید است. این مجموعه طی انجام یک پروژه‏‌ی کارشناسی ارشد درباره بازشناسی فرم‌های دستنویس تهیه شده است. داده‌های این مجموعه از حدود ۱۲۰۰۰ فرم ثبت نام آزمون سراسری کارشناسی ارشد سال ۱۳۸۴ و آزمون کاردانی پیوسته‌‏ی دانشگاه جامع علمی کاربردی سال ۱۳۸۳ استخراج شده است. (اطلاعات بیشتر درباره مجموعه ارقام دستنویس هدی) .

تعداد 1000 نمونه (از هر عدد 100 نمونه) از این مجموعه داده، با فرمت bmp در این پروژه مورد استفاده قرار گرفته که به همراه پروژه در انتهای این مطلب قابل دریافت است.

2.استخراج ویژگی (Feature extraction ) : در بازشناسی الگو و مفاهیم کلاس بندی، یکی از مهمترین گام‌ها، استخراج ویژگی است. ما موظف هستیم تا اطلاعات مناسبی را به عنوان ورودی برای دسته بندی‌مان معرفی نماییم. روش‌های مختلفی برای استخراج ویژگی وجود دارند. ویژگی‌ها به دو دسته‌ی کلی ویژگی‌های ظاهری (Appearance) و ویژگی‌های توصیف کننده ( Descriptive) قابل تقسیم هستند. در تشخیص حروف و اعداد، ویژگی‌هایی مانند شدت نور نقاط (Intensity)، تعداد حلقه بسته، تعداد خطوط راست، تعداد دندانه، تعداد نقطه (برای حروف) و ... در دسته‌ی اول و ویژگی‌هایی مانند شیب خطوط، گرادیان، میزان افت یا شدت نور یک ناحیه، HOG و ... در دسته دوم قرار می‌گیرند. در این مطلب ما تنها از روش شدت نور نقاط برای استخراج ویژگی‌هایمان استفاده کرده‌ایم.
کد زیر با دریافت یک فایل Bitmap، ابتدا ابعاد را به اندازه 32*32 تغییر می‌دهد و سپس آن‌را به صورت یک بردار 1*1024 را بر می‌گرداند:

        //تابع استخراج ویژگی
        private static double[] FeatureExtractor(Bitmap bitmap)
        {
            bitmap = BitmapResizer(bitmap, 32, 32);

            double[] features = new double[32 * 32];
            for (int i = 0; i < 32; i++)
                for (int j = 0; j < 32; j++)
                    features[i * 32 + j] = (bitmap.GetPixel(j, i).R == 255) ? 0 : 1;

            return features;
        }

        //تابع تغییر دهنده ابعاد عکس
        private static Bitmap BitmapResizer(Bitmap bitmap, int width, int height)
        {
            var newbitmap = new Bitmap(width, height);
            using (Graphics g = Graphics.FromImage((Image)newbitmap))
            {
                g.InterpolationMode = System.Drawing.Drawing2D.InterpolationMode.HighQualityBicubic;
                g.DrawImage(bitmap, 0, 0, width, height);
            }
            return newbitmap;
        }

3.ایجاد ورودی‌ها و برچسب : در این مرحله ما باید ورودی‌های دسته بندی SVM را که عملا آرایه‌ای براساس تعداد نمونه‌های مجموعه آموزش (train) است، ایجاد نماییم.

ورودی‌ها (inputs) = با توجه به اینکه تعداد نمونه‌ها 50 مورد از هر عدد (مجموعا 500 نمونه) تعیین شده است و تعداد ویژگی‌های هر نمونه یک بردار با طول 1024 است، ابعاد ماتریس ورودی مان [1024][500] می‌شود.
برچسب‌ها (labels) = تعداد برچسب مسلما به تعداد نمونه هایمان یعنی 500 مورد می‌باشد و مقادیر آن قاعدتا عدد متناظر آن تصویر است.

برای این کار از قطعه کد زیر استفاده می‌کنیم :

            var path = new DirectoryInfo(Directory.GetCurrentDirectory()).Parent.Parent.FullName + @"\dataset\";

            // ایجاد ورودی و برچسب
            int trainingCount = 50;
            double[][] inputs = new double[trainingCount * 10][];
            int[] labels = new int[trainingCount * 10];

            var index = 0;
            var filename = "";
            Bitmap bitmap;
            double[] feature;

            for (int number = 0; number < 10; number++)
            {
                for (int j = 0; j < trainingCount; j++)
                {
                    index = (number * trainingCount) + j;
                    filename = string.Format(@"{0}\{0} ({1}).bmp", number, j + 1);
                    bitmap = new Bitmap(path + filename);

                    feature = FeatureExtractor(bitmap);

                    inputs[index] = feature;
                    labels[index] = number;

                    Console.WriteLine(string.Format("{0}.Create input and label for number {1}", index, number));
                }
            }

4.در نهایت به دسته بندمان که همان MulticlassSupportVectorLearning است، خواهیم رسید. همانطور که در مطلب قبل مطرح شد، پس از تعریف پارامترهای Classifier مان، باید آن را به یک الگوریتم یادگیری که در اینجا هم همان روش SMO است، نسبت دهیم.

        private static double MachineLearning(IKernel kernel, double[][] inputs, int[] labels)
        {
            machine_svm = new MulticlassSupportVectorMachine(1024, kernel, 10);

            // معرفی دسته بندمان به الگوریتم یادگیری SMO
            MulticlassSupportVectorLearning ml = new MulticlassSupportVectorLearning(machine_svm, inputs, labels)
            {
                Algorithm = (svm, classInputs, classOutputs, i, j) => 
                    new SequentialMinimalOptimization(svm, classInputs, classOutputs)
            };

            var error = ml.Run();
            return error;
        }

می‌توانیم پس از اینکه ماشین دسته بندمان آماده شد، برای آزمایش تعدادی از نمونه‌های جدید و دیده نشده (UnSeen) را که در نمونه‌های آموزشی وجود نداشتند، مورد ارزیابی قرار دهیم. برای این کار اعداد 0 تا 9 از مجموعه داده مان را در نظر می‌گیریم و به وسیله کد زیر نتایج را مشاهده می‌کنیم :

            // بررسی یک دسته از ورودی‌ها 
            index = 51;
            for (int number = 0; number < 10; number++)
            {
                filename = string.Format(@"{0}\{0} ({1}).bmp", number, index);
                bitmap = new Bitmap(path + filename);

                feature = FeatureExtractor(bitmap);

                double[] responses;
                int recognizednumber = machine_svm.Compute(feature, out responses);

                Console.WriteLine
                (
                    String.Format
                    (
                        "Recognized number for file {0} is : '{1}' [{2}]",
                        filename,
                        recognizednumber,
                        (recognizednumber == number ? "OK" : "Error")
                    )
                );
                if (!machine_svm.IsProbabilistic)
                {
                    // Normalize responses
                    double max = responses.Max();
                    double min = responses.Min();

                    responses = Accord.Math.Tools.Scale(min, max, 0, 1, responses);
                    //int minIndex = Array.IndexOf(responses, 0);              
                }
            }

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

همانطور که دیدیم SVM گزینه‌ی بسیار مناسبی برای طبقه بندی خیلی از مسائل دو کلاسه و یا حتی چند کلاسه است. اما آکورد دات نت Classifier‌های خوب دیگری (مانند Naive Bayes و Decision Trees یا درخت تصمیم و ... ) را نیز در چارچوب خود جای داده که در مطالب آینده معرفی خواهند شد.

دریافت پروژه

‫۹ سال و ۲ ماه قبل، چهارشنبه ۱۱ شهریور ۱۳۹۴، ساعت ۰۳:۲۰

وحید نصیری

مطالب

EF Code First #2

در قسمت قبل با تنظیمات و قراردادهای ابتدایی EF Code first آشنا شدیم، هرچند این تنظیمات حجم کدنویسی ابتدایی راه اندازی سیستم را به شدت کاهش می‌دهند، اما کافی نیستند. در این قسمت نگاهی سطحی و مقدماتی خواهیم داشت بر امکانات مهیا جهت تنظیم ویژگی‌های مدل‌های برنامه در EF Code first.

تنظیمات EF Code first توسط اعمال متادیتای خواص

اغلب متادیتای مورد نیاز جهت اعمال تنظیمات EF Code first در اسمبلی System.ComponentModel.DataAnnotations.dll قرار دارند. بنابراین اگر مدل‌های خود را در اسمبلی و پروژه class library جداگانه‌ای تعریف و نگهداری می‌کنید (مثلا به نام DomainClasses)، نیاز است ابتدا ارجاعی را به این اسمبلی به پروژه جاری اضافه نمائیم. همچنین تعدادی دیگر از متادیتای قابل استفاده در خود اسمبلی EntityFramework.dll قرار دارند. بنابراین در صورت نیاز باید ارجاعی را به این اسمبلی نیز اضافه نمود.
همان مثال قبل را در اینجا ادامه می‌دهیم. دو کلاس Blog و Post در آن تعریف شده (به این نوع کلاس‌ها POCO – the Plain Old CLR Objects نیز گفته می‌شود)، به همراه کلاس Context که از کلاس DbContext مشتق شده است. ابتدا دیتابیس قبلی را دستی drop کنید. سپس در کلاس Blog، خاصیت public int Id را مثلا به public int MyTableKey تغییر دهید و پروژه را اجرا کنید. برنامه بلافاصله با خطای زیر متوقف می‌شود:

One or more validation errors were detected during model generation:
\tSystem.Data.Entity.Edm.EdmEntityType: : EntityType 'Blog' has no key defined.

زیرا EF Code first در این کلاس خاصیتی به نام Id یا BlogId را نیافته‌است و امکان تشکیل Primary key جدول را ندارد. برای رفع این مشکل تنها کافی است ویژگی Key را به این خاصیت اعمال کنیم:

using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;

namespace EF_Sample01.Models
{
    public class Blog
    {
        [Key]
        public int MyTableKey { set; get; }

همچنین تعدادی ویژگی دیگر مانند MaxLength و Required را نیز می‌توان بر روی خواص کلاس اعمال کرد:

using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;

namespace EF_Sample01.Models
{
    public class Blog
    {
        [Key]
        public int MyTableKey { set; get; }

        [MaxLength(100)]
        public string Title { set; get; }

        [Required]
        public string AuthorName { set; get; }

        public IList<Post> Posts { set; get; }        
    }
}

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

CREATE TABLE [dbo].[Blogs](
 [MyTableKey] [int] IDENTITY(1,1) NOT NULL,
 [Title] [nvarchar](100) NULL,
 [AuthorName] [nvarchar](max) NOT NULL,
 CONSTRAINT [PK_Blogs] PRIMARY KEY CLUSTERED 
(
 [MyTableKey] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, 
IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

همانطور که ملاحظه می‌کنید در اینجا طول فیلد Title به 100 تنظیم شده است و همچنین فیلد AuthorName اینبار NOT NULL است. به علاوه primary key نیز بر اساس ویژگی Key اعمالی تعیین شده است.
البته برای اجرای کدهای تغییر کرده مدل، فعلا بانک اطلاعاتی قبلی را دستی می‌توان حذف کرد تا بتوان به ساختار جدید رسید. در مورد جزئیات مبحث DB Migration در قسمت‌های بعدی مفصلا بحث خواهد شد.

ب) اعتبار سنجی اطلاعات پیش از ارسال کوئری به بانک اطلاعاتی
برای مثال اگر در حین تعریف وهله‌ای از کلاس Blog، خاصیت AuthorName مقدار دهی نگردد، پیش از اینکه رفت و برگشتی به بانک اطلاعاتی صورت گیرد، یک validation error را دریافت خواهیم کرد. یا برای مثال اگر طول اطلاعات خاصیت Title بیش از 100 حرف باشد نیز مجددا در حین ثبت اطلاعات، یک استثنای اعتبار سنجی را مشاهده خواهیم کرد. البته امکان تعریف پیغام‌های خطای سفارشی نیز وجود دارد. برای این حالت تنها کافی است پارامتر ErrorMessage این ویژگی‌ها را مقدار دهی کرد. برای مثال:

[Required(ErrorMessage = "لطفا نام نویسنده را مشخص نمائید")]
public string AuthorName { set; get; }

نکته‌ی مهمی که در اینجا وجود دارد، وجود یک اکوسیستم هماهنگ و سازگار است. این نوع اعتبار سنجی هم با EF Code first هماهنگ است و هم برای مثال در ASP.NET MVC به صورت خودکار جهت اعتبار سنجی سمت سرور و کلاینت یک مدل می‌تواند مورد استفاده قرار گیرد و مفاهیم و روش‌های مورد استفاده در آن نیز یکی است.

تنظیمات EF Code first به کمک Fluent API

اگر علاقمند به استفاده از متادیتا، جهت تعریف قیود و ویژگی‌های خواص کلاس‌های مدل خود نیستید، روش دیگری نیز در EF Code first به نام Fluent API تدارک دیده شده است. در اینجا امکان تعریف همان ویژگی‌ها توسط کدنویسی نیز وجود دارد، به علاوه اعمال قیود دیگری که توسط متادیتای مهیا قابل تعریف نیستند.
محل تعریف این قیود، کلاس Context که از کلاس DbContext مشتق شده است، می‌باشد و در اینجا، کار با تحریف متد OnModelCreating شروع می‌شود:

using System.Data.Entity;
using EF_Sample01.Models;

namespace EF_Sample01
{
    public class Context : DbContext
    {
        public DbSet<Blog> Blogs { set; get; }
        public DbSet<Post> Posts { set; get; }

        protected override void OnModelCreating(DbModelBuilder modelBuilder)
        {
            modelBuilder.Entity<Blog>().HasKey(x => x.MyTableKey);
            modelBuilder.Entity<Blog>().Property(x => x.Title).HasMaxLength(100);
            modelBuilder.Entity<Blog>().Property(x => x.AuthorName).IsRequired();
            
            base.OnModelCreating(modelBuilder);
        }
    }
}

به کمک پارامتر modelBuilder، امکان دسترسی به متدهای تنظیم کننده ویژگی‌های خواص یک مدل یا موجودیت وجود دارد. در اینجا چون می‌توان متدها را به صورت یک زنجیره به هم متصل کرد و همچنین حاصل نهایی شبیه به جمله بندی انگلیسی است، به آن Fluent API یا API روان نیز گفته می‌شود.
البته در این حالت امکان تعریف ErrorMessage وجود ندارد و برای این منظور باید از همان data annotations استفاده کرد.

نحوه مدیریت صحیح تعاریف نگاشت‌ها به کمک Fluent API

OnModelCreating محل مناسبی جهت تعریف حجم انبوهی از تنظیمات کلاس‌های مختلف مدل‌های برنامه نیست. در حد سه چهار سطر مشکلی ندارد اما اگر بیشتر شد بهتر است از روش زیر استفاده شود:

using System.Data.Entity;
using EF_Sample01.Models;
using System.Data.Entity.ModelConfiguration;

namespace EF_Sample01
{
    public class BlogConfig : EntityTypeConfiguration<Blog>
    {
        public BlogConfig()
        {
            this.Property(x => x.Id).HasColumnName("MyTableKey");
            this.Property(x => x.RowVersion).HasColumnType("Timestamp");
        }
    }

با ارث بری از کلاس EntityTypeConfiguration،‌ می‌توان به ازای هر کلاس مدل، تنظیمات را جداگانه انجام داد. به این ترتیب اصل SRP یا Single responsibility principle نقض نخواهد شد. سپس برای استفاده از این کلاس‌های Config تک مسئولیتی به نحو زیر می‌توان اقدام کرد:

protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
     modelBuilder.Configurations.Add(new BlogConfig());

نحوه تنظیمات ابتدایی نگاشت کلاس‌ها به بانک اطلاعاتی در EF Code first

الزامی ندارد که EF Code first حتما با یک بانک اطلاعاتی از نو تهیه شده بر اساس پیش فرض‌های آن کار کند. در اینجا می‌توان از بانک‌های اطلاعاتی موجود نیز استفاده کرد. اما در این حالت نیاز خواهد بود تا مثلا نام جدولی خاص با کلاسی مفروض در برنامه، یا نام فیلدی خاص که مطابق استانداردهای نامگذاری خواص در سی شارپ تعریف نشده، با خاصیتی در یک کلاس تطابق داده شوند. برای مثال اینبار تعاریف کلاس Blog را به نحو زیر تغییر دهید:

using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;

namespace EF_Sample01.Models
{
    [Table("tblBlogs")]
    public class Blog
    {
        [Column("MyTableKey")]
        public int Id { set; get; }

        [MaxLength(100)]
        public string Title { set; get; }

        [Required(ErrorMessage = "لطفا نام نویسنده را مشخص نمائید")]
        public string AuthorName { set; get; }

        public IList<Post> Posts { set; get; }

        [Timestamp]
        public byte[] RowVersion { set; get; }
    }
}

در اینجا فرض بر این است که نام جدول متناظر با کلاس Blog در بانک اطلاعاتی مثلا tblBlogs است و نام خاصیت Id در بانک اطلاعاتی مساوی فیلدی است به نام MyTableKey. چون نام خاصیت را مجددا به Id تغییر داده‌ایم، دیگر ضرورتی به ذکر ویژگی Key وجود نداشته است. برای تعریف این دو از ویژگی‌های Table و Column جهت سفارشی سازی نام‌های خواص و کلاس استفاده شده است.
یا اگر در کلاس خود خاصیتی محاسبه شده بر اساس سایر خواص، تعریف شده است و قصد نداریم آن‌را به فیلدی در بانک اطلاعاتی نگاشت کنیم، می‌توان از ویژگی NotMapped برای مزین سازی و تعریف آن کمک گرفت.
به علاوه اگر از نام پیش فرض کلید خارجی تشکیل شده خرسند نیستید می‌توان به کمک ویژگی ForeignKey، نسبت به تعریف مقداری جدید مطابق تعاریف یک بانک اطلاعاتی موجود، اقدام کرد.
همچنین خاصیت دیگری به نام RowVersion در اینجا اضافه شده که با ویژگی TimeStamp مزین گردیده است. از این خاصیت ویژه برای بررسی مسایل همزمانی ثبت اطلاعات در EF استفاده می‌شود. به علاوه بانک اطلاعاتی می‌تواند به صورت خودکار آن‌را در حین ثبت مقدار دهی کند.
تمام این تغییرات را به کمک Fluent API نیز می‌توان انجام داد:

modelBuilder.Entity<Blog>().ToTable("tblBlogs");
modelBuilder.Entity<Blog>().Property(x => x.Id).HasColumnName("MyTableKey");
modelBuilder.Entity<Blog>().Property(x => x.RowVersion).HasColumnType("Timestamp");

تبدیل پروژه‌های قدیمی EF به کلاس‌های EF Code first به صورت خودکار

روش متداول کار با EF از روز اول آن، مهندسی معکوس خودکار اطلاعات یک بانک اطلاعاتی و تبدیل آن به یک فایل EDMX بوده است. هنوز هم می‌توان از این روش در اینجا نیز بهره جست. برای مثال اگر قصد دارید یک پروژه قدیمی را تبدیل به نمونه جدید Code first کنید، یا یک بانک اطلاعاتی موجود را مهندسی معکوس کنید، بر روی پروژه در Solution explorer کلیک راست کرده و گزینه Add|New Item را انتخاب کنید. سپس از صفحه ظاهر شده، ADO.NET Entity data model را انتخاب کرده و در ادامه گزینه «Generate from database» را انتخاب کنید. این روال مرسوم کار با EF Database first است.
پس از اتمام کار به entity data model designer مراجعه کرده و بر روی صفحه کلیک راست نمائید. از منوی ظاهر شده گزینه «Add code generation item» را انتخاب کنید. سپس در صفحه باز شده از لیست قالب‌های موجود، گزینه «ADO.NET DbContext Generator» را انتخاب نمائید. این گزینه به صورت خودکار اطلاعات فایل EDMX قدیمی یا موجود شما را تبدیل به کلاس‌های مدل Code first معادل به همراه کلاس DbContext معرف آن‌ها خواهد کرد.

روش دیگری نیز برای انجام اینکار وجود دارد. نیاز است افزونه‌ی به نام Entity Framework Power Tools را دریافت کنید. پس از نصب، از منوی Entity Framework آن گزینه‌ی «Reverse Engineer Code First» را انتخاب نمائید. در اینجا می‌توان مشخصات اتصال به بانک اطلاعاتی را تعریف و سپس نسبت به تولید خودکار کدهای مدل‌ها و DbContext مرتبط اقدام کرد.

استراتژی‌های مقدماتی تشکیل بانک اطلاعاتی در EF Code first

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

System.Data.Entity.Database.SetInitializer(new DropCreateDatabaseIfModelChanges<Context>());
// or
System.Data.Entity.Database.SetInitializer(new DropCreateDatabaseAlways<Context>());

می‌توان بانک اطلاعاتی را در صورت تغییر اطلاعات یک مدل به صورت خودکار drop کرده و نسبت به ایجاد نمونه‌ای جدید اقدام کرد (DropCreateDatabaseIfModelChanges)؛ یا در حین آزمایش برنامه همیشه (DropCreateDatabaseAlways) با شروع برنامه، ابتدا باید بانک اطلاعاتی drop شده و سپس نمونه جدیدی تولید گردد.
محل فراخوانی این دستور هم باید در نقطه آغازین برنامه، پیش از وهله سازی اولین DbContext باشد. مثلا در برنامه‌های وب در متد Application_Start فایل global.asax.cs یا در برنامه‌های WPF در متد سازنده کلاس App می‌توان بانک اطلاعاتی را آغاز نمود.
البته الزامی به استفاده از کلاس‌های DropCreateDatabaseIfModelChanges یا DropCreateDatabaseAlways وجود ندارد. می‌توان با پیاده سازی اینترفیس IDatabaseInitializer از نوع کلاس Context تعریف شده در برنامه، همان عملیات را شبیه سازی کرد یا سفارشی نمود:

public class MyInitializer : IDatabaseInitializer<Context>
{
        public void InitializeDatabase(Context context)
        {
            if (context.Database.Exists() ||
                context.Database.CompatibleWithModel(throwIfNoMetadata: false))
                context.Database.Delete();

            context.Database.Create();            
        }
}

سپس برای استفاده از این کلاس در ابتدای برنامه، خواهیم داشت:

System.Data.Entity.Database.SetInitializer(new MyInitializer());

نکته:
اگر از یک بانک اطلاعاتی موجود استفاده می‌کنید (محیط کاری) و نیازی به پیش فرض‌های EF Code first ندارید و همچنین این بانک اطلاعاتی نیز نباید drop شود یا تغییر کند، می‌توانید تمام این پیش فرض‌ها را با دستور زیر غیرفعال کنید:

Database.SetInitializer<Context>(null);

بدیهی است این دستور نیز باید پیش از ایجاد اولین وهله از شیء DbContext فراخوانی شود.

همچنین باید درنظر داشت که در آخرین نگارش‌های پایدار EF Code first، این موارد بهبود یافته‌اند و مبحثی تحت عنوان DB Migration ایجاد شده است تا نیازی نباشد هربار بانک اطلاعاتی drop شود و تمام اطلاعات از دست برود. می‌توان صرفا تغییرات کلاس‌ها را به بانک اطلاعاتی اعمال کرد که به صورت جداگانه، در قسمتی مجزا بررسی خواهد شد. به این ترتیب دیگر نیازی به drop بانک اطلاعاتی نخواهد بود. به صورت پیش فرض در صورت از دست رفتن اطلاعات یک استثناء را سبب خواهد شد (که توسط برنامه نویس قابل تنظیم است) و در حالت خودکار یا دستی با تنظیمات ویژه قابل اعمال است.

تنظیم استراتژی‌های آغاز بانک اطلاعاتی در فایل کانفیگ برنامه

الزامی ندارد که حتما متد Database.SetInitializer را دستی فراخوانی کنیم. با اندکی تنظیم فایل‌های app.config و یا web.config نیز می‌توان نوع استراتژی مورد استفاده را تعیین کرد:

<appSettings>
 <add key="DatabaseInitializerForType MyNamespace.MyDbContextClass, MyAssembly" 
     value="MyNamespace.MyInitializerClass, MyAssembly"  />
</appSettings>

<appSettings>
 <add key="DatabaseInitializerForType MyNamespace.MyDbContextClass, MyAssembly" 
     value="Disabled" />
</appSettings>

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

<appSettings>
    <add key="DatabaseInitializerForType EF_Sample01.Context, EF_Sample01"
       value="EF_Sample01.MyInitializer, EF_Sample01" />
  </appSettings>

اجرای کدهای ویژه در حین تشکیل یک بانک اطلاعاتی جدید

امکان سفارشی سازی این آغاز کننده‌های پیش فرض نیز وجود دارد. برای مثال:

public class MyCustomInitializer : DropCreateDatabaseIfModelChanges<Context>
{
    protected override void Seed(Context context)
    {
        context.Blogs.Add(new Blog { AuthorName = "Vahid", Title = ".NET Tips" });
        context.Database.ExecuteSqlCommand("CREATE INDEX IX_title ON tblBlogs (title)");
        base.Seed(context);
    }
}

در اینجا با ارث بری از کلاس DropCreateDatabaseIfModelChanges یک آغاز کننده سفارشی را تعریف کرده‌ایم. سپس با تحریف متد Seed آن می‌توان در حین آغاز یک بانک اطلاعاتی، تعدادی رکورد پیش فرض را به آن افزود. کار ذخیره سازی نهایی در متد base.Seed انجام می‌شود.
برای استفاده از آن اینبار در حین فراخوانی متد System.Data.Entity.Database.SetInitializer، از کلاس MyCustomInitializer استفاده خواهیم کرد.
و یا توسط متد context.Database.ExecuteSqlCommand می‌توان دستورات SQL را مستقیما در اینجا اجرا کرد. عموما دستوراتی در اینجا مدنظر هستند که توسط ORMها پشتیبانی نمی‌شوند. برای مثال تغییر collation یک ستون یا افزودن یک ایندکس و مواردی از این دست.

سطح دسترسی مورد نیاز جهت فراخوانی متد Database.SetInitializer

استفاده از متدهای آغاز کننده بانک اطلاعاتی نیاز به سطح دسترسی بر روی بانک اطلاعاتی master را در SQL Server دارند (زیرا با انجام کوئری بر روی این بانک اطلاعاتی مشخص می‌شود، آیا بانک اطلاعاتی مورد نظر پیشتر تعریف شده است یا خیر). البته این مورد حین کار با SQL Server CE شاید اهمیتی نداشته باشد. بنابراین اگر کاربری که با آن به بانک اطلاعاتی متصل می‌شویم سطح دسترسی پایینی دارد نیاز است Persist Security Info=True را به رشته اتصالی اضافه کرد. البته این مورد را پس از انجام تغییرات بر روی بانک اطلاعاتی جهت امنیت بیشتر حذف کنید (یا به عبارتی در محیط کاری Persist Security Info=False باید باشد).

Server=(local);Database=yourDatabase;User ID=yourDBUser;Password=yourDBPassword;Trusted_Connection=False;Persist Security Info=True

تعیین Schema و کاربر فراخوان دستورات SQL

در EF Code first به صورت پیش فرض همه چیز بر مبنای کاربری با دسترسی مدیریتی یا dbo schema در اس کیوال سرور تنظیم شده است. اما اگر کاربر خاصی برای کار با دیتابیس تعریف گردد که در هاست‌های اشتراکی بسیار مرسوم است، دیگر از دسترسی مدیریتی dbo خبری نخواهد بود. اینبار نام جداول ما بجای dbo.tableName مثلا someUser.tableName می‌باشند و عدم دقت به این نکته، اجرای برنامه را غیرممکن می‌سازد.
برای تغییر و تعیین صریح کاربر متصل شده به بانک اطلاعاتی اگر از متادیتا استفاده می‌کنید، روش زیر باید بکارگرفته شود:

[Table("tblBlogs", Schema="someUser")]    
public class Blog

و یا در حالت بکارگیری Fluent API به نحو زیر قابل تنظیم است:

modelBuilder.Entity<Blog>().ToTable("tblBlogs", schemaName:"someUser");

‫۱۲ سال و ۶ ماه قبل، جمعه ۱۵ اردیبهشت ۱۳۹۱، ساعت ۱۴:۰۶

محمد جواد ابراهیمی

مطالب

شرط گذاری روی Include ها در EF Core 5x

سناریویی را در نظر بگیرید که میخواهید لیست Blog‌ها را به همراه Post هایشان که شامل کلمه‌ی خاصی است، به کلاینت باز گردانید. در این حالت احتمالا چنین کدی به نظرتان خواهد آمد:

// -- FilteredInclude_EFCore5
var list = dbContext.Blogs
    .AsNoTracking()
    .Include(p => p.Posts.Where(p => p.Title.Contains("test title")))
    .ToList();
return Json(list);

این کد تا قبل از EFCore 5.0 پیش نمایش 3، به خطای زیر منجر میشود؛ چرا که EFCore از شرط گذاری روی Include‌ها پشتیبانی نمی‌کند:

System.InvalidOperationException: 'Lambda expression used inside Include is not valid.'

پس مجبوریم همه‌ی رکورد‌های Include را از دیتابیس خوانده و سپس آنها را در حافظه فیلتر کنیم:

// -- NonFilteredInclude
var list = dbContext.Blogs
    .AsNoTracking()
    .Include(e => e.Posts)
    .ToList();
list.ForEach(p => p.Posts = p.Posts.Where(p => p.Title.Contains("test title")).ToList());

این روش سربار بسیار زیادی دارد و بسته به تعداد رکورد‌ها و ستون‌های Post، حجم زیادی از دیتای غیر لازم را از دیتابیس میخواند و تخصیص حافظه (memory allocation) اضافی و زیادی را به همراه دارد. مثلا اگر 100 Blog داشته باشیم که هرکدام 100 Post داشته باشند و فقط یکی از Post‌ها شرط مورد نظر را داشته باشد، بدین ترتیب 100 * 100 منهای 1 رکورد اضافی واکشی خواهد شد؛ یعنی برابر ‭9,999‬! (می توان با لحاظ کردن تعداد و حجم ستون‌های اضافی نیز وخامت اوضاع را درک کرد)

همچنین اگر به صورت غیر read-only (عدم استفاده از AsNoTracking) داده‌ها را لود کرده باشید، با شرطی که داخل ForEach اعمال می‌شود، رکوردهایی که فیلتر میشوند به صورت Deleted در ChangeTracker علامت گذاری میشوند که میتواند مشکل ساز نیز باشد.

برای حل این مشکل چندین روش وجود دارد:

1- توسط یک تایپ دلخواه (anonymous یا dto) واکشی را به صورت Projection انجام دهیم و Post‌ها را فیلتر کنیم:

// -- Projection_Manually
var list = dbContext.Blogs
    .AsNoTracking()
    .Select(p => new
    {
        p.Id,
        p.Name,
        Posts = p.Posts.Where(p => p.Title.Contains("test title")).ToList()
    }).ToList();

این دستور، کوئری SQL زیر را تولید میکند:

SELECT [b].[Id], [b].[Name], [t].[Id], [t].[BlogId], [t].[Description], [t].[Title]
FROM [Blogs] AS [b]
LEFT JOIN (
    SELECT [p].[Id], [p].[BlogId], [p].[Description], [p].[Title]
    FROM [Posts] AS [p]
    WHERE CHARINDEX(N'test title', [p].[Title]) > 0
) AS [t] ON [b].[Id] = [t].[BlogId]
ORDER BY [b].[Id], [t].[Id]

معایب این روش:

در صورت نیاز به ویرایش (عدم استفاده از AsNoTracking) بدلیل استفاده از anonymous بجای Blog، هیچ شیء Blog ایی در ChangeTracker ثبت نخواهد شد، ولی اشیا Post در ChangeTracker ثبت می‌شوند. در نتیجه تنها 1 شیء در ChangeTracker اضافه خواهد شد.
کد نویسی را کثیف میکند؛ مخصوصا اگر نیاز به شرط گذاری بر روی چندین Navigation Collection تو در تو را داشته باشید.

برای جلوگیری از این کثیف شدن میتوان از قابلیت Projection کتابخانه‌ی AutoMapper استفاده کرد. کوئری تولید شده و عملکرد آن عینا مشابه همین روش است، ولی کد تمیز‌تری را موجب می‌شود ( از نظر سرعت، مقدار کمی کند‌تر است. انتهای مقاله، بنچمارک آن را میتوانید مشاهده کنید)

2- از قابلیت IncludeFilter کتابخانه‌ی Z.EntityFramework.Plus.EFCore استفاده کنیم.

این کتابخانه امکانات بسیار مفیدی را ارائه میدهد و شخصا برای پروژه‌های واقعی و بزرگ آن را پیشنهاد میدهم. اگر از امکانات آن بجا استفاده شود، تاثیر بسیار زیادی را بر روی پرفرمنس پروژه خواهد گذاشت (توصیه میکنم حتما داکیومنت آن را مطالعه کنید). این کتابخانه کاملا رایگان است و از EFCore و EF6 (در یک پکیج جداگانه) پشتیبانی میکند. شرکت مالک آن (ZZZ) یک کتابخانه‌ی دیگر را نیز به نام Z.EntityFramework.Extensions.EFCore دارد که امکانات بیشتری را ارائه میدهد؛ ولی رایگان نیست.

در این روش خواهیم داشت:

// -- IncludeFilter_EFCorePlus
var list = dbContext.Blogs
    .AsNoTracking()
    .IncludeFilter(e => e.Posts.Where(p => p.Title.Contains("test tile")))
    .ToList();

این دستور کوئری SQL زیر را تولید میکند:

-- EF+ Query Future: 1 of 2
SELECT [b].[Id], [b].[Name]
FROM [Blogs] AS [b]
;

-- EF+ Query Future: 2 of 2
SELECT [t].[Id], [t].[BlogId], [t].[Description], [t].[Title]
FROM [Blogs] AS [b]
INNER JOIN (
    SELECT [p].[Id], [p].[BlogId], [p].[Description], [p].[Title]
    FROM [Posts] AS [p]
    WHERE CHARINDEX(N'test title', [p].[Title]) > 0
) AS [t] ON [b].[Id] = [t].[BlogId]
;

همانطور که می‌بینید این دستور، 2 کوئری را اجرا میکند. سرعت آن از روش قبلی کمی کند‌تر است و memory allocation بیشتری را انجام میدهد.
در صورت عدم استفاده از AsNoTracking، اشیاء Blog را نیز ثبت میکند؛ درنتیجه تعداد 101 آبجکت (100 Blog و 1 Post) به ChangeTracker اضافه خواهند شد.
کد نویسی تمیزتر و راحت‌تری در سمت سی شارپ دارد.
این روش در EF6 نیز قابل استفاده است.

3- کمبود این قابلیت در EFCore بسیار حس میشد (در NHibernate از قدیم این امکان وجود داشت) تا اینکه نهایتا در EFCore 5.0 پیش نمایش 3 (آخرین نسخه‌ی در حال حاضر) این قابلیت به EFCore اضافه شده‌است.

برای استفاده از آن نیاز به هیچ کد اضافه‌ای نیست و به صورت معمول میتوان از متد Include، همراه با شرط استفاده کرد:

// -- FilteredInclude_EFCore5
var list = dbContext.Blogs
    .AsNoTracking()
    .Include(p => p.Posts.Where(p => p.Title.Contains("test title")))
    .ToList();

این دستور، کوئری SQL زیر را تولید میکند:

SELECT [b].[Id], [b].[Name], [t].[Id], [t].[BlogId], [t].[Description], [t].[Title]
FROM [Blogs] AS [b]
LEFT JOIN (
    SELECT [p].[Id], [p].[BlogId], [p].[Description], [p].[Title]
    FROM [Posts] AS [p]
    WHERE CHARINDEX(N'test title', [p].[Title]) > 0
) AS [t] ON [b].[Id] = [t].[BlogId]
ORDER BY [b].[Id], [t].[Id]

این روش بسیار بهینه است و از روش قبلی (دوم) کمی سریع‌تر بوده و memory allocation کمتری (نزدیک به روش اول) دارد.
در صورت عدم استفاده از AsNoTracking، مانند قبلی عمل میکند؛ درنتیجه تعداد 101 آبجکت به ChangeTracker اضافه خواهند شد.
کد نویسی تمیزتر و راحت‌تری در سمت سی شارپ دارد.

بنچمارک مقایسه‌ی این روش‌ها را میتوانید از ریپازیتوری گیتهاب زیر دریافت کنید:

https://github.com/mjebrahimi/EFCore-Include-Filtering-Benchmark

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

‫۴ سال و ۵ ماه قبل، یکشنبه ۷ اردیبهشت ۱۳۹۹، ساعت ۱۹:۲۰

وحید نصیری

مطالب

بهبود کارآیی نمایش لیست‌ها در Blazor با استفاده از دایرکتیو key@

اگر پیشتر با React کار کرده باشید، احتمالا چنین پیام خطایی را دریافت کرده‌اید:

در اینجا React عنوان می‌کند که هر عنصر از لیستی را که در حال نمایش آن هستید، باید به همراه یک key، ارائه دهید. اما ... این key چیست؟
زمانیکه حالت کامپوننتی تغییر می‌کند (شیء یا اشیایی که به عناصر UI متصل هستند، تغییر می‌کنند)، React، درخت جدیدی از اشیایی را که باید رندر شوند، تولید می‌کند. اکنون React باید محاسبه کند که چه عناصری نسبت به درخت فعلی که در حال نمایش است، تغییر کرده‌اند تا فقط آن‌ها را به DOM اصلی اعمال کند؛ تا این تغییرات به کاربر نمایش داده شوند و ... این کار را هم به خوبی انجام می‌دهد. پس مشکل با لیست‌ها چیست که نیاز به key دارند؟
فرض کنید رندر لیستی، خروجی زیر را تولید می‌کند:

<li>Item 1</li>
<li>Item 2</li>

اکنون یک المان را به انتهای این لیست اضافه می‌کنیم:

<li>Item 1</li>
<li>Item 2</li>
<li>Item 3</li>

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

<li>Item 0</li> // <= New item
<li>Item 1</li>
<li>Item 2</li>
<li>Item 3</li>

یعنی این المان در ابتدای لیست، اضافه شده باشد، اینبار المان اول لیست سه‌تایی قبلی را با المان اول لیست چهارتایی جدید مقایسه می‌کند (مقایسه‌ی بر اساس ایندکس). چون این دو یکی نیستند، کل لیست جدید را مجددا رندر خواهد کرد؛ و در این حالت دیگر نمی‌تواند تشخیص دهد که المان‌هایی در این لیست هستند که با قبل تفاوتی ندارند.
راه‌حل React برای تشخیص منحصربفرد بودن المان‌های یک لیست و یا آرایه، استفاده از خاصیت key است:

<li key={0}>Item 0</li> // <= New item
<li key={1}>Item 1</li>
<li key={2}>Item 2</li>
<li key={3}>Item 3</li>

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

این نکات چه ربطی به Blazor دارند؟!
واقعیت این است که Blazor، همان نسخه‌ی مایکروسافتی React است (!) و این خاصیت key، در Blazor نیز تحت عنوان key directive@ وجود دارد و دقیقا مفهوم آن نیز با توضیحاتی که در مورد React داده شد، یکی است.
زمانیکه Blazor صفحه‌ای را رندر می‌کند، ابتدا یک DOM مشخصی را تولید خواهد کد. سپس با تغییر State یک کامپوننت، DOM جدیدی را محاسبه کرده و آن‌را با DOM فعلی مقایسه می‌کند و در نهایت diff تولیدی را به DOM موجود، در جهت نمایش تغییرات، اعمال خواهد کرد.
بنابراین الگوریتم diff باید اضافات، به روز رسانی‌ها و حذف‌های صورت گرفته‌ی در UI را تشخیص داده و فقط قسمت‌های تغییر یافته را جهت به روز رسانی بهینه‌ی UI، به آن اعمال کند. این الگوریتم diff به صورت پیش‌فرض از ایندکس المان‌ها برای مقایسه‌ی آن‌ها استفاده می‌کند. هرچند این روش در بسیاری از حالات، بهینه‌ترین روش است، اما در مورد لیست‌ها خیر؛ که توضیحات آن‌را با مثالی در مورد React، در ابتدای بحث بررسی کردیم. برای مثال اگر شیءای به انتهای لیست اضافه شود، هر المانی را که پس از این ایندکس قرار گرفته باشد، تغییر یافته درنظر گرفته و آن‌را مجددا رندر می‌کند. به همین جهت است که اگر المانی به ابتدای یک لیست اضافه شود، اینبار کل لیست را مجددا رندر می‌کند (چون تمام ایندکس‌های اشیاء موجود در لیست، تغییر کرده‌اند)؛ صرفنظر از اینکه عناصری از این لیست، پیشتر در UI رندر شده‌اند و نیازی به رندر مجدد، ندارند.

یک مثال: بررسی نحوه‌ی رندر لیستی از اشیاء در Blazor

در اینجا کدهای کامل کامپوننتی را مشاهده می‌کنید که یک لیست ساده را در ابتدا رندر کرده و هر بار که بر روی دکمه‌ی افزودن یک شخص کلیک می‌شود، شخص جدیدی را به ابتدای لیست اضافه می‌کند:

@page "/"

<button class="btn btn-primary" @onclick="addPerson">Add Person</button>

<ul class="mt-5">
    @foreach (var person in People)
    {
        <li>@person.Id, @person.Name</li>
    }
</ul>

@code{

    List<Person> People = new()
    {
        new() { Id = 1, Name = "User 1" },
        new() { Id = 2, Name = "User 2" },
    };
    int LastId = 2;

    void addPerson()
    {
        People.Insert(0, new() { Id = ++LastId, Name = $"User {LastId}" });
    }

    class Person
    {
        public int Id { set; get; }
        public string Name { set; get; }
    }
}

در این حالت اگر به لیست المان‌های نمایش داده شده‌ی در ابزار‌های توسعه دهندگان مرورگر مراجعه کنیم، با هر بار کلیک بر روی دکمه افزودن یک شخص جدید، محتوای li‌های نمایش داده شده، ابتدا به رنگ صورتی در آمده و سپس عادی می‌شوند. این تغییر رنگ، به معنای عناصری هستند که هم اکنون مجددا رندر شده‌اند و در UI نهایی تغییر کرده‌اند:

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

تغییر الگوریتم diff محاسبه‌ی تغییرات UI

الگوریتم پیش‌فرض diff، از ایندکس‌های عناصر برای یافتن تغییرات، استفاده می‌کند. با استفاده از دایرکتیو ویژه‌ی key@ می‌توان ایندکس‌های پیش‌فرض را با مقادیری منحصربفرد، بازنویسی کرد، تا اینبار Blazor دقیقا بداند که کدام آیتم، جدید است و کدام‌ها نیازی به رندر مجدد ندارند:

<ul class="mt-5">
    @foreach (var person in People)
    {
        <li @key="person.Id">@person.Id, @person.Name</li>
    }
</ul>

در اینجا تنها تغییر صورت گرفته، اضافه کردن دایرکتیو key@ به هر li در حال رندر است که اینبار مقدار آن، دیگر ایندکس پیش‌فرض عناصر نبوده، بلکه کلید منحصربفرد آن‌ها است.

اگر به تصویر فوق دقت کنید، اینبار فقط li جدیدی که اضافه شده‌است، ابتدا با رنگ صورتی نمایش داده می‌شود و محتوای داخل سایر li ها، دست نخورده باقی مانده‌است؛ یعنی مجددا رندر نشده‌اند.

‫۳ سال و ۴ ماه قبل، یکشنبه ۲۶ اردیبهشت ۱۴۰۰، ساعت ۱۶:۵۰

وحید نصیری

نظرات مطالب

ارتقاء به ASP.NET Core 1.0 - قسمت 18 - کار با ASP.NET Web API

ارتقاء به ASP.NET Core 7x

تغییر غیرسازگاری با نگارش‌های قبلی، در ASP.NET Core 7x رخ خواهد که در آن ویژگی [FromServices] که در مطلب جاری بحث شد، پیش‌فرض شده‌است؛ یعنی حتی اگر آن‌را ذکر هم نکردید، مهم نیست و به صورت پیش‌فرض در بین سرویس‌های ثبت شده نیز به دنبال پارامتر اکشن متد مدنظر شما می‌گردد:

Services.AddScoped<SomeCustomType>();

[Route("[controller]")]
[ApiController]
public class MyController : ControllerBase
{
    // Binding from the services
    [HttpPost]
    public ActionResult Post(SomeCustomType service) => Ok();
}

در این مثال، نوع SomeCustomType به صورت یک سرویس، در ابتدای برنامه ثبت شده‌است و همانطور که مشاهده می‌کنید، بدون نیاز به ذکر صریح ویژگی [FromServices]، در اکشن متد Post، مورد استفاده قرار گرفته‌است.

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

services.Configure<ApiBehaviorOptions>(options =>
{
     options.DisableImplicitFromServicesParameters = true;
});

‫۲ سال و ۷ ماه قبل، دوشنبه ۲۵ بهمن ۱۴۰۰، ساعت ۲۰:۵۷

وحید نصیری

مطالب

کوئری نویسی در EF Core - قسمت چهارم - اعمال تغییرات در داده‌ها

نوع دیگری از کوئری‌های پرکاربرد، کوئری‌های مرتبط با ثبت، حذف و ویرایش اطلاعات هستند که در این قسمت آن‌ها را بررسی می‌کنیم. البته این مثال‌ها از یکسری مثال کوئری‌های مرتبط با PostgreSQL، به EF-Core تبدیل و ترجمه شده‌اند. به همین جهت تطابق یک به یکی در اینجا وجود نداشته و روش شیءگرایی که ORMها برای کار با داده‌ها بکار می‌گیرند، الزاما کوئری‌های یکسانی را تولید نمی‌کنند؛ اما نتیجه‌ی نهایی آن‌ها یکی است.

مثال 1: افزودن ردیفی به یک جدول بانک اطلاعاتی

امکان و ویژگی جدیدی به نام SPA قرار است به مجموعه اضافه شود. اطلاعات آن که شامل موارد ذیل است، نیاز است به جدول facilities اضافه شود:

facid: 9, Name: 'Spa', membercost: 20, guestcost: 30, initialoutlay: 100000, monthlymaintenance: 800.

اگر قرار باشد چنین کاری را توسط دستورات SQL انجام دهیم، عموما به یکی از دو روش زیر عمل می‌شود:

insert into facilities
    (facid, name, membercost, guestcost, initialoutlay, monthlymaintenance)
    values (9, 'Spa', 20, 30, 100000, 800);
-- OR
insert into facilities values (9, 'Spa', 20, 30, 100000, 800);

که معادل آن در EF-Core به صورت زیر است:

context.Facilities.Add(new Facility
                {
                    Name = "Spa",
                    MemberCost = 20,
                    GuestCost = 30,
                    InitialOutlay = 100000,
                    MonthlyMaintenance = 800
                });
context.SaveChanges();

ابتدا وهله‌ای از موجودیت Facility به DbSet مرتبط با آن اضافه می‌شود و در آخر SaveChanges فراخوانی خواهد شد تا کوئری متناظر با آن ساخته شده و به بانک اطلاعاتی اعمال شود.

مثال 2: افزودن چندین ردیف از اطلاعات به یک جدول بانک اطلاعاتی

همان مثال قبلی را درنظر بگیرید. اینبار می‌خواهیم دو ردیف را به آن اضافه کنیم:

facid: 9, Name: 'Spa', membercost: 20, guestcost: 30, initialoutlay: 100000, monthlymaintenance: 800.
facid: 10, Name: 'Squash Court 2', membercost: 3.5, guestcost: 17.5, initialoutlay: 5000, monthlymaintenance: 80.

معادل کدهای SQL چنین عملی، می‌تواند کوئری زیر باشد:

insert into facilities
    (facid, name, membercost, guestcost, initialoutlay, monthlymaintenance)
    values
        (9, 'Spa', 20, 30, 100000, 800),
        (10, 'Squash Court 2', 3.5, 17.5, 5000, 80);

و روش انجام آن در EF-Core تفاوتی با مثال قبلی ندارد:

context.Facilities.Add(new Facility
                {
                    Name = "Spa",
                    MemberCost = 20,
                    GuestCost = 30,
                    InitialOutlay = 100000,
                    MonthlyMaintenance = 800
                });

context.Facilities.Add(new Facility
                {
                    Name = "Squash Court 2",
                    MemberCost = 3.5M,
                    GuestCost = 17.5M,
                    InitialOutlay = 5000,
                    MonthlyMaintenance = 80
                });
context.SaveChanges();

در اینجا می‌توان به هر تعدادی که نیاز است وهله‌های جدیدی از Facility را به context افزودن و سپس SaveChanges را در آخر کار فراخوانی کرد. اینکه EF-Core دستورات insert معادل را به یکباره و یا به صورت مجزایی اجرا می‌کند، به مفهومی به نام batching مرتبط است. اطلاعات بیشتر

مثال 3: افزودن اطلاعات محاسبه شده به یک جدول بانک اطلاعاتی

اطلاعات زیر را درنظر بگیرید:

Name: 'Spa', membercost: 20, guestcost: 30, initialoutlay: 100000, monthlymaintenance: 800.

در مثال اصلی عنوان شده که می‌خواهیم ID آن‌را یکی بیشتر از ردیف قبلی ثبت کنیم. در EF-Core و تنظیمات موجودیت‌هایی که داریم:

namespace EFCorePgExercises.Entities
{
    public class FacilityConfiguration : IEntityTypeConfiguration<Facility>
    {
        public void Configure(EntityTypeBuilder<Facility> builder)
        {
            builder.HasKey(facility => facility.FacId);
            builder.Property(facility => facility.FacId).IsRequired().UseIdentityColumn(seed: 0, increment: 1);

چون ستون ID به صورت خود افزایش یابنده معرفی شده‌است که از صفر شروع می‌شود و به صورت خودکار توسط بانک اطلاعاتی یکی یکی افزایش می‌یابد، نیازی به حل این مساله وجود ندارد. چون ID افزایش یابنده را خود بانک اطلاعاتی محاسبه می‌کند. همچنین به همین علت در مثال‌های قبلی نیز ID را به صورت مستقیمی مقدار دهی نکردیم. اگر نیاز به انجام چنین کاری وجود داشته باشد (ذکر صریح ID خاصی)، با توجه به طراحی بانک اطلاعاتی حاصل از این تنظیمات:

CREATE TABLE [dbo].[Facilities](
[FacId] [int] IDENTITY(0,1) NOT NULL,
--- ...
 CONSTRAINT [PK_Facilities] PRIMARY KEY CLUSTERED 
(
[FacId] ASC
);

باید مانند مثال ثبت اطلاعات اولیه‌ی در بانک اطلاعاتی در قسمت اول این سری، از روش SET IDENTITY_INSERT Facilities ON استفاده کرد تا بتوان مجوز ثبت دستی این ID کنترل شده‌ی توسط بانک اطلاعاتی را پیدا کرد.

مثال 4: به روز رسانی اطلاعاتی از پیش موجود

می‌خواهیم مقدار InitialOutlay دومین زمین تنیس را از 8000 موجود به 10000 تغییر دهیم. با توجه به اینکه ID این زمین شماره 1 است، در حالت متداول SQL نویسی، به کدهای زیر خواهیم رسید:

update facilities
    set initialoutlay = 10000
    where facid = 1;

که معادل EF-Core آن به صورت زیر است:

var facility1 = context.Facilities.Find(1);
facility1.InitialOutlay = 10000;
context.SaveChanges();

این دستورات کوئری مشابهی را تولید نمی‌کنند. ابتدا موجودیت متناظر با ID شماره‌ی 1 از بانک اطلاعاتی واکشی شده و سپس مقدار خاصیتی از آن تغییر کرده‌است. در آخر SaveChanges بر روی آن فراخوانی می‌شود.
EF-Core برای اینکه بتواند تغییرات اعمالی به یک شیء را محاسبه کند، نیاز دارد تا آن شیء را به نحوی در سیستم change tracking خودش موجود داشته باشد. هر نوع کوئری که در EF-Core نوشته می‌شود و به همراه متد AsNoTracking نیست، خروجی تک تک اشیاء حاصل از آن پیش از ارائه‌ی نهایی، وارد سیستم change tracking آن می‌شوند. یعنی اگر مقادیر خواص این اشیاء را تغییر داده و بر روی آن‌ها SaveChanges را فراخوانی کنیم، کوئری‌های متناظر با به روز رسانی تنها این خواص تغییر یافته به صورت خودکار محاسبه شده و به بانک اطلاعاتی اعمال می‌شوند.
فراخوانی متد AsNoTracking بر روی کوئری‌های EF-Core، تولید پروکسی‌های change tracking را غیرفعال می‌کند. یک چنین کوئری‌هایی صرفا کاربردهای گزارشگیری فقط خواندنی را دارند و نسبت به کوئری‌های معمولی، سریعتر و با مصرف حافظه‌ی کمتری هستند. بنابراین نتایج حاصل از کوئری‌های متداول EF-Core، به صورت پیش‌فرض (یعنی بدون داشتن متد AsNoTracking) هم خواندنی و هم نوشتنی با قابلیت اعمال به بانک اطلاعاتی هستند.

مثال 5: به روز رسانی چندین ردیف و چندین جدول در یک زمان

می‌خواهیم مقادیر MemberCost و GuestCost دو زمین تنیس را به 6 و 30 تغییر دهیم. روش انجام اینکار با SQL نویسی معمولی به صورت زیر است:

update cd.facilities
    set
        membercost = 6,
        guestcost = 30
    where facid in (0,1);

اما همانطور که عنوان شد در EF-Core ابتدا باید اشیاء متناظر با این زمین‌های تنیس را در سیستم change tacking موجود داشت و سپس نسبت به ویرایش آن‌ها اقدام نمود. یکی از روش‌های وارد کردن اشیاء به سیستم change tacking، نوشتن کوئری‌های بدون متد AsNoTracking است و سپس به روز رسانی نتایج حاصل از آن‌ها که اکنون توسط پروکسی‌های change tracking محصور شده‌اند و در آخر فراخوانی SaveChanges بر روی context جاری:

int[] facIds = { 0, 1 };
var tennisCourts = context.Facilities.Where(x => facIds.Contains(x.FacId)).ToList();
foreach (var tennisCourt in tennisCourts)
{
     tennisCourt.MemberCost = 6;
     tennisCourt.GuestCost = 30;
}

context.SaveChanges();

مثال 6: به روز رسانی اطلاعات یک ردیف بر اساس اطلاعات ردیفی دیگر

می‌خواهیم هزینه‌ی دومین زمین تنیس را به نحوی ویرایش کنیم که 10 درصد بیشتر از هزینه‌ی اولین زمین تنیس باشد.
روش پیشنهادی انجام اینکار با SQL نویسی مستقیم به صورت زیر است:

update cd.facilities facs
    set
        membercost = (select membercost * 1.1 from cd.facilities where facid = 0),
        guestcost = (select guestcost * 1.1 from cd.facilities where facid = 0)
    where facs.facid = 1;

در EF-Core می‌توان اشیاء متناظر با این دو زمین تنیس را ابتدا واکشی کرد، سپس تغییر داد و در نهایت ذخیره کرد:

var fac0 = context.Facilities.Where(x => x.FacId == 0).First();
var fac1 = context.Facilities.Where(x => x.FacId == 1).First();
fac1.MemberCost = fac0.MemberCost * 1.1M;
fac1.GuestCost = fac0.GuestCost * 1.1M;

context.SaveChanges();

مثال 7: حذف تمام اطلاعات یک جدول

می‌خواهیم تمام اطلاعات جدول bookings را حذف کنیم.
روش انجام اینکار با SQL نویسی مستقیم به صورت زیر است:

delete from bookings

اما ... این تک کوئری، معادلی را در EF-Core استاندارد ندارد. چون EF-Core نیاز دارد مدام تمام اطلاعات ویرایشی/حذف و به روز رسانی را در context و سیستم change tracking خودش داشته باشد، ابتدا باید توسط یک کوئری لیست اشیاء مدنظر را تهیه کرد و سپس آن‌را به متد RemoveRange معرفی کرد تا حذف تک تک آن‌ها که شامل صدها کوئری خواهد شد، صورت گیرد:

context.Bookings.RemoveRange(context.Bookings.ToList());
context.SaveChanges();

این روش سریع نیست؛ اما کار می‌کند!
البته هستند کتابخانه‌های ثالثی (^ و ^) که انجام به روز رسانی دسته‌ای و یا حذف دسته‌ای از رکوردها را تنها با یک کوئری SQL میسر می‌کنند؛ اما ... هنوز جزئی از EF استاندارد نشده‌اند و مهم‌ترین مشکل احتمالی این روش‌ها، همگام نبودن context و سیستم change tacking، با نتیجه‌ی حاصل از به روز رسانی یکباره‌ی صدها ردیف است.

مثال 8: حذف یک کاربر از جدول کاربران

می‌خواهیم کاربر شماره‌ی 37 را حذف کنیم.
روش انجام اینکار با SQL نویسی به صورت زیر است:

delete from members where memid = 37;

و در EF-Core برای انجام اینکار می‌توان ابتدا شیء متناظر با کاربر 37 را از طریق یک کوئری به سیستم change tracking وارد کرد و سپس آن‌را حذف نمود:

var mem37 = context.Members.Where(x => x.MemId == 37).First();
context.Members.Remove(mem37);

context.SaveChanges();

یک نکته: امکان ساده‌تر حذف یک ردیف با داشتن ID آن

کوئری گرفتن از بانک اطلاعاتی، یک روش وارد کردن شیءای به context و سیستم change tacking آن است. در این حالت عموما فرض بر این است که ID شیء را نمی‌دانیم. اما اگر این ID مانند مثال جاری از پیش مشخص بود، نیازی نیست تا ابتدا از بانک اطلاعاتی کوئری گرفت و کل شیء را در حافظه وارد کرد. در این حالت خاص می‌توان با استفاده از روش زیر، این ID را وارد سیستم tracking کرد و سپس حالت آن‌را به Deleted تغییر داد و در آخر آن‌را ذخیره کرد:

var entry = context.Entry(new Member { MemId = 37 });
entry.State = EntityState.Deleted;
context.SaveChanges();

در کدهای فوق می‌توان سطر entry.State = EntityState.Deleted را با context.Remove(entry) نیز جایگزین کرد و هر دو به یک معنا هستند.
روش فوق چنین کوئری‌هایی را ایجاد می‌کند:

SET NOCOUNT ON;
DELETE FROM [Members]
WHERE [MemId] = @p0;
SELECT @@ROWCOUNT;

مثال 9: حذف بر اساس یک sub-query

می‌خواهیم تمام کاربرانی را که هیچگاه رزروی را انجام نداده‌اند، حذف کنیم.
این مورد نیز با SQL نویسی مستقیم نیز توسط یک کوئری دسته‌ای قابل انجام است:

delete from members where memid not in (select memid from cd.bookings);

اما همانطور که عنوان شد، EF-Core این نوع اعمال ویرایش دسته‌ای را در طی یک تک کوئری پشتیبانی نمی‌کند. به همین جهت ابتدا آن‌ها را توسط یک کوئری به context وارد کرده و سپس حذف می‌کنیم:

var mems = context.Members.Where(x =>
  !context.Bookings.Select(x => x.MemId).Contains(x.MemId)).ToList();
context.Members.RemoveRange(mems);

context.SaveChanges();

کدهای کامل این قسمت را در اینجا می‌توانید مشاهده کنید.

‫۴ سال و ۲ ماه قبل، چهارشنبه ۸ مرداد ۱۳۹۹، ساعت ۱۶:۰۰

وحید نصیری

مطالب

Angular Material 6x - قسمت دوم - معرفی Angular Flex layout

در این سری قصد داریم یک برنامه‌ی ساده‌ی دفترچه تلفن را توسط Angular 6x و کامپوننت‌های متریال آن ایجاد کنیم؛ اما Grid جزئی از بسته‌ی Angular Material نیست. بنابراین برای طرحبندی برنامه و قرار دادن المان‌های مختلف در مکان‌های تعیین شده‌ی صفحه، از Angular FlexBox Module استفاده خواهیم کرد که محصور کننده‌ی CSS 3 FlexBox است.

آشنایی با Flex Layout Box Model

برای طراحی ظاهر یک برنامه‌ی وب نیاز است عناصر آن‌را در مکان‌های مختلفی از صفحه قرار داد که به آن Layout گفته می‌شود. برای این منظور عموما 4 روش ذیل مرسوم هستند:
1. Table
2. Float, position, clear
3. CSS Grids
4. FlexBox CSS

امروزه دیگر آنچنان روش‌های 1 و 2 به صورت مستقیم مورد استفاده قرار نمی‌گیرند. CSS Grid روش نهایی طراحی Layout در آینده خواهد بود و در حال حاضر تعداد مرورگرهایی که از آن پشتیبانی می‌کنند، قابل توجه نیست؛ اما از FlexBox در IE 11، کروم 21 و فایرفاکس 22 به بعد پشتیبانی می‌شود.

FlexBox CSS، سیلان المان‌های قرار گرفته‌ی در داخل آن‌را سبب می‌شود. در اینجا یک container اصلی وجود دارد که در برگیرنده‌ی المان‌ها است. در تصویر فوق دو محور را مشاهده می‌کنید. محور افقی از چپ به راست ادامه پیدا می‌کند. محور عمودی نحوه‌ی ارتباط عناصر را مشخص می‌کند.
اکنون این سؤال مطرح می‌شود که چه تفاوتی بین یک Grid و FlexBox CSS وجود دارد؟ در یک Grid طراحی دو بعدی سطرها و ستون وجود دارد. اما به FlexBox باید به صورت سیلان یک بعدی سلول‌ها نگاه کرد. برای مثال عناصر قرار گرفته‌ی درون Container یا به صورت افقی درون آن گسترده شده و قرار می‌گیرند و یا به صورت عمودی.

نحوه‌ی تفکر و کارکرد با FlexBox چگونه است؟

در اینجا باید به دو مفهوم دقت داشت:
الف) سیلان عناصر درون Container که می‌تواند افقی و یا عمودی باشد.
ب) اندازه‌ی المان‌ها که می‌تواند ثابت و یا نسبی باشد.

یک Container، جهت سیلان عناصر درون آن‌را مشخص می‌کند. المان‌های آن، اندازه، فاصله‌ی از یکدیگر و ترتیب قرارگیری را ارائه می‌دهند. یک flex container می‌تواند شامل چندین flex container تو در تو نیز باشد.

نحوه‌ی سیلان عناصر در FlexBox چگونه است؟

برای نمونه طرحبندی متداول ذیل را درنظر بگیرید:

نحوه تفکر در مورد طراحی این طرحبندی، باید از بیرون به درون و از بالا به پایین (سیلان عمودی) باشد:

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

در ادامه به قسمت میانی می‌رسیم که آن نیز دارای سیلان افقی از چپ به راست است:

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

و تمام این سیلان‌ها و انتقال به سطرهای بعدی بر اساس اندازه‌ی المان‌ها صورت می‌گیرد:

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

معرفی کتابخانه‌ی Angular Flex Layout

برای کار با Flex CSS نیاز است:
- مقدار زیادی کد CSS نوشت.
- نیاز به درک عمیقی از Flex Box دارد.
- نیاز است با باگ‌های مرورگرها و تفاوت‌های پیاده سازی‌های آن‌ها در مورد FlexBox آشنا بود.
- نیاز به Prefixing دارد.
- برای Angular طراحی نشده‌است.

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

مزایای کار با کتابخانه‌ی Angular flex layout

- یک کتابخانه‌ی متکی به خود و مستقل است و برای کار با آن الزامی به استفاده‌ی از Angular Material نیست.

- به همراه هیچ فایل CSS جانبی ارائه نمی‌شود.
- پیاده سازی TypeScript ایی دارد. در اصل یک سری directives مخصوص Angular است که با TypeScript نوشته شده‌است.
- به صورت پویا و inline تمام CSSهای مورد نیاز را تولید و تزریق می‌کند.
- به همراه یک API استاتیک است و همچنین یک API واکنشگرا
- با Angular CLI نیز یکپارچه شده‌است.

نصب و تنظیم کتابخانه‌ی Angular Flex layout

برای نصب این کتابخانه، در ریشه‌ی پروژه دستور زیر را صادر کنید:

 npm install @angular/flex-layout --save

سپس ماژول آن‌را باید به shared.module.ts اضافه کرد:

import { FlexLayoutModule } from "@angular/flex-layout";

@NgModule({
  imports: [
    FlexLayoutModule
  ],
  exports: [
    FlexLayoutModule
  ]
})
export class SharedModule {
}

کار با API استاتیک Angular Flex layout

API استاتیک Angular Flex layout شامل این مزایا و مشخصات است:
- به صورت یکسری دایرکتیو Angular طراحی شده‌است که به HTML قالب کامپوننت‌ها اضافه می‌شود.
- از data binding پشتیبانی می‌کند.
- CSS نهایی را به صورت پویا و inline تولید و به صفحه تزریق می‌کند. Inline CSS تزریق شده به ویژگی‌های styles هر المان تزریق می‌شوند و موارد مشابه را در صورت وجود بازنویسی می‌کنند.
- از تشخیص تغییرات پشتیبانی می‌کند.
- به همراه ویژگی‌های fxHide و fxShow است.
- کارآیی مطلوبی دارد.

در اینجا برای تعریف container اصلی از دایرکتیوهای زیر استفاده می‌شود:
- fxLayout جهت‌های flex را مشخص می‌کند.

<div fxLayout="row" 
     fxLayout.xs="column"></div>

- fxLayout می‌تواند دارای مقداری مانند row، column و row-reverse و column-reverse باشد. برای مثال مقدار row-reverse‌، نمایش از راست به چپ را سبب می‌شود.
- fxLayoutWrap مشخص می‌کند که آیا المان‌ها باید به سطر و یا ستون بعدی منتقل شوند یا خیر؟

<div fxLayoutWrap></div>

- fxLayoutGap فاصله‌ی بین المان‌ها را مشخص می‌کند.

<div fxLayoutGap="10px"></div>

- fxLayoutAlign نحوه‌ی چیدمان المان را تعیین می‌کند.

<div fxLayoutAlign="start stretch"></div>

چند مثال:

و یا حالت راست به چپ آن به صورت زیر است:

و برای تعریف آیتم‌های قرار گرفته‌ی درون containers می‌توان از دایرکتیوهای زیر استفاده کرد:
- fxflex برای تعیین اندازه و flex المان‌ها

<div fxFlex="1 2 calc(15em + 20px)"></div>

در اینجا سه مقداری که ذکر می‌شوند (و یا تنها یک مقدار) چنین معنایی را به همراه دارند:

 fxFlex="grow shrink basis"

و یا

 fxFlex="basis"

- grow به این معنا است که آیتم جاری در صورت وجود فضا (طراحی واکنشگرا و واکنش نشان دادن به اندازه‌ی صفحه)، نسبت به سایر المان‌ها تا چه اندازه‌ای می‌تواند بزرگ شود.
- shrink به این معنا است که اگر به اندازه‌ی کافی فضا وجود نداشت، این المان نسبت به سایر المان‌های دیگر تا چه اندازه‌ای می‌تواند کوچک شود.
- basis به معنای اندازه‌ی پیش‌فرض المان است.

در اینجا اندازه‌ها برحسب پیکسل، درصد و یا calcs, em, cw, vh می‌توانند تعیین شوند. همچنین یک سری نام مستعار مانند grow, initial, auto, none, nogrow, noshrink هم قابل استفاده هستند.

- fxflexorder برای تعیین ترتیب قرارگیری یک المان

<div fxFlexOrder="2"></div>

- fxflexoffset برای تعیین فاصله یک المان از container آن

 <div fxFlexOffset="20px"></div>

- fxflexAlign برای تعیین محل قرارگیری المان

 <div fxFlexAlign="center"></div>

- fxflexfill برای تعیین اینکه این المان کل ردیف یا ستون را پر خواهد کرد

 <div fxFlexFill></div>

چند مثال:

در اینجا سه نمایشی را که در ذیل تعریف div‌ها مشاهده می‌کنید بر اساس تغییر اندازه‌ی صفحه حاصل شده‌اند. چون آیتم دوم دارای مقدار grow مساوی 5 است، به همین جهت با تغییر اندازه‌ی صفحه و دسترسی به مقدار فضای بیشتر، بزرگ‌تر شده‌است.

یک مثال کامل
اگر علاقمند باشید تا توانمندی‌های angular flex layout را در قالب یک مثال کامل مشاهده کنید، به آدرس زیر مراجعه نمائید:
https://tburleson-layouts-demos.firebaseapp.com/#/docs
در این مثال با تغییر گزینه‌‌های مختلف، کد معادل angular flex layout آن نیز تولید می‌شود.
همچنین wiki خود پروژه نیز به همراه مثال‌های بیشتری است:
https://github.com/angular/flex-layout/wiki

کار با API واکنشگرای Angular Flex layout

در طراحی واکنشگرا، container و عناصر داخل آن بر اساس تغییرات اندازه‌ی صفحه و یا اندازه‌ی وسیله‌ی نمایشی، تغییر اندازه و همچنین موقعیت می‌دهند و این تغییرات بر اساس انطباق با viewport وسیله‌ی نمایشی صورت می‌گیرند. به همین جهت برای طراحی واکنشگرا نیاز به Flex CSS و همچنین Media Query است. نوشتن Medial Query و ترکیب آن با Flex CSS کار مشکلی است. به همین جهت Angular Flex layout به همراه یک API واکنشگرا نیز هست که در پشت صحنه Flex CSS را بر اساس طراحی متریال و Medial Queries مورد استفاده قرار می‌دهد.
اگر علاقمند هستید تا اندازه‌های واکنشگرای استاندارد متریال را ملاحظه کنید، می‌توانید به آدرس زیر مراجعه نمائید (قسمت Breakpoint system آن):
https://material.io/design/layout/responsive-layout-grid.html#breakpoints
برای مثال هر اندازه‌ای کمتر از 600px در گروه extra small قرار می‌گیرد (با مخفف xs). از 600px تا 1024px در بازه‌ی small (با مخفف sm)، از 1024px تا 1440px در بازه‌ی medium (با مخفف md) و از 1440px تا 1920px در بازه‌ی large (با مخفف lg) و بیشتر از آن در بازه‌ی xlrage قرار می‌گیرند (با مخفف xl). این اعداد و بازه‌ها، پایه‌ی طراحی API واکنشگرای Angular Flex layout هستند. به همین جهت نام این بازه‌ها در این API به صورت مخفف xs, sm, md, lg, xl درنظر گرفته شده‌اند و مورد استفاده قرار می‌گیرند. همچنین اگر اندازه‌های مدنظر از این بازه‌ها کمتر باشند، می‌توان از lt-sm, lt-md, lt-lg, lt-xl نیز استفاده کرد. در اینجا lt به معنای less than است و یا اگر بازه‌های مورد نیاز بیش از این اندازه‌ها باشند می‌توان با gt-xs, gt-sm, gt-md, gt-lg کار کرد. در اینجا gt به معنای greater than است.
به این مخفف‌ها «media query alias» هم گفته می‌شود و اکنون که لیست آن‌ها مشخص است، تنها کافی است آن‌ها را به API استاتیکی که پیشتر بررسی کردیم، اضافه کنیم. برای مثال:

fxLayout.sm = "..."
fxLayoutAlign.md = "..."
fxHide.gt-sm = "..."

برای نمونه فرض کنید یک چنین طرحبندی دسکتاپی را داریم:

معادل طراحی آن با API استاتیک Angular Flex Layout به صورت زیر است:

که در اینجا دو container را ملاحظه می‌کنید. ابتدا Container بیرونی جهت ارائه‌ی ستونی از سه المان اضافه شده‌است. سپس یک Container میانی برای تعریف ردیفی از سه المان تعریف شده‌است. توسط روش "fxFlex="grow shrink basis نیز اندازه‌های آن‌ها مشخص شده‌اند.

اکنون که این طرحبندی دسکتاپ را داریم، چگونه باید آن‌را تبدیل به طرحبندی موبایل، مانند شکل زیر کنیم؟

برای اینکار ابتدا fxLayout.xs را به سطر میانی اضافه می‌کنیم تا هرگاه به این اندازه رسیدیم، بجای ردیف، تبدیل به ستون شود. سپس توسط fxFlexOrder.xs، در اندازه‌ی xs، محل قرارگیری المان‌های این ستون را هم مشخص می‌کنیم:

همانطور که ملاحظه می‌کنید کار کردن با این API بسیار ساده‌است و نیازی به کارکردن مستقیم با Media Queries و یا برنامه نویسی مستقیم ندارد و تمام آن در قالب HTML یک کامپوننت قابل پیاده سازی است.
یک نکته: مثال کاملی که پیشتر در این بحث مطرح شد، به همراه مثال واکنشگرا نیز هست که برای مشاهده‌ی اثر آن‌ها بهتر است اندازه‌ی مرورگر را کوچک و بزرگ کنید.

مخفی کردن و یا نمایش قسمتی از صفحه بر اساس اندازه‌ی آن

علاوه بر media query alias هایی که عنوان شد، امکان نمایش و یا مخفی سازی قسمت‌های مختلف صفحه بر اساس اندازه‌ی صفحه‌ی نمایشی نیز هست:

 <div fxShow fxHide.xs="false" fxHide.lg="true"></div>

در اینجا fxShow سبب نمایش این div در حالت عادی می‌شود (پیش‌فرض آن xl، md و sm است). اما اگر اندازه‌ی صفحه lg باشد، fxHide.lg تنظیم شده‌ی به true سبب مخفی سازی آن خواهد شد و در اندازه‌ی xs مجددا نمایش داده می‌شود.

تغییر اندازه‌ی قسمتی از صفحه بر اساس اندازه‌ی آن

در مثال زیر اگر اندازه‌ی صفحه gt-sm باشد (بیشتر از small)، اندازه‌ی این div به 100 درصد بجای 50 درصد حالت‌های دیگر، تنظیم می‌شود:

 <div fxFlex="50%" fxFlex.gt-sm="100%"></div>

حالت‌های ویژه‌ی طراحی واکنشگرا در Angular Flex Layout

در API واکنشگرای آن حالت‌های ویژه‌ی fxshow, fxhide, ngclass و ngstyle نیز درنظر گرفته شده‌اند که امکان فعالسازی آن‌ها در اندازه‌های مختلف صفحه مسیر است:

<div fxShow [fxShow.xs]="isVisibleOnMobile()"></div>
<div fxHide [fxHide.gt-sm]="isVisibleOnDesktop()"></div>
<div [ngClass.sm]="{'fxClass-sm': hasStyle}" ></div>
<div [ngStyle.xs]="{color: 'blue'}"></div>

امکان کار با API واکنشگرا از طریق برنامه نویسی

برای این منظور می‌توان از سرویس ObservableMedia مانند مثال زیر استفاده کرد:

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

برای مطالعه‌ی بیشتر

قسمت‌های عمده‌ای از مطلب جاری، از ویدیوی زیر که توسط نویسنده‌ی اصلی angular flex layout تهیه شده‌است، گردآوری شدند.

Responsive Layouts with @angular/Flex-Layout

‫۶ سال و ۳ ماه قبل، یکشنبه ۱۷ تیر ۱۳۹۷، ساعت ۱۲:۳۵