چون عناصر آن متصل هستند. یعنی Context نیازی به اتصال مجدد و بررسی وضعیت تک تک عناصر آن برای تولید SQL صحیح ندارد و همه چیز از پیش محاسبه شده است (این دو مورد اتصال و محاسبه وضعیت، زمانبر است؛ برای 20 عنصر در محاسبات فوق نزدیک به 20 میلی ثانیه تفاوتش است).
مباحث eager fetching/loading (واکشی حریصانه) و lazy loading/fetching (واکشی در صورت نیاز، با تاخیر، تنبل) جزو نکات کلیدی کار با ORM های پیشرفته بوده و در صورت عدم اطلاع از آنها و یا استفاده‌ی ناصحیح از هر کدام، باید منتظر از کار افتادن زود هنگام سیستم در زیر بار چند کاربر همزمان بود. به همین جهت تصور اینکه "با استفاده از ORMs دیگر از فراگیری SQL راحت شدیم!" یا اینکه "به من چه که پشت صحنه چه اتفاقی می‌افته!" بسی مهلک و نادرست است!
در ادامه به تفصیل به این موضوع پرداخته خواهد شد.
ابزار مورد نیاز
در این مطلب از برنامه‌ی NHProf استفاده خواهد شد.
اگر مطالب NHibernate این سایت را دنبال کرده باشید، در مورد لاگ کردن SQL تولیدی به اندازه‌ی کافی توضیح داده شده یا حتی یک ماژول جمع و جور هم برای مصارف دم دستی نوشته شده است. این موارد شاید این ایده را به همراه داشته باشند که چقدر خوب می‌شد یک برنامه‌ی جامع‌تر برای این نوع بررسی‌ها تهیه می‌شد. حداقل SQL نهایی فرمت می‌شد (یعنی برنامه باید مجهز به یک SQL Parser تمام عیار باشد که کار چند ماهی هست ...؛ با توجه به اینکه مثلا NHibernate از افزونه‌های SQL ویژه بانک‌های اطلاعاتی مختلف هم پشتیبانی می‌کند، مثلا T-SQL مایکروسافت با یک سری ریزه کاری‌های منحصر به MySQL متفاوت است)، یا پس از فرمت شدن، syntax highlighting به آن اضافه می‌شد، در ادامه مشخص می‌کرد کدام کوئری‌ها سنگین‌تر هستند، کدامیک نشانه‌ی عدم استفاده‌ی صحیح از ORM مورد استفاده است، چه مشکلی دارد و از این موارد.
خوشبختانه این ایده‌ها یا آرزوها با برنامه‌ی NHProf محقق شده است. این برنامه برای استفاده‌ی یک ماه اول آن رایگان است (آدرس ایمیل خود را وارد کنید تا یک فایل مجوز رایگان یک ماهه برای شما ارسال گردد) و پس از یک ماه، باید حداقل 300 دلار هزینه کنید.
واکشی حریصانه و غیرحریصانه چیست؟
رفتار یک ORM جهت تعیین اینکه آیا نیاز است برای دریافت اطلاعات بین جداول Join صورت گیرد یا خیر، واکشی حریصانه و غیرحریصانه را مشخص می‌سازد.
در حالت واکشی حریصانه به ORM خواهیم گفت که لطفا جهت دریافت اطلاعات فیلدهای جداول مختلف، از همان ابتدای کار در پشت صحنه، Join های لازم را تدارک ببین. در حالت واکشی غیرحریصانه به ORM خواهیم گفت به هیچ عنوان حق نداری Join ایی را تشکیل دهی. هر زمانی که نیاز به اطلاعات فیلدی از جدولی دیگر بود باید به صورت مستقیم به آن مراجعه کرده و آن مقدار را دریافت کنی.
به صورت خلاصه برنامه نویس در حین کار با ORM های پیشرفته نیازی نیست Join بنویسد. تنها باید ORM را طوری تنظیم کند که آیا اینکار را حتما خودش در پشت صحنه انجام دهد (واکشی حریصانه)، یا اینکه خیر، به هیچ عنوان SQL های تولیدی در پشت صحنه نباید حاوی Join باشند (lazy loading).
چگونه واکشی حریصانه و غیرحریصانه را در NHibernate 3.0 تنظیم کنیم؟
در NHibernate اگر تنظیم خاصی را تدارک ندیده و خواص جداول خود را به صورت virtual معرفی کرده باشید، تنظیم پیش فرض دریافت اطلاعات همان lazy loading است. به مثالی در این زمینه توجه بفرمائید:
مدل برنامه:
مدل برنامه همان مثال کلاسیک مشتری و سفارشات او میباشد. هر مشتری چندین سفارش می‌تواند داشته باشد. هر سفارش به یک مشتری وابسته است. هر سفارش نیز از چندین قلم جنس تشکیل شده است. در این خرید، هر جنس نیز به یک سفارش وابسته است.
using System.Collections.Generic;
namespace CustomerOrdersSample.Domain
{
public class Customer
{
public virtual int Id { get; set; }
public virtual string Name { get; set; }
public virtual IList<Order> Orders { get; set; }
}
}
using System;
using System.Collections.Generic;
namespace CustomerOrdersSample.Domain
{
public class Order
{
public virtual int Id { get; set; }
public virtual DateTime OrderDate { set; get; }
public virtual Customer Customer { get; set; }
public virtual IList<OrderItem> OrderItems { set; get; }
}
}
namespace CustomerOrdersSample.Domain
{
public class OrderItem
{
public virtual int Id { get; set; }
public virtual Product Product { get; set; }
public virtual int Quntity { get; set; }
public virtual Order Order { set; get; }
}
}
namespace CustomerOrdersSample.Domain
{
public class Product
{
public virtual int Id { set; get; }
public virtual string Name { get; set; }
public virtual decimal UnitPrice { get; set; }
}
}
که جداول متناظر با آن به صورت زیر خواهند بود:
create table Customers (
CustomerId INT IDENTITY NOT NULL,
Name NVARCHAR(255) null,
primary key (CustomerId)
)
create table Orders (
OrderId INT IDENTITY NOT NULL,
OrderDate DATETIME null,
CustomerId INT null,
primary key (OrderId)
)
create table OrderItems (
OrderItemId INT IDENTITY NOT NULL,
Quntity INT null,
ProductId INT null,
OrderId INT null,
primary key (OrderItemId)
)
create table Products (
ProductId INT IDENTITY NOT NULL,
Name NVARCHAR(255) null,
UnitPrice NUMERIC(19,5) null,
primary key (ProductId)
)
alter table Orders
add constraint fk_Customer_Order
foreign key (CustomerId)
references Customers
alter table OrderItems
add constraint fk_Product_OrderItem
foreign key (ProductId)
references Products
alter table OrderItems
add constraint fk_Order_OrderItem
foreign key (OrderId)
references Orders
همچنین یک سری اطلاعات آزمایشی زیر را هم در نظر بگیرید: (بانک اطلاعاتی انتخاب شده SQL CE است)
SET IDENTITY_INSERT [Customers] ON;
GO
INSERT INTO [Customers] ([CustomerId],[Name]) VALUES (1,N'Customer1');
GO
SET IDENTITY_INSERT [Customers] OFF;
GO
SET IDENTITY_INSERT [Products] ON;
GO
INSERT INTO [Products] ([ProductId],[Name],[UnitPrice]) VALUES (1,N'Product1',1000.00000);
GO
INSERT INTO [Products] ([ProductId],[Name],[UnitPrice]) VALUES (2,N'Product2',2000.00000);
GO
INSERT INTO [Products] ([ProductId],[Name],[UnitPrice]) VALUES (3,N'Product3',3000.00000);
GO
SET IDENTITY_INSERT [Products] OFF;
GO
SET IDENTITY_INSERT [Orders] ON;
GO
INSERT INTO [Orders] ([OrderId],[OrderDate],[CustomerId]) VALUES (1,{ts '2011-01-07 11:25:20.000'},1);
GO
SET IDENTITY_INSERT [Orders] OFF;
GO
SET IDENTITY_INSERT [OrderItems] ON;
GO
INSERT INTO [OrderItems] ([OrderItemId],[Quntity],[ProductId],[OrderId]) VALUES (1,10,1,1);
GO
INSERT INTO [OrderItems] ([OrderItemId],[Quntity],[ProductId],[OrderId]) VALUES (2,5,2,1);
GO
INSERT INTO [OrderItems] ([OrderItemId],[Quntity],[ProductId],[OrderId]) VALUES (3,20,3,1);
GO
SET IDENTITY_INSERT [OrderItems] OFF;
GO
دریافت اطلاعات :
میخواهیم نام کلیه محصولات خریداری شده توسط مشتری‌ها را به همراه نام مشتری و زمان خرید مربوطه، نمایش دهیم (دریافت اطلاعات از 4 جدول بدون join نویسی):
var list = session.QueryOver<Customer>().List();
foreach (var customer in list)
{
foreach (var order in customer.Orders)
{
foreach (var orderItem in order.OrderItems)
{
Console.WriteLine("{0}:{1}:{2}", customer.Name, order.OrderDate, orderItem.Product.Name);
}
}
}
خروجی به صورت زیر خواهد بود:
Customer1:2011/01/07 11:25:20 :Product1
Customer1:2011/01/07 11:25:20 :Product2
Customer1:2011/01/07 11:25:20 :Product3
همانطور که مشاهده می‌کنید در اینجا اطلاعات از 4 جدول مختلف دریافت می‌شوند اما ما Join ایی را ننوشته‌ایم. ORM هرجایی که به اطلاعات فیلدهای جداول دیگر نیاز داشته، به صورت مستقیم به آن جدول مراجعه کرده و یک کوئری، حاصل این عملیات خواهد بود (مطابق تصویر جمعا 6 کوئری در پشت صحنه برای نمایش سه سطر خروجی فوق اجرا شده است).
این حالت فقط و فقط با تعداد رکورد کم بهینه است (و به همین دلیل هم تدارک دیده شده است). بنابراین اگر برای مثال قصد نمایش اطلاعات حاصل از 4 جدول فوق را در یک گرید داشته باشیم، بسته به تعداد رکوردها و تعداد کاربران همزمان برنامه (خصوصا در برنامه‌های تحت وب)، بانک اطلاعاتی باید بتواند هزاران هزار کوئری رسیده حاصل از lazy loading را پردازش کند و این یعنی مصرف بیش از حد منابع (IO بالا، مصرف حافظه بالا) به همراه بالا رفتن CPU usage و از کار افتادن زود هنگام سیستم.
کسانی که پیش از این با SQL نویسی خو گرفته‌اند احتمالا الان منابع موجود را در مورد نحوه‌ی نوشتن Join در NHibernate زیر و رو خواهند کرد؛ زیرا پیش از این آموخته‌اند که برای دریافت اطلاعات از دو یا چند جدول مرتبط باید Join نوشت. اما همانطور که پیشتر نیز عنوان شد، اگر با جزئیات کار با NHibernate آشنا شویم، نیازی به Join نویسی نخواهیم داشت. اینکار را خود ORM در پشت صحنه باید و می‌تواند مدیریت کند. اما چگونه؟
در NHibernate 3.0 با معرفی QueryOver که جایگزینی از نوع strongly typed همان ICriteria API قدیمی است، یا با معرفی Query که همان LINQ to NHibernate میباشد، متدی به نام Fetch نیز تدارک دیده شده است که استراتژی‌های lazy loading و eager loading را به سادگی توسط آن میتوان مشخص نمود.
مثال: دریافت اطلاعات با استفاده از QueryOver
var list = session
.QueryOver<Customer>()
.Fetch(c => c.Orders).Eager
.Fetch(c => c.Orders.First().OrderItems).Eager
.Fetch(c => c.Orders.First().OrderItems.First().Product).Eager
.List();
foreach (var customer in list)
{
foreach (var order in customer.Orders)
{
foreach (var orderItem in order.OrderItems)
{
Console.WriteLine("{0}:{1}:{2}", customer.Name, order.OrderDate, orderItem.Product.Name);
}
}
}
پشت صحنه:
اینبار فقط یک کوئری حاصل عملیات بوده و join ها به صورت خودکار با توجه به متدهای Fetch ذکر شده که حالت eager loading آنها صریحا مشخص شده است، تشکیل شده‌اند (6 بار رفت و برگشت به بانک اطلاعاتی به یکبار تقلیل یافت).
نکته 1: نتایج تکراری
اگر حاصل join آخر را نمایش دهیم، نتایجی تکراری خواهیم داشت که مربوط است به مقدار دهی customer با سه وهله از شیء مربوطه تا بتواند واکشی حریصانه‌ی مجموعه اشیاء فرزند آن‌را نیز پوشش دهد. برای رفع این مشکل یک سطر TransformUsing باید اضافه شود:
...
.TransformUsing(NHibernate.Transform.Transformers.DistinctRootEntity)
.List();
دریافت اطلاعات با استفاده از LINQ to NHibernate3.0
برای اینکه بتوان متدهای Fetch ذکر شده را به LINQ to NHibernate 3.0 اعمال نمود، ذکر فضای نام NHibernate.Linq ضروری است. پس از آن خواهیم داشت:
var list = session
.Query()
.FetchMany(c => c.Orders)
.ThenFetchMany(o => o.OrderItems)
.ThenFetch(p => p.Product)
.ToList();
اینبار از FetchMany، سپس ThenFetchMany (برای واکشی حریصانه مجموعه‌های فرزند) و در آخر از ThenFetch استفاده خواهد شد.
همانطور که ملاحظه می‌کنید حاصل این کوئری، با کوئری قبلی ذکر شده یکسان است. هر دو، اطلاعات مورد نیاز از دو جدول مختلف را نمایش می‌دهند. اما یکی در پشت صحنه شامل چندین و چند کوئری برای دریافت اطلاعات است، اما دیگری تنها از یک کوئری Join دار تشکیل شده است.
نکته 2: خطاهای ممکن
ممکن است حین تعریف متدهای Fetch در زمان اجرا به خطاهای Antlr.Runtime.MismatchedTreeNodeException و یا Specified method is not supported و یا موارد مشابهی برخورد نمائید. تنها کاری که باید انجام داد جابجا کردن مکان بکارگیری extension methods است. برای مثال متد Fetch باید پس از Where در حالت استفاده از LINQ ذکر شود و نه قبل از آن.
Top Issues Fixed in Visual Studio 2019 RC.1
- Visual Studio 2019 Preview 4 crash if closing undocked Window.
- Intellisense error: C++11 static constexpr member initialization causes "member may not be initialized".
- Start Page "Remove From List" stops working.
- $(VCIDEInstallDir) is an invalid path. Missing backslash in Microsoft.Cpp.Common.props.
- Visual Studio 2019 Preview 2.0+ crashes when opening soultion filter.
- Manage Extensions toolbar throws exception.
- Fixed rendering of the Import and Export Settings Wizard when running per-monitor aware
- Fixed sizing of the New Project Dialog when running per-monitor aware
- Made a set of visual refinements to the start window
در پروژه‌های ویندوزی یکی از بیشترین ابزار کاربردی گریدویو تلریک Telerik
GridView میباشد و اینکه تمامی امکانات گرید مانند گروه بندی ، فیلترینگ و
... همه فارسی باشند خیلی برای پروژه خوب است.
منم در یکی از پروژه‌ها نیاز به فارسی کردن این ابزار پرکاربرد ویندوزی داشتم و توانستم این مورد
را حل کنم . نحوه فارسی کردن این ابزار به شرح ذیل میباشد:
1- یک پروژه جدید ویندوزی در visual studio ایجاد میکنیم
public List<MyCustomData> GetData() {
List<MyCustomData> myList = new List<MyCustomData>();
for (int i = 1; i < 11; i++)
{
myList.Add(new MyCustomData() {
ID = i,
Name = "Name Family " + i.ToString(),
Age = 29
});
}
return myList;
}
public class MyCustomData
{
public int ID { get; set; }
public string Name { get; set; }
public int Age { get; set; }
public bool Sex { get; set; }
} 4 - حال برای اینکه این اطلاعات را در گرید نمایش دهیم کد زیر را در بخش Load_Form1 مینویسیم :
private void Form1_Load(object sender, EventArgs e)
{
radGridView1.DataSource = GetData();
} 
6 - برای اینکه این موارد فارسی شوند نیاز به یک کلاس یا Provider داریم که این عمل ترجمه را انجام دهد که حتی در سایت خود تلریک در بخش مربوطه نیز ارائه شده است. بنده این کلاس را کپی کرده و تمامی ترجمه‌های آنها را نیز نوشتم ( اگر در ترجمه ایرادی بود به بزرگی خودتان بخشیده و تصحیح نمائید . ) که کد آن را در زیر میتوانید در اختیار داشته باشید:
class PersianRadGridLocalizationProvider : RadGridLocalizationProvider
{
public override string GetLocalizedString(string id)
{
switch (id)
{
case RadGridStringId.FilterFunctionBetween: return "بین"; //Between
case RadGridStringId.FilterOperatorBetween: return "بین";
case RadGridStringId.FilterFunctionContains: return "حاوی";
case RadGridStringId.FilterOperatorContains: return "حاوی";
case RadGridStringId.FilterFunctionDoesNotContain: return "شامل نشود"; //Does not contain
case RadGridStringId.FilterOperatorDoesNotContain: return "شامل نشود";
case RadGridStringId.FilterFunctionEndsWith: return "پایان پذیرد با"; //Ends with
case RadGridStringId.FilterOperatorEndsWith: return "پایان پذیرد با";
case RadGridStringId.FilterFunctionEqualTo: return "برابر با"; //Equals
case RadGridStringId.FilterOperatorEqualTo: return "برابر با";
case RadGridStringId.FilterFunctionGreaterThan: return "بزرگتر از"; //Greater than
case RadGridStringId.FilterOperatorGreaterThan: return "بزرگتر از";
case RadGridStringId.FilterFunctionGreaterThanOrEqualTo: return "بزرگتر یا مساوی با"; //Greater than or equal to
case RadGridStringId.FilterOperatorGreaterThanOrEqualTo: return "بزرگتر یا مساوی با";
case RadGridStringId.FilterFunctionIsEmpty: return "خالی باشد"; //Is empty
case RadGridStringId.FilterOperatorIsEmpty: return "خالی باشد";
case RadGridStringId.FilterFunctionIsNull: return "تهی باشد"; //Is null
case RadGridStringId.FilterOperatorIsNull: return "تهی باشد";
case RadGridStringId.FilterFunctionLessThan: return "کمتر از"; //Less than
case RadGridStringId.FilterOperatorLessThan: return "کمتر از";
case RadGridStringId.FilterFunctionLessThanOrEqualTo: return "کمتر یا مساوی با"; //Less than or equal to
case RadGridStringId.FilterOperatorLessThanOrEqualTo: return "کمتر یا مساوی با";
case RadGridStringId.FilterFunctionNoFilter: return "بدون شرط"; //No filter
case RadGridStringId.FilterOperatorNoFilter: return "بدون شرط";
case RadGridStringId.FilterFunctionNotBetween: return "نباشد بین"; //Not between
case RadGridStringId.FilterOperatorNotBetween: return "نباشد بین"; //Operator
case RadGridStringId.FilterFunctionNotEqualTo: return "برابر نباشد با"; //Not equal to
case RadGridStringId.FilterOperatorNotEqualTo: return "برابر نباشد با";
case RadGridStringId.FilterFunctionNotIsEmpty: return "خالی نباشد"; //Is not empty
case RadGridStringId.FilterFunctionNotIsNull: return "خالی نباشد"; //Is not null
case RadGridStringId.FilterFunctionStartsWith: return "شروع شود با"; //Starts with
case RadGridStringId.FilterFunctionCustom: return "شرط دلخواه"; //Custom
case RadGridStringId.CustomFilterMenuItem: return "شرط دلخواه منو"; //Custom
case RadGridStringId.CustomFilterDialogCaption: return "انتخاب شرط دلخواه"; //RadGridView Custom Filter Dialog
case RadGridStringId.CustomFilterDialogLabel: return ":نشان دادن سطرهایی که"; //Show rows where:
case RadGridStringId.CustomFilterDialogRbAnd: return "و"; //And
case RadGridStringId.CustomFilterDialogRbOr: return "یا"; //Or
case RadGridStringId.CustomFilterDialogBtnOk: return "تایید"; //OK
case RadGridStringId.CustomFilterDialogBtnCancel: return "انصراف"; //Cancel
case RadGridStringId.AddNewRowString: return "برای افزودن سطر جدید اینجا کلیک کنید";
case RadGridStringId.ClearValueMenuItem: return "پاک کردن مقدار سلول";
case RadGridStringId.DeleteRowMenuItem: return "حذف سطر"; //Delete Row
case RadGridStringId.SortAscendingMenuItem: return "مرتب سازی صعودی"; //Sort Ascending
case RadGridStringId.SortDescendingMenuItem: return "مرتب سازی نزولی"; //Sort Descending
case RadGridStringId.ClearSortingMenuItem: return "حذف مرتب سازی"; //Clear Sorting
case RadGridStringId.ConditionalFormattingMenuItem: return "قالب بندی مشروط"; //Conditional Formatting
case RadGridStringId.GroupByThisColumnMenuItem: return "گروهبندی بر حسب این ستون"; //Group by this column
case RadGridStringId.UngroupThisColumn: return "حذف این ستون از گروهبندی "; //Ungroup this column
case RadGridStringId.ColumnChooserMenuItem: return "انتخابگر ستون"; //Column Chooser
case RadGridStringId.HideMenuItem: return "مخفی کردن ستون"; //Hide
case RadGridStringId.UnpinMenuItem: return "حالت پیش فرض"; //Unpin
case RadGridStringId.PinMenuItem: return "حالت ستون"; //Pin
case RadGridStringId.PinAtLeftMenuItem: return "چسپیدن به سمت چپ";
case RadGridStringId.PinAtRightMenuItem: return "چسپیدن به سمت راست";
case RadGridStringId.PinAtTopMenuItem: return "چسپیدن به بالا";
case RadGridStringId.PinAtBottomMenuItem: return "چسپیدن به پایین";
case RadGridStringId.BestFitMenuItem: return "اندازه بهینه ستون"; //Best Fit
case RadGridStringId.PasteMenuItem: return "چسپاندن"; //Paste
case RadGridStringId.EditMenuItem: return "ویرایش"; //Edit
case RadGridStringId.CopyMenuItem: return "کپی"; //Copy
case RadGridStringId.ConditionalFormattingCaption: return "قالب بندی مشروط"; //Custom Formatting Condition Editor
case RadGridStringId.ConditionalFormattingLblColumn: return "قالب بندی سلولهایی با شرط:"; //Column:
case RadGridStringId.ConditionalFormattingLblName: return "نام شرط:"; //Name:
case RadGridStringId.ConditionalFormattingLblType: return "مقدار سلول:"; //Type:
case RadGridStringId.ConditionalFormattingLblValue1: return "مقدار اول:"; //Value 1:
case RadGridStringId.ConditionalFormattingLblValue2: return "مقدار دوم:"; //Value 2:
case RadGridStringId.ConditionalFormattingGrpConditions: return "شرایط"; //Conditions
case RadGridStringId.ConditionalFormattingGrpProperties: return "مشخصات"; //Properties
case RadGridStringId.ConditionalFormattingChkApplyToRow: return "اعمال این شرط به کل سطر"; //Apply to row
case RadGridStringId.ConditionalFormattingBtnAdd: return "افزودن شرایط"; //Add
case RadGridStringId.ConditionalFormattingBtnRemove: return "حذف شرایط انتخابی"; //Remove
case RadGridStringId.ConditionalFormattingBtnOK: return "تایید"; //OK
case RadGridStringId.ConditionalFormattingBtnCancel: return "انصراف"; //Cancel
case RadGridStringId.ConditionalFormattingBtnApply: return "اعمال قالب بندی"; //Apply
case RadGridStringId.ColumnChooserFormCaption: return "انتخاب ستون ها"; //Column Chooser
case RadGridStringId.ColumnChooserFormMessage: return "برای حذف یکی از ستونها، آن ستون را به اینجا بکشید";//"Drag a column header from the grid here to remove it from the current view.";
case RadGridStringId.CompositeFilterFormErrorCaption: return "خطا";
case RadGridStringId.ConditionalFormattingChooseOne: return "[یکی را انتخاب کنید]";
case RadGridStringId.ConditionalFormattingContains: return "[حاوی [مقدار اول";
case RadGridStringId.ConditionalFormattingDoesNotContain: return "حاوی [مقدار اول] نباشد";
case RadGridStringId.ConditionalFormattingEndsWith: return "با [مقدار اول] پایان یابد";
case RadGridStringId.ConditionalFormattingEqualsTo: return "[برابر با [مقدار اول";
case RadGridStringId.ConditionalFormattingIsBetween: return "بین [مقدار اول] و [مقدار دوم] باشد";
case RadGridStringId.ConditionalFormattingIsGreaterThan: return "[بزرگتر از [مقدار اول";
case RadGridStringId.ConditionalFormattingIsGreaterThanOrEqual: return "[بزرگتر یا مساوی با [مقدار اول";
case RadGridStringId.ConditionalFormattingIsLessThan: return "کوچکتر از [مقدار اول]";
case RadGridStringId.ConditionalFormattingIsLessThanOrEqual: return "کوچکتر یا مساوی با [مقدار اول]";
case RadGridStringId.ConditionalFormattingIsNotBetween: return "بین [مقدار اول] و [مقدار دوم] نباشد";
case RadGridStringId.ConditionalFormattingIsNotEqualTo: return "برابر با [مقدار اول] نباشد";
case RadGridStringId.ConditionalFormattingRuleAppliesOn: return "اعمال شرایط روی:";
case RadGridStringId.ConditionalFormattingStartsWith: return "با [مقدار اول] شروع میشود";
case RadGridStringId.CustomFilterDialogCheckBoxNot: return "با این شرایط نباشد";
case RadGridStringId.CustomFilterDialogFalse: return "False";
case RadGridStringId.CustomFilterDialogTrue: return "True";
case RadGridStringId.FilterCompositeNotOperator: return "نباشد";
case RadGridStringId.FilterLogicalOperatorAnd: return "و";
case RadGridStringId.FilterLogicalOperatorOr: return "یا";
case RadGridStringId.FilterMenuAvailableFilters: return "فیلتر شده";
case RadGridStringId.FilterMenuButtonCancel: return "انصراف";
case RadGridStringId.FilterMenuButtonOK: return "تایید";
case RadGridStringId.FilterMenuClearFilters: return "پاک کردن فیلتر";
case RadGridStringId.FilterMenuSearchBoxText: return "جستجو...";
case RadGridStringId.FilterMenuSelectionAll: return "همه";
//case RadGridStringId.FilterMenuSelectionAllSearched: return "نتیجه همه جستجو";
case RadGridStringId.FilterMenuSelectionNotNull: return "خالی نباشد";
case RadGridStringId.FilterMenuSelectionNull: return "خالی باشد";
case RadGridStringId.FilterOperatorCustom: return "دلخواه";
case RadGridStringId.FilterOperatorIsLike: return "مانند";
case RadGridStringId.FilterOperatorNotIsContainedIn: return "نباشد در";
case RadGridStringId.FilterOperatorNotIsEmpty: return "خالی نباشد";
case RadGridStringId.FilterOperatorNotIsLike: return "نباشد شبیه";
case RadGridStringId.FilterOperatorNotIsNull: return "خالی نباشد";
case RadGridStringId.FilterOperatorStartsWith: return "شروع شود با";
case RadGridStringId.GroupingPanelDefaultMessage: return "برای گروهبندی ستونها، ستونی را به اینجا بکشید";
case RadGridStringId.GroupingPanelHeader: return ":گروهبندی بر حسب";
case RadGridStringId.NoDataText: return "داده ای برای نمایش وجود ندارد";
case RadGridStringId.UnpinRowMenuItem: return "حالت پیش فرض";
default:
return base.GetLocalizedString(id);
}
}
} 7 - حال اگر برنامه را اجرا کنید باز موارد انگلیسی گرید تلریک فارسی نمی‌شوند و باید در کلاس Program.cs پروژه این یک خط کد را هم اضافه نمائید.
//using Telerik.WinControls.UI.Localization; RadGridLocalizationProvider.CurrentProvider = new PersianRadGridLocalizationProvider();
8 - حال اگر برنامه را اجرا نمایید تمامی موارد را فارسی مشاهده خواهید نمود ( شکل ذیل )
لطفا ما را از نظرات سازنده خود بی نصیب نفرمائید. با تشکر
برای ایجاد «خواص الحاقی» قبلا در سایت مطلب ایجاد «خواص الحاقی» تهیه شده‌است. در این مطلب قصد داریم راه حل ارائه شده‌ی در مطلب مذکور را با یک TypeDescriptionProvider سفارشی ترکیب کرده تا به صورت یکدست، از طریق TypeDescriptor بتوان به آن خواص نیز دسترسی داشته باشیم.
فرض کنید در یک سیستم Modular Monolith، نیاز جدیدی به دست شما رسیده است که به شرح زیر میباشد:
نیاز داریم در گریدی از صفحه‌ی X مربوط به «مؤلفه 1»، ستونی جدید را اضافه کنید و دیتای مربوط به این ستون، توسط «مؤلفه 2» مهیا خواهد شد.
شرایط زیر می‌تواند در سیستم حاکم باشد:
- قبلا «مؤلفه 2» ارجاعی را به «مؤلفه 1» داده است؛ لذا امکان ارجاع معکوس را در این حالت، نداریم.
- «مؤلفه 1» باید بتواند مستقل از «مؤلفه 2» نیز توزیع شده و کار کند؛ لذا این نیاز برای زمانی است که «مؤلفه 2» برای توزیع در Component Model ما وجود داشته باشد.
- نمی‌خواهیم در آینده برای نیازهای مشابه در همان صفحه‌ی X، تغییر جدیدی را در «مؤلفه 1» داشته باشیم (اضافه کردن خصوصیت مورد نظر به مدل نمایشی یا اصطلاحا ویو-مدل متناظر با گرید در در زمان طراحی، جواب مساله نمی‌باشد)
- میخواهیم به یک طراحی با Loose Coupling (اتصال سست و ضعیف، وابستگی ضعیف) دست پیدا کنیم.
راه حل چیست؟
با توجه به شرایط حاکم، بدون شک برای مهیا کردن دیتای ستون مذکور نمی‌توان به «مؤلفه 2» مستقیما ارجاع داده و «مؤلفه 1» را به «مؤلفه 2» وابسته کنیم. از طرفی چه بسا در نیازهای آتی نیز لازم باشد ستون جدید دیگری برای نمایش دیتای خاصی در گرید مذکور، اضافه شود. راه حل پیشنهادی، معکوس سازی این وابستگی میباشد. به عنوان مثال با استفاده از Expose کردن یک Interface توسط «مؤلفه 1» و پیاده سازی آن توسط سایر مؤلفه‌ها و استفاده از این پیاده سازی‌ها در زمان اجرا، می‌تواند راه حلی برای این معکوس سازی باشد.
نمودار UML بالا، نشان دهنده‌ی راه حل پیشنهادی میباشد.
در این حالت «مؤلفه 1» بدون آگاهی از سایر مؤلفه‌ها، همه‌ی پیاده سازی‌های IExtraColumnConenvtion را در زمان اجرا یافته و از آنها برای ایجاد ستون‌های جدید، استفاده خواهد کرد.
واسط مذکور به شکل زیر میباشد:
public interface IConvention
{
}
public interface IExtraColumnConvention<T> : IConvention
{
string Name { get; }
string Title { get; }
void Populate(IEnumerable<T> list);
} البته این واسط می‌تواند جزئیات بیشتری را هم شامل شود.
گام اول: طراحی TypeDescriptionProvider
در .NET به دو طریق میتوان به متادیتای یک Type دسترسی داشت:
- استفاده از API Reflection موجود در فضای نام System.Reflection
- کلاس TypeDescriptor
به طور کلی هدف از این کلاس در دات نت، ارائه اطلاعاتی در خصوص یک وهله از جمله: Attributeها، Propertyها، Eventهای آن و غیره، میباشد. هنگام استفاده از Reflection، اطلاعات بدست آمده از Type، به دلیل اینکه بعد از کامپایل نمی‌توانند تغییر کنند، لذا قابلیت توسعه پذیری را هم ندارند. در مقابل، با استفاده از کلاس TypeDescriptor این توسعه پذیری را برای وهله‌های مختلف میتوانید داشته باشید.
برای مهیا کردن متادیتای سفارشی (در اینجا اطلاعات مرتبط با خصوصیات الحاقی) برای TypeDescriptor، نیاز است یک TypeDescriptionProvider سفارشی را طراحی کنیم.
/// <summary>
/// Use this provider when you need access ExtraProperties with TypeDescriptor.GetProperties(instance)
/// </summary>
public class ExtraPropertyTypeDescriptionProvider<T> : TypeDescriptionProvider where T : class
{
private static readonly TypeDescriptionProvider Default =
TypeDescriptor.GetProvider(typeof(T));
public ExtraPropertyTypeDescriptionProvider() : base(Default)
{
}
public override ICustomTypeDescriptor GetTypeDescriptor(Type instanceType, object instance)
{
var descriptor = base.GetTypeDescriptor(instanceType, instance);
return instance == null ? descriptor : new ExtraPropertyCustomTypeDescriptor(descriptor, instance);
}
private sealed class ExtraPropertyCustomTypeDescriptor : CustomTypeDescriptor
{
//...
}
} در تکه کد بالا، ابتدا تامین کننده‌ی پیش‌فرض مرتبط با نوع جنریک مورد نظر را یافته و به عنوان تامین کننده‌ی پایه معرفی کرده‌ایم. سپس برای معرفی CustomTypeDescritpr باید متد GetTypeDescriptor را بازنویسی کنیم. در اینجا لازم است برای معرفی متادیتا مرتبط با یک نوع، یک پیاده سازی از واسط ICustomTypeDescriptor را ارائه کنیم:
private sealed class ExtraPropertyCustomTypeDescriptor : CustomTypeDescriptor
{
private readonly IEnumerable<ExtraPropertyDescriptor<T>> _instanceExtraProperties;
public ExtraPropertyCustomTypeDescriptor(ICustomTypeDescriptor defaultDescriptor, object instance)
: base(defaultDescriptor)
{
_instanceExtraProperties = instance.ExtraPropertyList<T>();
}
public override PropertyDescriptorCollection GetProperties(Attribute[] attributes)
{
var properties = new PropertyDescriptorCollection(null);
foreach (PropertyDescriptor property in base.GetProperties(attributes))
{
properties.Add(property);
}
foreach (var property in _instanceExtraProperties)
{
properties.Add(property);
}
return properties;
}
public override PropertyDescriptorCollection GetProperties()
{
return GetProperties(null);
}
} متد الحاقی ExtraPropertList به شکل زیر پیاده‌سازی شده‌است:
public static class ExtraProperties
{
//...
public static IEnumerable<ExtraPropertyDescriptor<T>> ExtraPropertyList<T>(this object instance) where T : class
{
if (!PropertyCache.TryGetValue(instance, out var properties))
throw new KeyNotFoundException($"key: {instance.GetType().Name} was not found in dictionary");
return properties.Select(p =>
new ExtraPropertyDescriptor<T>(p.PropertyName, p.PropertyValueFunc, p.SetPropertyValueFunc,
p.PropertyType,
p.Attributes));
}
} در اینجا از همان مکانیزم افزودن خواص الحاقی که در ابتدای مطلب اشاره شد، استفاده شده است.
ExtraPropertyDescriptor به شکل زیر طراحی شده است:
public sealed class ExtraPropertyDescriptor<T> : PropertyDescriptor where T : class
{
private readonly Func<object, object> _propertyValueFunc;
private readonly Action<object, object> _setPropertyValueFunc;
private readonly Type _propertyType;
public ExtraPropertyDescriptor(
string propertyName,
Func<object, object> propertyValueFunc,
Action<object, object> setPropertyValueFunc,
Type propertyType,
Attribute[] attributes) : base(propertyName, attributes)
{
_propertyValueFunc = propertyValueFunc;
_setPropertyValueFunc = setPropertyValueFunc;
_propertyType = propertyType;
}
public override void ResetValue(object component)
{
}
public override bool CanResetValue(object component) => true;
public override object GetValue(object component) => _propertyValueFunc(component);
public override void SetValue(object component, object value) => _setPropertyValueFunc(component, value);
public override bool ShouldSerializeValue(object component) => true;
public override Type ComponentType => typeof(T);
public override bool IsReadOnly => _setPropertyValueFunc == null;
public override Type PropertyType => _propertyType;
} [TypeDescriptionProvider(typeof(ExtraPropertyTypeDescriptionProvider<Person>))]
private class Person
{
public string Name { get; set; }
public string Family { get; set; }
} [Test]
public void Should_TypeDescriptor_GetProperties_Returns_ExtraProperties_And_PredefinedProperties()
{
//Arrange
var rabbal = new Person {Name = "GholamReza", Family = "Rabbal"};
const string propertyName = "Title";
const string propertyValue = "Software Engineer";
//Act
rabbal.ExtraProperty(propertyName, propertyValue);
var title = TypeDescriptor.GetProperties(rabbal).Find(propertyName, true);
//Assert
rabbal.ExtraProperty<string>(propertyName).ShouldBe(propertyValue);
title.ShouldNotBeNull();
title.GetValue(rabbal).ShouldBe(propertyValue);
} گام دوم: استفاده از IExtraColumnConvention برای نمایش ستون‌های الحاقی
فرض کنیم 3 پیاده‌سازی از واسط IExtraColumnConvention را توسط مؤلفه‌های مختلف، به شکل داشته باشیم:
public class Column4Convention : IExtraColumnConvention<Product>
{
public string Name => "Column4";
public string Title => "Column 4"
public void Populate(IEnumerable<Product> list)
{
//TODO: forEach on list and set ExtraProperty
// item.ExtraProperty(Name,value)
// item.ExtraProperty(Name,(obj)=> value)
// item.ExtraProperty(Name,(obj)=> value, (obj,value)=>)
}
}
public class Column2Convention : IExtraColumnConvention<Product>
{
public string Name => "Column2";
public string Title => "Column 2"
public void Populate(IEnumerable<Product> list)
{
//TODO: forEach on list and set ExtraProperty
}
}
public class Column3Convention : IExtraColumnConvention<Product>
{
public string Name => "Column3";
public string Title => "Column 3"
public void Populate(IEnumerable<Product> list)
{
//TODO: forEach on list and set ExtraProperty
}
} سپس این پیاده‌سازی‌ها از طریق مکانیزمی مانند معرفی آنها به یک IoC Container، توسط میزبان (مؤلفه 1) قابل دسترسی خواهد بود. در نهایت میزبان، قبل از نمایش محصولات، به شکل زیر عمل خواهد کرد:
var products = _productService.PagedList(page:1, pageSize:10);
var columns = _provider.GetServices<IExtraColumnConvention<Product>>();
foreach(var column in columns)
{
column.Populate(products);
} از این پس خصوصیات الحاقی اضافه شده‌ی توسط مؤلفه‌های دیگر نیز جزئی از خصوصیات محصولات بوده و از طریق TypeDescriptor.GetProperties قابل دسترسی میباشد. البته مشخص است راهکاری که در اینجا مطرح شد، وابستگی خیلی زیادی را به مکانیزم استفاده شده در لایه Presentation برای نمایش اطلاعات دارد.
نکته: امکان تهیه ContractResolver سفارشی برای کتابخانه JSON.NET به منظور Serialize خواص الحاقی اضافه شده در زمان اجرا، نیز وجود دارد.
تامین کننده طراحی شده‌ی در این مطلب، به زیرساخت DNTFrameworkCore اضافه شد.
in Angular 1.x we had this:
- Angular 1.0 - major version
- Angular 1.1 - major version (well, more a preview of Angular 1.2)
- Angular 1.2 - major version
- Angular 1.3 - major version (dropped IE8 support)
- Angular 1.4 - major version
- Angular 1.5 - major version
In “Angular 2”, you’re looking at this:
- Angular 2 - major version
- Angular 3 - major version
- Angular 4 - major version
- Angular 5 - major version
- Angular 6 - major version
- Angular 7 - major version
تهیه پیش‌نیازهای شروع به کار با ASP.NET MVC
در زمان نگارش این مطلب، نگارش نهایی ASP.NET MVC 3 در دسترس است و همچنین نگارش بتای 4 آن نیز قابل دریافت و نصب میباشد. بنابراین فعلا اساس را بر مبنای نگارشی قرار خواهیم داد که در محیط کاری قابل استفاده باشد.
ASP.NET MVC 3 پس از ارائه Visual Studio 2010، منتشر شد و VS.NET به صورت پیش فرض به همراه ASP.NET MVC 2 است. ساده‌ترین روش نصب ASP.NET MVC 3 بر روی VS 2010 استفاده از برنامه رایگانی است به نام Web Platform Installer. این برنامه را از این آدرس میتوان دریافت کرد: http://microsoft.com/web/downloads
پس از دریافت آن حداقل دو راه برای نصب ASP.NET MVC 3 وجود دارد. یا گزینه‌ی نصب ASP.NET MVC 3 Tools Update را انتخاب کنید و یا سرویس پک یک VS 2010 را از طریق این برنامه یا جداگانه (بسته کامل و مستقل) دریافت و نصب نمائید. VS 2010 SP1 نیز به همراه ASP.NET MVC 3 است؛ همچنین IIS Express را که نسخه ساده شده IIS 7.5 مخصوص توسعه دهنده‌ها است، میتوان با این نگارش یکپارچه کرد.
بنابراین به صورت خلاصه بهترین کار این است که سرویس پک یک VS 2010 را یکبار نصب نمائید. اگر این نصب از طریق برنامه Web Platform Installer باشد، به صورت خودکار IIS Express را هم انتخاب و نصب خواهد کرد. اگر فقط SP1 را به صورت مستقل دریافت کرده‌اید، حاوی IIS Express نیست و باید جداگانه آن‌را دریافت و نصب نمائید (^). البته نصب IIS Express در اینجا یک گزینه اختیاری است و الزامی نیست.
مروری بر ساختار یک پروژه ASP.NET MVC
پس از نصب پیش نیازها، امکان انتخاب یک پروژه وب ASP.NET MVC 3 در VS 2010 میسر خواهد شد:
در اینجا گزینه‌ی ASP.NET MVC 3 Web Application را انتخاب میکنیم. در صفحه بعدی که ظاهر میشود:
حالت Internet Application به همراه یک سری مدل و کنترلر از پیش نوشته شده جهت مدیریت ورود به سایت و ثبت نام در سایت است و حالت Empty تنها به همراه ساختار پیش فرض پوشه‌های یک پروژه ASP.NET MVC است.
فعلا جهت توضیحات اولیه بیشتر، گزینه‌ی Internet Application و نوع View Engine را هم ASPX انتخاب میکنیم. کار View Engine، رندر یک View به شکل HTML و ارائه نهایی اطلاعات آن به کاربر است. این نوع‌های متفاوت هم فقط در Syntax تفاوت دارند (به آن templating language هم گفته میشود). نوع ASPX همان Syntax متداول قدیمی ASP.NET را تداعی می‌کند و نوع Razor به صورت اختصاصی برای ASP.NET MVC تهیه شده است.
باید در نظر داشت که گزینه مرجح از نگارش 3 به بعد، Razor است (البته این هم سلیقه‌ای است. اگر هیچکدام از این دو را هم نخواهید استفاده کنید مشکلی نیست! میشود کلا آن را عوض کرد). هدفم هم از انتخاب ASPX نمایش یک سری ریزه کاری است که شاید برای برنامه نویس‌های ASP.NET Web forms جالب باشد. این موارد را در حالت انتخاب Razor به این وضوح مشاهده نخواهید کرد و محیط خیلی ساده شده است.
همانطور که ملاحظه می‌کنید این فریم ورک یک سری پوشه پیش فرض را توصیه می‌کند. بدیهی است که ضرورتی ندارد تا پوشه Models یا پوشه Controllers حتما در همین پروژه قرار داشته باشند؛ چون زمانیکه پروژه کامپایل شد، محل این پوشه بندی‌ها آنچنان اهمیتی ندارد.
نکته جالب در این تصویر، فایل Site.Master است. بله، این فایل شبیه به همان فایل master page موجود در ASP.NET Web form است که قالب کلی سایت را به همراه داشته و سایر صفحات، قالب خود را از آن به ارث می‌برند. حتی تگ runat=server هم به وضوح در این فایل، در چندین جای آن قابل مشاهده است. تنها تفاوت آن نداشتن فایل code behind است. asp:ContentPlaceHolder نیز در آن تعریف شده است. خلاصه این محیط جدید به معنای دور ریختن تمام آنچیزی که در Web forms وجود دارد نیست. برای نمونه اگر فایل ChangePassword.aspx موجود در پوشه Account را باز کنید، باز هم همان asp:Content معروف به همراه تگ runat=server قابل مشاهده است. برای مثال این محتوای صفحه Error.aspx پیش فرض آن است:
<%@ Page Language="C#" MasterPageFile="~/Views/Shared/Site.Master"
Inherits="System.Web.Mvc.ViewPage<System.Web.Mvc.HandleErrorInfo>" %>
<asp:Content ID="errorTitle" ContentPlaceHolderID="TitleContent" runat="server">
Error
</asp:Content>
<asp:Content ID="errorContent" ContentPlaceHolderID="MainContent" runat="server">
<h2>
Sorry, an error occurred while processing your request.
</h2>
</asp:Content>
اگر از قسمت Inherits آن صرفنظر کنیم، «هیچ» تفاوتی با ASP.NET Web forms ندارد؛ علت هم به این بر می‌گردد که موتوری که Web forms و MVC از آن استفاده می‌کنند، یکی است. هر دو بر فراز موتور ASP.NET معنا پیدا خواهند کرد.
قرار دادهای پوشه‌های پیش فرض یک پروژه ASP.NET MVC
- پوشه Controllers حاوی کلاس‌های کنترلری است که درخواست‌های رسیده را مدیریت می‌کنند.
- پوشه Models حاوی کلاس‌هایی است که اشیاء تجاری و همچنین کار با اطلاعات را تعریف و مدیریت می‌کنند.
- در پوشه Views، فایل‌های قالب‌های رابط کاربری که مسئول ارائه خروجی به کاربر هستند قرار می‌گیرند. همچنین مطابق قرارداد دیگری، اگر نام کنترلر ما مثلا ProductController باشد (با توجه به اینکه نام کلاس آن هم مطابق قرارداد، مختوم به کلمه Controller است)، فایل‌های Viewهای مرتبط با آن در پوشه Views/Product قرار خواهند گرفت.
- در پوشه Scripts، فایل‌های جاوا اسکریپت مورد استفاده در سایت قرار خواهند گرفت.
- پوشه Content محل قرارگیری فایل‌های CSS و تصاویر است.
- پوشه App_Data جایی است که فایل‌هایی با قابلیت read/write در آن قرار می‌گیرند (و باید دقت داشت که فقط همینجا هم باید قرار گیرند و گرنه این نوشتن‌ها در مکان‌های متفرقه، ممکن است سبب ری استارت شدن برنامه شوند:(^)).
در قسمت قبل با الگوریتم Naive Bayes به عنوان الگوریتمی جهت شروع امر داده کاوی آشنا شدیم. در این قسمت به الگوریتم‌های Decision trees و Linear Regression می‌پردازیم.
مقدمه
خودتان را جای یک متصدی اعطای وام بانکی درنظر بگیرید. یک زوج جوان برای دریافت وام به بانک مراجعه می‌کنند. برای اعطای وام، ممکن است جوان بودن آنها یک علامت مثبت نباشد. حال شما شروع به مصاحبه با آنها می‌کنید و متوجه می‌شوید که ازدواج کرده‌اند. متاهل بودن آنها یک نکته مثبت است. همچنین متوجه می‌شوید که هر دو یک شغل دارند و به مدت سه سال است که مشغول همان کار هستند. درست حدس زدید، پایداری شغل می‌تواند یک نکته مثبت باشد. پس از بررسی حساب بانکی آنها متوجه می‌شوید که در یکسال اخیر سه چک برگشتی دارند. این موضوع، یک منفی بزرگ را سر راه قرار می‌دهد. درنهایت، شما جهت تصمیم گیری برای اعطای وام، براساس تجربه کاری خود در ذهنتان یک درخت ایجاد می‌کنید که رتبه بندی امتیاز برای اعطای وام را تسهیل می‌کند. کاری که الگوریتم Decision Trees انجام می‌دهد شبیه به همین کار است.
چرا الگوریتم درخت تصمیم؟
این الگوریتم به دلایل سرعت و کارآیی بالا در آماده سازی داده‌ها و دقت بالا و درک راحت الگو توسط انسان، محبوب‌ترین تکنیک داده کاوی است. رایج‌ترین کاری که معمولا با استفاده از این الگوریتم انجام می‌گردد دسته بندی داده‌ها است. برای مثال متقاضی وام می‌تواند به دو دسته با درجه ریسک پایین و درجه ریسک بالا تقسیم شود و این الگوریتم به ما کمک می‌کند تا قاعده‌ای برای انجام این دسته بندی بر اساس داده‌های قبلی پیدا نماییم.
تفسیر الگوریتم
درختی که توسط این الگوریتم تولید میشود به شکل زیر تفسیر می‌گردد: هر نود شامل یک نوار هیستوگرام (پیشینه نما) با رنگ‌های مختلف میباشد که حالات مختلفی از خروجی را نشان می‌دهد. هر مسیر از ریشه به یک نود یک قاعده را شرح می‌دهد.
شرح نوار ابزار
- کمبوی مربوط به ،Tree شامل درخت‌های تصمیم مربوط به خروجی‌ها (ویژگی‌هایی که میخواهیم
پیش بینی کنیم) میباشد.
- Default Expansion اندازه درخت را مشخص می‌کند. به عبارتی مشخص می‌کند که درخت چند
سطحی باشد.
- هیستوگرام تعداد حالات ویژگی قابل پیش بینی را مشخص می‌کند که از طریق
آن میتوان در یک نگاه با توجه به رنگ حالت مورد نظر در هر نود، یک مسیر مشخص را
در درخت طی کرد. برای مثال فرض کنید که یک ویژگی دارای 10 حالت باشد که برای شما 5
حالت از این 10 حالت مهمتر است. بنابراین تعداد را روی 5 تنظیم میکنیم. مابقی
حالات در یک گروه قرار گرفته به رنگ خاکستری نشان داده می‌شوند.
- کمبوی Background جهت کنترل رنگ پیش زمینه نودها میباشد. در حالت پیش فرض، این کمبو تمامی حالات ویژگی مورد پیش بینی را در نظر می‌گیرد. در این حالت رنگ تیره‌تر نود نشان دهنده تعداد موردها در آن نود میباشد. هرچه این رنگ تیره‌تر باشد، یعنی موارد بیشتری در آن دسته قرار می‌گیرند. شما همچنین میتوانید یک حالت خاص از ویژگی مورد پیش بینی را انتخاب کنید. در این حالت رنگ پس زمینه هر نود احتمال پیش بینی با توجه به حالت انتخاب شده را نشان می‌دهد. نود با پس زمینه پر رنگ‌تر احتمال بالاتری با توجه به حالت انتخاب شده دارد.
آموزش بیش از اندازه
این الگوریتم، درخت را به صورت بازگشتی رشد می‌دهد. درنتیجه گاهی اوقات ممکن است که با یک درخت بزرگ مواجه شوید. این درخت می‌تواند شامل سطح‌ها و شاخه‌های زیادی باشد. بنابراین شامل قوانین زیادی هم خواهد بود. اما در نظر داشته باشید که ارتباط مستقیمی بین کیفیت پیش بینی و اندازه درخت وجود ندارد. حقیقت امر این است، هرگاه که درخت بیش از اندازه عمیق شود، بجای اینکه تعمیم قوانین صورت گیرد، آموزش حالات مختلف نشان داده میشود و این خوب نیست. الگوریتم درخت تصمیم مایکروسافت ویژگی دارد به نام forward pruning که رشد درخت را با استفاده از امتیاز بایزین کنترل می‌کند. به عبارتی زمانیکه اطلاعات کافی برای بخش کردن یک نود وجود نداشته باشد، از این امر جلوگیری می‌کند. این کار توسط پارامتر Complexity_Penalty انجام می‌گردد که مقداری اعشاری بین 0 و 1 را می‌گیرد. هرچه مقدار بالاتری به این پارامتر اختصاص داده شود، محدودیت بیشتری برای تقسیم درخت درنظر گرفته میشود و بنابراین سایز درخت کوچکتر می‌گردد.
پارامترهای الگوریتم درخت تصمیم
دسترسی به این پارامترها از طریق تب mining models امکان پذیر میباشد. با کلیک بر روی الگوریتم پنجره، properties آن نمایش داده خواهد شد حال میتوان به بخش Algorithm Parameters رفت و پارامترها را مقداردهی کرد.
Complexity_Penalty : که توضیح آن در بخش "آموزش بیش از اندازه" آورده شد.
Minimum_Support : جهت تعیین مینیمم اندازه هر نود به کار می‌رود. برای مثال اگر مقدار 20 را به آن بدهیم، آنگاه هر تقسیم بندی که منجر به تولید نودهای فرزندی با اندازه کمتر از 20 شود، انجام نمی‌گردد. اغلب در مواردی که مجموعه داده دارای حالات گوناگون زیادی است، میتوان مقدار این متغیر را بالا برد تا از آموزش بیش از اندازه جلوگیری کرد. پیش فرض این پارامتر 10 میباشد.
Score_Method : این پارامتر مشخص می‌کند که از کدام روش برای محاسبه امتیاز جهت بخش بندی درخت استفاده کنیم. سه مقدار 1، 3 و 4 را می‌گیرد. 1 از امتیاز انتروپی استفاده می‌کند، 3 از بایزین k2 و 4 از بایزین Dirichlet equivalent .
Split_Method : سه مقدار 1 تا 3 را می‌گیرد. فرض کنید که وضعیت تحصیل در یک مجموعه داده سه حالت را دارد: دیپلم، لیسانس، فوق لیسانس. اگر مقدار 1 را برای این پارامتر تعیین نماییم آنگاه حالت دودویی برای تقسیم نودها درخت درنظر گرفته میشود. یعنی دو حالت دیپلم و غیر دیپلم. حال اگر مقدار 2 را نظر بگیریم آنگاه تقسیم نودها براساس تمامی حالات درنظر گرفته میشود؛ در اینجا سه تا. مقدار 3 که مقدار پیش فرض نیز میباشد، انتخاب حالت 1 یا 2 را به عهده الگوریتم می‌گذارد.
Maximum_Input_Attributes : ماکزیمم ورودی را میتوان از این طریق تعیین کرد. اگر تعداد ورودی‌ها بیشتر از این مقدار باشد، آنگاه فقط ورودی‌های مهم درنظر گرفته شده و مابقی نادیده گرفته می‌شوند.
Linear Regression:
این الگوریتم شبیه الگوریتم درخت تصمیم است. به همین دلیل هم در این مقاله گنجانده شده‌است؛ البته با این تفاوت که نوار هیستوگرام ندارد و در عوض دارای یک نوار الماسی است که توزیع متغیرهای قابل پیش بینی را نشان می‌دهد. این الگوریتم فقط برای ویژگی‌های continuous کاربرد دارد. خود الماس نیز نشان دهنده توزیع مقدار نود میباشد. عرض الماس دوبرابر انحراف معیار میباشد. بنابراین اگر الماس نازک باشد، پیش بینی برپایه آن نود دقیق‌تر است. هر نود شامل یک فرمول رگرسیون است که میتوان از آن در داده کاوی بهره جست.
می‌دانیم بهینه‌سازی موتورهای جستجو (به انگلیسی: Search engine optimization (SEO)) که گاهی در فارسی به آن سئو نیز گفته میشود، عملیاتی است برای بهبود دید یک وب‌گاه یا یک صفحهٔ وب، در صفحه نتایج موتورهای جستجو که می‌تواند طبیعی و یا الگوریتمی باشد. این عملیات برای وبمسترها یکی از عوامل مهم و حیاتی بدست آوردن کاربران جدید از موتورهای جستجو است.
اگر چک لیست‌های SEO وب سایت ها را مشاهده کنیم، می‌توانیم آنها را در دو دسته‌ی کلی بهینه سازی درونی و برونی وب سایت در نظر بگیریم:
Off-Page Optimization یا برونی ، که بیشتر بر دوش مشاوران سئو و خود مدیران وب سایت است.(link building ، فعالیت در شبکه اجتماعی و ...)
و اما در حوزه On-Page Optimization یا درونی که بخش‌های مهمی از آن وظیفه‌ی مابرنامه نویس‌ها است.(H1 Tag ، URL Naming ، Meta Tags ، عنوان صفحه و ...)
[البته عامل درونی بهینه سازی محتوا (Content Optimization) که مهمترین عامل در الگوریتم‌های نسل جدید موتورهای جستجو و همچنین الگوریتم جدید گوگل (و +) به حساب می‌آید بر عهده مشاوران سئو و خود مدیران وب سایت میباشد]
در ادامه به ارائه چند راهکار جهت بهینه سازی برنامه‌های وب ASP.NET مان برای موتورهای جستجو می‌پردازیم:
1.متدی برای ایجاد عنوان سایت
نکته :
2.متدی برای ایجاد متاتگ صفحات سایت
چند نکته :
3.متدی برای ایجاد Slug ( اسلاگ آدرسی با مفهوم برای بکار بردن در URL ها است که دوست‌دار موتورهای جستجو میباشد)
نکته :
نمونه ای از کاربرد توابع :
و خروجی در Page Source :
موفق باشید
اگر چک لیست‌های SEO وب سایت ها را مشاهده کنیم، می‌توانیم آنها را در دو دسته‌ی کلی بهینه سازی درونی و برونی وب سایت در نظر بگیریم:
Off-Page Optimization یا برونی ، که بیشتر بر دوش مشاوران سئو و خود مدیران وب سایت است.(link building ، فعالیت در شبکه اجتماعی و ...)
و اما در حوزه On-Page Optimization یا درونی که بخش‌های مهمی از آن وظیفه‌ی مابرنامه نویس‌ها است.(H1 Tag ، URL Naming ، Meta Tags ، عنوان صفحه و ...)
[البته عامل درونی بهینه سازی محتوا (Content Optimization) که مهمترین عامل در الگوریتم‌های نسل جدید موتورهای جستجو و همچنین الگوریتم جدید گوگل (و +) به حساب می‌آید بر عهده مشاوران سئو و خود مدیران وب سایت میباشد]
در ادامه به ارائه چند راهکار جهت بهینه سازی برنامه‌های وب ASP.NET مان برای موتورهای جستجو می‌پردازیم:
1.متدی برای ایجاد عنوان سایت
private const string SeparatorTitle = " - ";
private const int MaxLenghtTitle = 60;
public static string GeneratePageTitle(params string[] crumbs)
{
var title = "";
for (int i = 0; i < crumbs.Length; i++)
{
title += string.Format
(
"{0}{1}",
crumbs[i],
(i < crumbs.Length - 1) ? SeparatorTitle : string.Empty
);
}
title = title.Substring(0, title.Length <= MaxLenghtTitle ? title.Length : MaxLenghtTitle).Trim();
return title;
} - MaxLenghtTitle پیشنهادی برای عنوان سایت 60 میباشد.
2.متدی برای ایجاد متاتگ صفحات سایت
public enum CacheControlType
{
[Description("public")]
_public,
[Description("private")]
_private,
[Description("no-cache")]
_nocache,
[Description("no-store")]
_nostore
}
private const int MaxLenghtTitle = 60;
private const int MaxLenghtDescription = 170;
private const string FaviconPath = "~/cdn/ui/favicon.ico";
public static string GenerateMetaTag(string title, string description, bool allowIndexPage, bool allowFollowLinks, string author = "", string lastmodified = "", string expires = "never", string language = "fa", CacheControlType cacheControlType = CacheControlType._private)
{
title = title.Substring(0, title.Length <= MaxLenghtTitle ? title.Length : MaxLenghtTitle).Trim();
description = description.Substring(0, description.Length <= MaxLenghtDescription ? description.Length : MaxLenghtDescription).Trim();
var meta = "";
meta += string.Format("<title>{0}</title>\n", title);
meta += string.Format("<link rel=\"shortcut icon\" href=\"{0}\"/>\n", FaviconPath);
meta += string.Format("<meta http-equiv=\"content-language\" content=\"{0}\"/>\n", language);
meta += string.Format("<meta http-equiv=\"content-type\" content=\"text/html; charset=utf-8\"/>\n");
meta += string.Format("<meta charset=\"utf-8\"/>\n");
meta += string.Format("<meta name=\"description\" content=\"{0}\"/>\n", description);
meta += string.Format("<meta http-equiv=\"Cache-control\" content=\"{0}\"/>\n", EnumExtensions.EnumHelper<CacheControlType>.GetEnumDescription(cacheControlType.ToString()));
meta += string.Format("<meta name=\"robots\" content=\"{0}, {1}\" />\n", allowIndexPage ? "index" : "noindex", allowFollowLinks ? "follow" : "nofollow");
meta += string.Format("<meta name=\"expires\" content=\"{0}\"/>\n", expires);
if (!string.IsNullOrEmpty(lastmodified))
meta += string.Format("<meta name=\"last-modified\" content=\"{0}\"/>\n", lastmodified);
if (!string.IsNullOrEmpty(author))
meta += string.Format("<meta name=\"author\" content=\"{0}\"/>\n", author);
//------------------------------------Google & Bing Doesn't Use Meta Keywords ...
//meta += string.Format("<meta name=\"keywords\" content=\"{0}\"/>\n", keywords);
return meta;
} -
MaxLenghtDescription پیشنهادی برای متاتگ توضیح سایت 170 می باشد.
- آشنایی با متاتگ‌ها (Meta tags) و کاربرد آنها در صفحات وب (HTML)
- برای کاربرد allowIndexPage و allowFollowLinks هم میتوانید به لینک بالا و بررسی متاتگ robots بپردازید.
- با توجه به اهمیت شبکه‌های اجتماعی متاتگ‌های شبکه‌های اجتماعی (+ و +) را هم نباید از قلم انداخت.
- برای دریافت Description نوع سفارشی CacheControlType از پروژه متدهای الحاقی علیرضا اسم رام استفاده کردم.
3.متدی برای ایجاد Slug ( اسلاگ آدرسی با مفهوم برای بکار بردن در URL ها است که دوست‌دار موتورهای جستجو میباشد)
private const int MaxLenghtSlug = 45;
public static string GenerateSlug(string title)
{
var slug = RemoveAccent(title).ToLower();
slug = Regex.Replace(slug, @"[^a-z0-9-\u0600-\u06FF]", "-");
slug = Regex.Replace(slug, @"\s+", "-").Trim();
slug = Regex.Replace(slug, @"-+", "-");
slug = slug.Substring(0, slug.Length <= MaxLenghtSlug ? slug.Length : MaxLenghtSlug).Trim();
return slug;
}
private static string RemoveAccent(string text)
{
var bytes = Encoding.GetEncoding("UTF-8").GetBytes(text);
return Encoding.UTF8.GetString(bytes);
} - MaxLenghtSlug پیشنهادی برای عنوان سایت 45 میباشد.
نمونه ای از کاربرد توابع :
Head.InnerHtml = SEO.GenerateMetaTag
(
title: SEO.GeneratePageTitle(".NET Tips", "آرشیو مطالب", "ASP.NET MVC #1"),
description: "چرا ASP.NET MVC با وجود فریم ورک پخته‌ای به نام ASP.NET web forms، اولین سؤالی که حین سوئیچ به ASP.NET MVC مطرح میشود این است: «برای چی؟». بنابراین تا به این سؤال پاسخ داده نشود، هر نوع بحث فنی در این مورد بی فایده است.",
allowIndexPage: true,
allowFollowLinks: true,
author: "وحید نصیری",
cacheControlType: SEO.CacheControlType._private
);
<title>.NET Tips - آرشیو مطالب - ASP.NET MVC #1</title> <link rel="shortcut icon" href="../../cdn/images/ui/favicon.ico"/> <meta http-equiv="content-language" content="fa"/> <meta http-equiv="content-type" content="text/html; charset=utf-8"/> <meta charset="utf-8"/> <meta name="description" content="چرا ASP.NET MVC ؟با وجود فریم ورک پخته‌ای به نام ASP.NET web forms، اولین سؤالی که حین سوئیچ به ASP.NET MVC مطرح میشود این است: «برای چی؟». بن ..."/> <meta http-equiv="Cache-control" content="private"/> <meta name="robots" content="index, follow" /> <meta name="expires" content="never"/> <meta name="author" content="وحید نصیری"/>
وقتی ما تست‌های Unit - Integration - UI را مینویسیم، به طور معمول پیش می‌آید که بخواهیم آبجکتی را نیز از نوع DateTime، اثبات کنیم (Assert.That). وقتی دو DateTime را با هم مقایسه میکنیم، معمولا این دو به خاطر ثانیه و یا میلی ثانیه با هم برابر نمی‌شوند. به همین دلیل ما به راه بهتری برای مقایسه نیاز داریم. برای مثال اگر بخواهیم دو تاریخ زیر را مقایسه کنیم:
این دو تاریخ تقریبا با هم برابرند و تنها 1 ثانیه با هم اختلاف دارند. در بیشتر موارد 1 ثانیه مسئله مهمی نیست و قابل چشم پوشی میباشد. بنابراین ما نیاز به متدی برای اثبات داریم که بتوانیم آن را برای چشم پوشی از 1 ثانیه اختلاف، تنظیم کنیم.
بنابراین نیازی به پیاده سازی متد سفارشی نیست.
برای استفاده:
2016-11-13 21:03:20 <=> 2016-11-13 21:03:21
چگونگی اثبات کردن DateTime در NUnit
NUnit با استفاده از کلمه کلیدی Within این کار را به صورت کامل پشتیبانی کرده است.DateTime now = DateTime.Now; DateTime later = now + TimeSpan.FromHours(1.0); Assert.That( now, Is.EqualTo(now) ); Assert.That( later, Is.EqualTo(now).Within( TimeSpan.FromHours(3.0) ) ); Assert.That( later, Is.EqualTo(now).Within(3).Hours );
چگونگی اثبات کردن DateTime در MSTest
با استفاده از متد AreEqual در کلاس زیر میتوان دو تاریخ را با هم مقایسه کرد و میزان اختلاف قابل چشم پوشی را نیز با استفاده از پارامتر maximum تعیین کرد.public static class DateTimeAssert
{
public static void AreEqual( DateTime? expectedDate,
DateTime? actualDate,
TimeSpan maximum )
{
if ( expectedDate == null && actualDate == null )
return;
if ( expectedDate == null )
throw new NullReferenceException( "The expected date was null" );
if ( actualDate == null )
throw new NullReferenceException( "The actual date was null" );
var totalSecondsDifference = Math.Abs( ( actualDate.Value - expectedDate.Value ).TotalSeconds );
if ( totalSecondsDifference > maximum.TotalSeconds )
{
throw new Exception( $"Expected Date: {expectedDate}, Actual Date: {actualDate} Expected: {maximum}, Total Seconds Difference: {totalSecondsDifference}" );
}
}
} DateTimeAssert.AreEqual( new DateTime(2016, 11, 12, 21, 4, 5),
new DateTime(2016, 11, 13, 21, 4, 5),
TimeSpan.FromMilliSeconds(500));
DateTimeAssert.AreEqual( new DateTime(2016, 11, 12, 21, 4, 5),
new DateTime(2016, 11, 13, 21, 4, 5),
TimeSpan.FromMinutes(0.5)); // half a minute = 30s