نظرات مطالب
دریافت خلاصهی وبلاگ تا اول اسفند 87
استاد عزیز سلام، سپاس از همه مطالب خوبی ارائه میدهید. من هر روز وبلاگ شما را دنبال میکنم.
فایل را دریافت کردم اما با مشکل به عبارتی درست دانلود نمیکند و در زمان باز کردنش پیغام :Cannot open the file را میدهد که این پیغام در یک Box با عنوان Help است.
آیا راهی وجود دارد تا از محتویات این فایل بهرهمند شوم؟
با سپاس از راهنمایی شما . . .
فایل را دریافت کردم اما با مشکل به عبارتی درست دانلود نمیکند و در زمان باز کردنش پیغام :Cannot open the file را میدهد که این پیغام در یک Box با عنوان Help است.
آیا راهی وجود دارد تا از محتویات این فایل بهرهمند شوم؟
با سپاس از راهنمایی شما . . .
اگر به گوگل ریدر دقت کرده باشید، دو گزینهی به اشتراک گذاری دارد: share و share with note .
اگر گزینهی share with note را انتخاب کرده و توضیحی را ارسال یا اضافه کنیم، این توضیحات، به فید از نوع Atom اشتراکها هم اضافه میشود. مثلا:
<?xml version="1.0"?>
<feed xmlns:media="http://search.yahoo.com/mrss/"
xmlns:gr="http://www.google.com/schemas/reader/atom/"
xmlns:idx="urn:atom-extension:indexing"
xmlns="http://www.w3.org/2005/Atom"
idx:index="no"
gr:dir="ltr">
...
<entry gr:crawl-timestamp-msec="1316627782108">
...
<gr:annotation>
<content type="html">text-text-text</content>
<author>
<name>Vahid</name>
</author>
</gr:annotation>
...
</entry>
...
</feed>
این افزونه استاندارد نیست و همانطور که در قسمت xmlns:gr اطلاعات فوق مشخص است، در فضای نام http://www.google.com/schemas/reader/atom/ معنا پیدا میکند. از دات نت سه و نیم به بعد هم کلاسی جهت خواندن فیدهای استاندارد وجود دارد (تعریف شده در فضای نام System.ServiceModel.Syndication). اما چگونه میتوان این افزونهی غیر استاندارد را با کمک امکانات توکار دات نت خواند؟
روش کار با استفاده از ElementExtensions هر آیتم یک فید است؛ به صورت زیر :
using System;
using System.Collections.Generic;
using System.Linq;
using System.ServiceModel.Syndication;
using System.Xml;
using System.Xml.Linq;
namespace Linq2Rss
{
public class RssEntry
{
public string Title { set; get; }
public string Description { set; get; }
public string Link { set; get; }
public DateTime PublicationDate { set; get; }
public string Author { set; get; }
public string BlogName { set; get; }
public string BlogAddress { set; get; }
public string Annotation { set; get; }
}
public static class AtomReader
{
private static string getAtomAnnotation(this SyndicationElementExtensionCollection items)
{
if (!items.Any()) return string.Empty;
var item = items.Where(x => x.OuterName.ToLowerInvariant() == "annotation").FirstOrDefault();
if (item == null) return string.Empty;
var element = item.GetObject<XElement>();
var content = element.Element("{http://www.w3.org/2005/Atom}content");
return content == null ? string.Empty : content.Value;
}
public static IList<RssEntry> GetEntries(string feedUrl)
{
using (var reader = XmlReader.Create(feedUrl))
{
var feed = SyndicationFeed.Load(reader);
if (feed == null) return null;
return feed.Items.Select(x =>
new RssEntry
{
Title = x.Title.Text,
Author = x.Authors.Any() ? x.Authors.First().Name : string.Empty,
Description = x.Content == null ? string.Empty : ((TextSyndicationContent)x.Content).Text,
Link = x.Links.Any() ? x.Links.First().Uri.AbsoluteUri : string.Empty,
PublicationDate = x.PublishDate.UtcDateTime,
BlogName = x.SourceFeed.Title.Text,
BlogAddress = x.SourceFeed.Links.Any() ? x.SourceFeed.Links.First().Uri.AbsoluteUri : string.Empty,
Annotation = x.ElementExtensions.getAtomAnnotation()
}).ToList();
}
}
}
}
در این مثال به کمک متد الحاقی getAtomAnnotation، مجموعهی SyndicationElementExtensionCollection هر آیتم یک فید بررسی شده، در بین اینها، موردی که از نوع annotation باشد انتخاب و سپس content آن استخراج میگردد.
نکتهای دیگر:
اکثر کلاسهای موجود در فضاهای نام مرتبط با XML در دات نت امکان خواندن اطلاعات را از یک Uri هم دارند؛ مانند مثال فوق و متد XmlReader.Create بکارگرفته شده در آن. اما اگر بخواهیم حین خواندن اطلاعات، یک پروکسی را نیز به پروسه جاری اضافه کنیم، به نظر خاصیت یا متدی جهت انجام اینکار وجود ندارد. برای رفع این مشکل میتوان یک پروکسی سراسری را تعریف کرد. تنها کافی است خاصیت System.Net.WebRequest.DefaultWebProxy مقدار دهی شود. پس از آن به صورت خودکار بر روی کل برنامه تاثیر خواهد گذاشت.
چند وقت پیش لینکی را معرفی کردم که در آن به طراحی پنجرههای بوت استرپ 3 با استفاده از جی کوئری پرداخته بود و از آنجا که من دوست دارم انعطاف بیشتری در استفاده از این مدل کتابخانهها داشته باشم و مستندات آن را حفظ نکنم، آنها را به HtmlHelper تبدیل میکنم.
ابتدا از این آدرس فایلهای مورد نظر را دریافت کنید. دو عدد از آنها فایل استایل و دیگری فایل جی کوئری آن است که به ترتیب زیر صدا بزنید:
<script src="//code.jquery.com/jquery-1.11.3.min.js"></script> <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.4/css/bootstrap.min.css"> <script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.4/js/bootstrap.min.js"></script> <link href="~/content/css/bootstrap-dialog.min.css" rel=stylesheet"></link> <script src="~/Scripts/bootstrap-dialog.min.js"></script>
پروژه اصلی شامل دو فایل اصلی است؛ یکی که درفضای نام models جهت قرار دادن مدلها قرار گرفته و دیگری در فضای نام Controls جهت ایجاد متدهای Helper یا اجرایی قرار گرفته است.
ابتدا نیاز است که یک کلاس از نوع BootstrapDialog ایجاد کنید تا خصوصیات پنجره مشخص گردند. این خصوصیات به شرح زیر هستند:
var dialog=new BootstrapDialog(); dialog.Title="عنوان دیالوگ"; dialog.Message="متن پنجره"; //فعال سازی این خصوصیت باعث میشود یک دکمه بستن به //پنجره اضافه شده و همچنین توسط کلیک کاربر در خارج از صفحه //باعث بسته شدن پنجره شود یا استفاده از کلید //ESC dialog.Closable=false; //تغییر اندازه دیالوگ Dialog.Size=BootstrapDialogSize.SizeNormal; //رنگ بندی دیالوگ را تغییر میدهد.مقدار زیر باعث میشود //دیالوگ با رنگبندی قرمز نمایش داده شود تا برای نمایش خطاها مناسب باشد Dialog.Type=BootstrapDialogType.Danger; //برای اعمال کردن یک کلاس استابل دلخواه Dialog.CssClass=""; //آیکن برای دیالوگ-استفاده از نام کلاس آیکنهای بوت استراپ Dialog.SpinIcon=""; //یک توصیف است که فقط در کد صفحه نمایش داده میشود //استفاده خاصی ندارد Dialog.Description=""; //بعد از بستن دیالوگ ، کدهای آن در صفحه حذف خواهند شد //اگر میخواهید کد را بارها و بارها نمایش دهید //آن را با مقدار ناصحیح مقدار دهی کنید dialog.AutoDestory=false; //========== رویدادها ============= //این رویدا قبل از نمایش دیالوگ نمایش داده میشود dialog.OnShow="function(){alert('before Dialog');}"; //این رویداد بعد از نمایش دیالوگ اجرا میشود dialog.OnShown="function(){alert('after Dialog shown');}"; //موقع درخواست بستن دیالوگ قبل از بسته شدن اجرا میگردد dialog.OnHide="function(){alert('before Dialog close');}"; //بعد از بسته شدن دیالوگ اجرا میشود dialog.OnHidden="function(){alert('after Dialog close');}";
@{ var dialog=new BootstrapDialog(); dialog.... // ........ } @HTML.BootstrapDialog("example1",dialog)
در کد، اولین پارامتر نام پنجره است: از این اسم بعدا میتوانید جهت اجرای متدها، چه دستی توسط خود شما یا ایجاد متدهای ساده توسط خود کلاس استفاده کنید. دومین پارامتر هم دریافت خصوصیات پنجره است که در بالا توضیح دادیم.
دکمه ها
در صورتیکه قصد دارید دکمهای را روی پنجره ایجاد نمایید، با شیوه زیر اینکار صورت میگیرد:
var dialog=new BootstrapDialog(); var cancelButton=new BootstrapDialogButton("cancelButton"); //cancelButton.id="cancelButton"; cancelButton.label="Cancel"; cancelButton.Key=65; cancelButton.Action="function(){alert('You Clicked!');}"; dialog.AddButton(cancelButton);
dialog.RemoveButton("cancelButton");
داده ها
در صورتیکه قصد دارید دادههایی را به این پنجره نسبت دهید تا بعدا در کدهای سمت کلاینت از آن استفاده کنید میتوانید از کد زیر استفاده کنید:
dialog.AddData("key","value");
dialog.RemoveData("key");
متدها
متدها را به دو صورت میتوانید اعمال کنید:
- دستی: که میتوانید اطلاعات متدها را در همان صفحه مثال و مستندات ببینید و از نامی که به دکمهها و پنجرهها میدهید آنها را اعمال کنید.
- با استفاده از کلاس: کلاس ما شامل دو متد دیگر برای کنترل متدها میباشد. حدود 13 متد در آن پشتیبانی میشود که باعث میشود در بسیاری از اوقات دیگری نیازی به دانستن نام متدها نداشته باشید. یکی از متدها برای استفاده در Helper طراحی شده است که خروجی آن از نوع MvcHtmlString است و متد دیگر خروجی string دارند که میتوانید در صورتیکه خواستید، در رویدادها و خارج از Html Helper از آن استفاده کنید.
نحوهی استفاده از helper به شکل زیر است؛ فرض شده است که پنجره را تشکیل دادهاید و الان قصد دارید با کلیک بر روی یک دکمه آن را نمایش دهید:
$( "#btnshowpopup" ).click(function() { @HTML.RunBootstrapDialogMethod("example1",BootstrapDialogMethods.Open) });
$( "#btnshowpopup" ).click(function() { @HTML.RunBootstrapDialogMethod("example1",BootstrapDialogMethods.SetData,new{"key","value"}) });
cancelButton.Action="function(){{{0}}}"; cancelButton.Action=string.format(cancelButton.Action,RunBootstrapDialogMethod("example1",BootstrapDialogMethods.Close));
به عنوان یک مثال نهایی کد زیر را نوشته که نتیجه آن را در تصویر زیر میبینم:
@{ const string dialogName = "errorDialog"; var cancelButton = new BootstrapDialogButton(); cancelButton.Id = "btncancel"; cancelButton.Label = "بستن"; cancelButton.Action = "function(){{{0}}}"; cancelButton.Action = String.Format(cancelButton.Action, Dialogs.RunBootstrapDialogMethod(dialogName, BootstrapDialogMethods.Close)); var dialog = new BootstrapDialog(); dialog.AddButton(cancelButton); dialog.Title = "عنوان"; dialog.Message = "پیام هشدار"; dialog.DialogType=BootstrapDialogType.Warning; dialog.DialogSize=BootstrapDialogSize.SizeNormal; dialog.Closable = false; dialog.AddData("data1","5"); } @Html.BootstrapDialog(dialogName, dialog) @Html.RunBootstrapDialogMethod(dialogName,BootstrapDialogMethods.Open);
نکته مهم: برای ایجاد پنجره از طریق توابع عمل کنید و خط تعریف پنجره را داخل یک تابع قرار داده و از همانجا آن را باز کنید. در حال حاضر به نظر میرسد در صورتی که تعریف پنجره به طور عمومی باشد، این کتابخانه برای بار دوم به بعد مشکلاتی دارد که مشکل آن بسته نشدن پنجره است. در حال حاضر در گیت هاب این مسئله را عنوان کردیم، در صورتی که پاسخی ارائه شود همینجا به اطلاع شما میرسانم.
نظرات مطالب
BloggerToCHM
با سپاس.
اگر فایل chm فوق رو نمیتونید مشاهده کنید احتمالا بلاک شده. روی فایل کلیک راست کنید و در قسمت خواص یک دکمه مخصوص اینکار هست.
http://www.drexplain.com/press/chm-files-the-page-cannot-be-displayed-error/
اگر فایل chm فوق رو نمیتونید مشاهده کنید احتمالا بلاک شده. روی فایل کلیک راست کنید و در قسمت خواص یک دکمه مخصوص اینکار هست.
http://www.drexplain.com/press/chm-files-the-page-cannot-be-displayed-error/
داتنت 8 به همراه بهبودهای قابل ملاحظهای در کارآیی برنامههای داتنتی است و در این بین تعدادی قابلیت جدید را نیز به زبان سیشارپ اضافه کردهاست. در این مطلب ویژگی جدید «Alias any type» آنرا بررسی میکنیم. پیشنیاز کار با این قابلیت تنها نصب SDK داتنت 8 است.
امکان تعریف alias، قابلیت جدیدی نیست!
در نگارشهای پیشین زبان #C نیز میتوان برای نوعهای نامدار داتنت، alias/«نام مستعار» تعریف کرد؛ برای مثال:
Aliasها در قسمت using تعاریف یک کلاس معرفی میشوند و یکی از اهدف آنها، کوتاه کردن تعاریف فضاهای نام طولانی است و یا رفع تداخلها؛ همچنین تنها به Named types، محدود هستند و Named types فقط شامل این موارد میشوند: classes ،delegates ،interfaces ،records و structs
بنابراین دو حالت تعریف Namespace alias برای کوتاه سازی فضاهای نام طولانی و یا تعریف Type alias برای معرفی یک نام مستعار جدید برای نوعی مشخص، میسر است:
تنها کارکرد نامهای مستعار، کوتاه و زیبا سازی نامهای طولانی نیستند. برای مثال گاهی از اوقات ممکن است که بین نام نوعهای موجود در usingهای جاری، تداخل حاصل شود و برنامه کامپایل نشود. برای مثال فرض کنید که دو using زیر را تعریف کردهاید:
کامپایل این برنامه میسر نیست. چون هر دو نوع System.Random و UnityEngine.Random پیشتر تعریف شدهاند و در اینجا دقیقا مشخص نیست که تامین کنندهی شیء Random، کدام فضای نام است. در این حالت میتوان برای مثال در حین نمونه سازی، فضای نام را صراحتا ذکر کرد:
و یا میتوان برای آن نام مستعاری نیز تعریف کرد:
در این حالت دیگر تداخلی وجود نداشته و کامپایلر دقیقا میداند که تامین کنندهی Random، کدام کتابخانه و کدام فضای نام است.
امکان تعریف alias برای هر نوعی در C# 12.0
محدودیت امکان تعریف alias برای نوعهای نامدار داتنت در C# 12.0 برطرف شده و اکنون میتوان برای انواع و اقسام نوعها مانند آرایهها، tuples و غیره نیز alias تعریف کرد:
در اینجا امکان تعریف alias را برای آرایهها، nullable value types، نوعهای توکار، tupleها و حتی نوعهای unsafe، مشاهده میکنید.
یک نکته: امکان تعریف alias برای nullable reverence types وجود ندارد.
بررسی یک مثال C# 12.0
در اینجا محتویات یک فایل Program.cs یک برنامهی کنسول داتنت 8 را مشاهده میکنید:
در این مثال برای یک نوع tuple سفارشی، یک alias به نام Person تعریف شده و سپس از آن برای نمونه سازی یک شیء جدید و یا ارسال آن به عنوان یک پارامتر متد، استفاده شدهاست. خروجی برنامهی فوق به صورت زیر است:
چه زمانی بهتر است از قابلیت تعریف نامهای مستعار نوعها و یا فضاهای نام استفاده شود؟
اگر یک نام طولانی را بتوان به این صورت خلاصه کرد، مفید هستند؛ برای مثال ساده سازی تعریف یک لیست طولانی به صورت زیر:
و مثالی دیگر در این زمینه، کوتاه سازی تعاریف متداول جنریک طولانی است:
و یا اگر بتوانند رفع تداخلی را حاصل کنند، بکارگیری آنها ضروری است (مانند مثال شیء Random ابتدای بحث) و یا اگر بتوانند از تکرار تعریف یک tuple جلوگیری کنند، ذکر آنها یک refactoring مثبت بهشمار میرود؛ مانند مثال زیر که در آن از تعریف نوع tuple ای، دوبار استفاده شدهاست:
اما ... آیا واقعا تعاریفی مانند ذیل، مفید یا ضروری هستند؟
اینجا فقط قطعه کدی اضافی را که بیشتر سبب سردرگمی و بالا بردن درجهی پیچیدگی برنامه میشود، تولید کردهایم. خوانایی و سادگی درک برنامه در این حالت کاهش پیدا میکند.
میدان دید نامهای مستعار
به صورت پیشفرض، تمام نامهای مستعار تنها در داخل همان فایلی که تعریف شدهاند، قابل استفاده میباشند. از زمان C# 10.0 ، میتوان پیش از واژهی کلیدی using از واژهی کلیدی global نیز استفاده کرد تا تعریف آنها فقط در پروژهی جاری به صورت سراسری قابل دسترسی شود.
به همین جهت اگر نوعی قرار است در سایر پروژهها استفاده شود، بهتر است از global using استفاده نشده و از همان روشهای متداول تعریف records و یا classes استفاده شود.
امکان تعریف alias، قابلیت جدیدی نیست!
در نگارشهای پیشین زبان #C نیز میتوان برای نوعهای نامدار داتنت، alias/«نام مستعار» تعریف کرد؛ برای مثال:
using MyConsole = System.Console; MyConsole.WriteLine("Test console");
بنابراین دو حالت تعریف Namespace alias برای کوتاه سازی فضاهای نام طولانی و یا تعریف Type alias برای معرفی یک نام مستعار جدید برای نوعی مشخص، میسر است:
// Namespace alias using SuperJSON = System.Text.Json; var document = SuperJSON.JsonSerializer.Serialize("{}"); // Type alias using SuperJSON = System.Text.Json.JsonSerializer; var document = SuperJSON.Serialize("{}");
تنها کارکرد نامهای مستعار، کوتاه و زیبا سازی نامهای طولانی نیستند. برای مثال گاهی از اوقات ممکن است که بین نام نوعهای موجود در usingهای جاری، تداخل حاصل شود و برنامه کامپایل نشود. برای مثال فرض کنید که دو using زیر را تعریف کردهاید:
using UnityEngine; using System; Random rnd = new Random();
var rnd = new System.Random();
using Random = System.Random;
امکان تعریف alias برای هر نوعی در C# 12.0
محدودیت امکان تعریف alias برای نوعهای نامدار داتنت در C# 12.0 برطرف شده و اکنون میتوان برای انواع و اقسام نوعها مانند آرایهها، tuples و غیره نیز alias تعریف کرد:
using Ints = int[]; using DatabaseInt = int?; using OptionalFloat = float?; using Grade= decimal; using Point3D = (int, int, int); using Person = (string name, int age, string country); using unsafe P = char*; using Matrix = int[][]; Matrix aMatrix = [[1, 2, 3], [4, 5, 6], [7, 8, 9]];
یک نکته: امکان تعریف alias برای nullable reverence types وجود ندارد.
بررسی یک مثال C# 12.0
در اینجا محتویات یک فایل Program.cs یک برنامهی کنسول داتنت 8 را مشاهده میکنید:
using MyConsole = System.Console; using Person = (string name, int age, string country); Person person = new("User 1", 33, "Iran"); Console.WriteLine(person); PrintPerson(person); MyConsole.WriteLine("Test console"); static void PrintPerson(Person person) { MyConsole.WriteLine($"{person.name}, {person.age}, {person.country}"); }
(User 1, 33, Iran) User 1, 33, Iran Test console
چه زمانی بهتر است از قابلیت تعریف نامهای مستعار نوعها و یا فضاهای نام استفاده شود؟
اگر یک نام طولانی را بتوان به این صورت خلاصه کرد، مفید هستند؛ برای مثال ساده سازی تعریف یک لیست طولانی به صورت زیر:
using Companies = System.Collections.Generic.List<Company>; Companies GetCompanies() { // logic here } class Company { public string Name; public int Id; }
using EventHandlers = System.Collections.Generic.IEnumerable<System.Func<System.Threading.Tasks.Task>>;
و یا اگر بتوانند رفع تداخلی را حاصل کنند، بکارگیری آنها ضروری است (مانند مثال شیء Random ابتدای بحث) و یا اگر بتوانند از تکرار تعریف یک tuple جلوگیری کنند، ذکر آنها یک refactoring مثبت بهشمار میرود؛ مانند مثال زیر که در آن از تعریف نوع tuple ای، دوبار استفاده شدهاست:
using Country = (string Abbreviation, string Name); Country GetCountry(string abbreviation) { // Logic here } List<Country> GetCountries() { // Logic here }
using Ints = int[]; using DatabaseInt = int?; using OptionalFloat = float?;
میدان دید نامهای مستعار
به صورت پیشفرض، تمام نامهای مستعار تنها در داخل همان فایلی که تعریف شدهاند، قابل استفاده میباشند. از زمان C# 10.0 ، میتوان پیش از واژهی کلیدی using از واژهی کلیدی global نیز استفاده کرد تا تعریف آنها فقط در پروژهی جاری به صورت سراسری قابل دسترسی شود.
به همین جهت اگر نوعی قرار است در سایر پروژهها استفاده شود، بهتر است از global using استفاده نشده و از همان روشهای متداول تعریف records و یا classes استفاده شود.
مطالب
ASP.NET MVC #10
آشنایی با روشهای مختلف ارسال اطلاعات یک درخواست به کنترلر
تا اینجا با روشهای مختلف ارسال اطلاعات از یک کنترلر به View متناظر آن آشنا شدیم. اما حالت عکس آن چطور؟ مثلا در ASP.NET Web forms، دوبار بر روی یک دکمه کلیک میکردیم و در روال رویدادگردان کلیک آن، همانند برنامههای ویندوزی، دسترسی به اطلاعات اشیاء قرار گرفته بر روی فرم را داشتیم. در ASP.NET MVC که کلا مفهوم Events را حذف کرده و وب را همانگونه که هست ارائه میدهد و به علاوه کنترلرهای آن، ارجاع مستقیمی را به هیچکدام از اشیاء بصری در خود ندارند (برای مثال کنترلر و متدی در آن نمیدانند که الان بر روی View آن، یک گرید قرار دارد یا یک دکمه یا اصلا هیچی)، چگونه میتوان اطلاعاتی را از کاربر دریافت کرد؟
در اینجا حداقل سه روش برای دریافت اطلاعات از کاربر وجود دارد:
الف) استفاده از اشیاء Context مانند HttpContext، Request، RouteData و غیره
ب) به کمک پارامترهای اکشن متدها
ج) با استفاده از ویژگی جدیدی به نام Data Model Binding
یک مثال کاربردی
قصد داریم یک صفحه لاگین ساده را طراحی کنیم تا بتوانیم هر سه حالت ذکر شده فوق را در عمل بررسی نمائیم. بحث HTML Helpers استاندارد ASP.NET MVC را هم که در قسمت قبل شروع کردیم، لابلای توضیحات قسمت جاری و قسمتهای بعدی با مثالهای کاربردی دنبال خواهند شد.
بنابراین یک پروژه جدید خالی ASP.NET MVC را شروع کرده و مدلی را به نام Account با محتوای زیر به پوشه Models برنامه اضافه کنید:
namespace MvcApplication6.Models
{
public class Account
{
public string Name { get; set; }
public string Password { get; set; }
}
}
یک کنترلر جدید را هم به نام LoginController به پوشه کنترلرهای برنامه اضافه کنید. بر روی متد Index پیش فرض آن کلیک راست نمائید و یک View خالی را اضافه نمائید.
در ادامه به فایل Global.asax.cs مراجعه کرده و نام کنترلر پیشفرض را به Login تغییر دهید تا به محض شروع برنامه در VS.NET، صفحه لاگین ظاهر شود.
کدهای کامل کنترلر لاگین را در ادامه ملاحظه میکنید:
using System.Web.Mvc;
using MvcApplication6.Models;
namespace MvcApplication6.Controllers
{
public class LoginController : Controller
{
[HttpGet]
public ActionResult Index()
{
return View(); //Shows the login page
}
[HttpPost]
public ActionResult LoginResult()
{
string name = Request.Form["name"];
string password = Request.Form["password"];
if (name == "Vahid" && password == "123")
ViewBag.Message = "Succeeded";
else
ViewBag.Message = "Failed";
return View("Result");
}
[HttpPost]
[ActionName("LoginResultWithParams")]
public ActionResult LoginResult(string name, string password)
{
if (name == "Vahid" && password == "123")
ViewBag.Message = "Succeeded";
else
ViewBag.Message = "Failed";
return View("Result");
}
[HttpPost]
public ActionResult Login(Account account)
{
if (account.Name == "Vahid" && account.Password == "123")
ViewBag.Message = "Succeeded";
else
ViewBag.Message = "Failed";
return View("Result");
}
}
}
همچنین Viewهای متناظر با این کنترلر هم به شرح زیر هستند:
فایل index.cshtml به نحو زیر تعریف خواهد شد:
@model MvcApplication6.Models.Account
@{
ViewBag.Title = "Index";
}
<h2>
Login</h2>
@using (Html.BeginForm(actionName: "LoginResult", controllerName: "Login"))
{
<fieldset>
<legend>Test LoginResult()</legend>
<p>
Name: @Html.TextBoxFor(m => m.Name)</p>
<p>
Password: @Html.PasswordFor(m => m.Password)</p>
<input type="submit" value="Login" />
</fieldset>
}
@using (Html.BeginForm(actionName: "LoginResultWithParams", controllerName: "Login"))
{
<fieldset>
<legend>Test LoginResult(string name, string password)</legend>
<p>
Name: @Html.TextBoxFor(m => m.Name)</p>
<p>
Password: @Html.PasswordFor(m => m.Password)</p>
<input type="submit" value="Login" />
</fieldset>
}
@using (Html.BeginForm(actionName: "Login", controllerName: "Login"))
{
<fieldset>
<legend>Test Login(Account acc)</legend>
<p>
Name: @Html.TextBoxFor(m => m.Name)</p>
<p>
Password: @Html.PasswordFor(m => m.Password)</p>
<input type="submit" value="Login" />
</fieldset>
}
و فایل result.cshtml هم محتوای زیر را دارد:
@{
ViewBag.Title = "Result";
}
<fieldset>
<legend>Login Result</legend>
<p>
@ViewBag.Message</p>
</fieldset>
توضیحاتی در مورد View لاگین برنامه:
در View صفحه لاگین سه فرم را مشاهده میکنید. در برنامههای ASP.NET Web forms در هر صفحه، تنها یک فرم را میتوان تعریف کرد؛ اما در ASP.NET MVC این محدودیت برداشته شده است.
تعریف یک فرم هم با متد کمکی Html.BeginForm انجام میشود. در اینجا برای مثال میشود یک فرم را به کنترلری خاص و متدی مشخص در آن نگاشت نمائیم.
از عبارت using هم برای درج خودکار تگ بسته شدن فرم، در حین dispose شیء MvcForm کمک گرفته شده است.
برای نمونه خروجی HTML اولین فرم تعریف شده به صورت زیر است:
<form action="/Login/LoginResult" method="post">
<fieldset>
<legend>Test LoginResult()</legend>
<p>
Name: <input id="Name" name="Name" type="text" value="" /></p>
<p>
Password: <input id="Password" name="Password" type="password" /></p>
<input type="submit" value="Login" />
</fieldset>
</form>
توسط متدهای کمکی Html.TextBoxFor و Html.PasswordFor یک TextBox و یک PasswordBox به صفحه اضافه میشوند، اما این For آنها و همچنین lambda expression ایی که بکارگرفته شده برای چیست؟
متدهای کمکی Html.TextBox و Html.Password از نگارشهای اولیه ASP.NET MVC وجود داشتند. این متدها نام خاصیتها و پارامترهایی را که قرار است به آنها بایند شوند، به صورت رشته میپذیرند. اما با توجه به اینکه در اینجا میتوان یک strongly typed view را تعریف کرد، تیم ASP.NET MVC بهتر دیده است که این رشتهها را حذف کرده و از قابلیتی به نام Static reflection استفاده کند (^ و ^).
با این توضیحات، اطلاعات سه فرم تعریف شده در View لاگین برنامه، به سه متد متفاوت قرار گرفته در کنترلری به نام Login ارسال خواهند شد. همچنین با توجه به مشخص بودن نوع model که در ابتدای فایل تعریف شده، خاصیتهایی را که قرار است اطلاعات ارسالی به آنها بایند شوند نیز به نحو strongly typed تعریف شدهاند و تحت نظر کامپایلر خواهند بود.
توضیحاتی در مورد نحوه عملکرد کنترلر لاگین برنامه:
در این کنترلر صرفنظر از محتوای متدهای آنها، دو نکته جدید را میتوان مشاهده کرد. استفاده از ویژگیهای HttpPost، HttpGet و ActionName. در اینجا به کمک ویژگیهای HttpGet و HttpPost در مورد نحوه دسترسی به این متدها، محدودیت قائل شدهایم. به این معنا که تنها در حالت Post است که متد LoginResult در دسترس خواهد بود و اگر شخصی نام این متدها را مستقیما در مرورگر وارد کند (یا همان HttpGet پیش فرض که نیازی هم به ذکر صریح آن نیست)، با پیغام «یافت نشد» مواجه میگردد.
البته در نگارشهای اولیه ASP.NET MVC از ویژگی دیگری به نام AcceptVerbs برای مشخص سازی نوع محدودیت فراخوانی یک اکشن متد استفاده میشد که هنوز هم معتبر است. برای مثال:
[AcceptVerbs(HttpVerbs.Get)]
یک نکته امنیتی:
همیشه متدهای Delete خود را به HttpPost محدود کنید. به این علت که ممکن است در طی مثلا یک ایمیل، آدرسی به شکل http://localhost/blog/delete/10 برای شما ارسال شود و همچنین سشن کار با قسمت مدیریتی بلاگ شما نیز در همان حال فعال باشد. URL ایی به این شکل، در حالت پیش فرض، محدودیت اجرایی HttpGet را دارد. بنابراین احتمال اجرا شدن آن بالا است. اما زمانیکه متد delete را به HttpPost محدود کردید، دیگر این نوع حملات جواب نخواهند داد و حتما نیاز خواهد بود تا اطلاعاتی به سرور Post شود و نه یک Get ساده (مثلا کلیک بر روی یک لینک معمولی)، کار حذف را انجام دهد.
توسط ActionName میتوان نام دیگری را صرفنظر از نام متد تعریف شده در کنترلر، به آن متد انتساب داد که توسط فریم ورک در حین پردازش نهایی مورد استفاده قرار خواهد گرفت. برای مثال در اینجا به متد LoginResult دوم، نام LoginResultWithParams را انتساب دادهایم که در فرم دوم تعریف شده در View لاگین برنامه مورد استفاده قرار گرفته است.
وجود این ActionName هم در مثال فوق ضروری است. از آنجائیکه دو متد هم نام را معرفی کردهایم و فریم ورک نمیداند که کدامیک را باید پردازش کند. در این حالت (بدون وجود ActionName معرفی شده)، برنامه با خطای زیر مواجه میگردد:
The current request for action 'LoginResult' on controller type 'LoginController' is ambiguous between the following action methods:
System.Web.Mvc.ActionResult LoginResult() on type MvcApplication6.Controllers.LoginController
System.Web.Mvc.ActionResult LoginResult(System.String, System.String) on type MvcApplication6.Controllers.LoginController
برای اینکه بتوانید نحوه نگاشت فرمها به متدها را بهتر درک کنید، بر روی چهار return View موجود در کنترلر لاگین برنامه، چهار breakpoint را تعریف کنید. سپس برنامه را در حالت دیباگ اجرا نمائید و تک تک فرمها را یکبار با کلیک بر روی دکمه لاگین، به سرور ارسال نمائید.
بررسی سه روش دریافت اطلاعات از کاربر در ASP.NET MVC
الف) استفاده از اشیاء Context
در ویژوال استودیو، در کنترلر لاگین برنامه، بر روی کلمه Controller کلیک راست کرده و گزینه Go to definition را انتخاب کنید. در اینجا بهتر میتوان به خواصی که در یک کنترلر به آنها دسترسی داریم، نگاهی انداخت:
public HttpContextBase HttpContext { get; }
public HttpRequestBase Request { get; }
public HttpResponseBase Response { get; }
public RouteData RouteData { get; }
در بین این خواص و اشیاء مهیا، Request و RouteData بیشتر مد نظر ما هستند. در مورد RouteData در قسمت ششم این سری، توضیحاتی ارائه شد. اگر مجددا Go to definition مربوط به HttpRequestBase خاصیت Request را بررسی کنیم، موارد ذیل جالب توجه خواهند بود:
public virtual NameValueCollection QueryString { get; } // GET variables
public NameValueCollection Form { get; } // POST variables
public HttpCookieCollection Cookies { get; }
public NameValueCollection Headers { get; }
public string HttpMethod { get; }
توسط خاصیت Form شیء Request میتوان به مقادیر ارسالی به سرور در یک کنترلر دسترسی یافت که نمونهای از آنرا در اولین متد LoginResult میتوانید مشاهده کنید. این روش در ASP.NET Web forms هم کار میکند. جهت اطلاع این روش با ASP کلاسیک دهه نود هم سازگار است!
البته این روش آنچنان مرسوم نیست؛ چون NameValueCollection مورد استفاده، ایندکسی عددی یا رشتهای را میپذیرد که هر دو با پیشرفتهایی که در زبانهای دات نتی صورت گرفتهاند، دیگر آنچنان مطلوب و روش مرجح به حساب نمیآیند. اما ... هنوز هم قابل استفاده است.
به علاوه اگر دقت کرده باشید در اینجا HttpContextBase داریم بجای HttpContext. تمام این کلاسهای پایه هم به جهت سهولت انجام آزمونهای واحد در ASP.NET MVC ایجاد شدهاند. کار کردن مستقیم با HttpContext مشکل بوده و نیاز به شبیه سازی فرآیندهای رخ داده در یک وب سرور را دارد. اما این کلاسهای پایه جدید، مشکلات یاد شده را به همراه ندارند.
ب) استفاده از پارامترهای اکشن متدها
نکتهای در مورد نامگذاری پارامترهای یک اکشن متد به صورت توکار اعمال میشود که باید به آن دقت داشت:
اگر نام یک پارامتر، با نام کلید یکی از رکوردهای موجود در مجموعههای زیر یکی باشد، آنگاه به صورت خودکار اطلاعات دریافتی به این پارامتر نگاشت خواهد شد (پارامتر هم نام، به صورت خودکار مقدار دهی میشود). این مجموعهها شامل موارد زیرهستند:
Request.Form
Request.QueryString
Request.Files
RouteData.Values
برای نمونه در متدی که با نام LoginResultWithParams مشخص شده، چون نامهای دو پارامتر آن، با نامهای بکارگرفته شده در Html.TextBoxFor و Html.PasswordFor یکی هستند، با مقادیر ارسالی آنها مقدار دهی شده و سپس در متد قابل استفاده خواهند بود. در پشت صحنه هم از همان رکوردهای موجود در Request.Form (یا سایر موارد ذکر شده)، استفاده میشود. در اینجا هر رکورد مثلا مجموعه Request.Form، کلیدی مساوی نام ارسالی به سرور را داشته و مقدار آن هم، مقداری است که کاربر وارد کرده است.
اگر همانندی یافت نشد، آن پارامتر با نال مقدار دهی میگردد. بنابراین اگر برای مثال یک پارامتر از نوع int را معرفی کرده باشید و چون نوع int، نال نمیپذیرد، یک استثناء بروز خواهد کرد. برای حل این مشکل هم میتوان از Nullable types استفاده نمود (مثلا بجای int id نوشت int? id تا مشکلی جهت انتساب مقدار نال وجود نداشته باشد).
همچنین باید دقت داشت که این بررسی تطابقهای بین نام عناصر HTML و نام پارامترهای متدها، case insensitive است و به کوچکی و بزرگی حروف حساس نیست. برای مثال، پارامتر معرفی شده در متد LoginResult مساوی string name است، اما نام خاصیت تعریف شده در کلاس Account مساوی Name بود.
ج) استفاده از ویژگی جدیدی به نام Data Model Binding
در ASP.NET MVC چون میتوان با یک Strongly typed view کار کرد، خود فریم ورک این قابلیت را دارد که اطلاعات ارسالی یکی فرم را به صورت خودکار به یک وهله از یک شیء نگاشت کند. در اینجا model binder وارد عمل میشود، مقادیر ارسالی را استخراج کرده (اطلاعات دریافتی از Form یا کوئری استرینگها یا اطلاعات مسیریابی و غیره) و به خاصیتهای یک شیء نگاشت میکند. بدیهی است در اینجا این خواص باید عمومی باشند و هم نام عناصر HTML ارسالی به سرور. همچنین model binder پیش فرض ASP.NET MVC را نیز میتوان کاملا تعویض کرد و محدود به استفاده از model binder توکار آن نیستیم.
وجود این Model binder، کار با ORMها را بسیار لذت بخش میکند؛ از آنجائیکه خود فریم ورک ASP.NET MVC میتواند عناصر شیءایی را که قرار است به بانک اطلاعاتی اضافه شود، یا در آن به روز شود، به صورت خودکار ایجاد کرده یا به روز رسانی نماید.
نحوه کار با model binder را در متد Login کنترلر فوق میتوانید مشاهده کنید. بر روی return View آن یک breakpoint قرار دهید. فرم سوم را به سرور ارسال کنید و سپس در VS.NET خواص شیء ساخته شده را در حین دیباگ برنامه، بررسی نمائید.
بنابراین تفاوتی نمیکند که از چندین پارامتر استفاده کنید یا اینکه کلا یک شیء را به عنوان پارامتر معرفی نمائید. فریم ورک سعی میکند اندکی هوش به خرج داده و مقادیر ارسالی به سرور را به پارامترهای تعریفی، حتی به خواص اشیاء این پارامترهای تعریف شده، نگاشت کند.
در ASP.NET MVC سه نوع Model binder وجود دارند:
1) Model binder پیش فرض که توضیحات آن به همراه مثالی ارائه شد.
2) Form collection model binder که در ادامه توضیحات آنرا مشاهده خواهید نمود.
3) HTTP posted file base model binder که توضیحات آن به قسمت بعدی موکول میشود.
یک نکته:
اولین متد LoginResult کنترلر را به نحو زیر نیز میتوان بازنویسی کرد:
[HttpPost]
[ActionName("LoginResultWithFormCollection")]
public ActionResult LoginResult(FormCollection collection)
{
string name = collection["name"];
string password = collection["password"];
if (name == "Vahid" && password == "123")
ViewBag.Message = "Succeeded";
else
ViewBag.Message = "Failed";
return View("Result");
}
در اینجا FormCollection به صورت خودکار بر اساس مقادیر ارسالی به سرور توسط فریم ورک تشکیل میشود (FormCollection هم یک نوع model binder ساده است) و اساسا یک NameValueCollection میباشد.
بدیهی است در این حالت باید نگاشت مقادیر دریافتی، به متغیرهای متناظر با آنها، دستی انجام شود (مانند مثال فوق) یا اینکه میتوان از متد UpdateModel کلاس Controller هم استفاده کرد:
[HttpPost]
public ActionResult LoginResultUpdateFormCollection(FormCollection collection)
{
var account = new Account();
this.UpdateModel(account, collection.ToValueProvider());
if (account.Name == "Vahid" && account.Password == "123")
ViewBag.Message = "Succeeded";
else
ViewBag.Message = "Failed";
return View("Result");
}
متد توکار UpdateModel، به صورت خودکار اطلاعات FormCollection دریافتی را به شیء مورد نظر، نگاشت میکند.
همچنین باید عنوان کرد که متد UpdateModel، در پشت صحنه از اطلاعات Model binder پیش فرض و هر نوع Model binder سفارشی که ایجاد کنیم استفاده میکند. به این ترتیب زمانیکه از این متد استفاده میکنیم، اصلا نیازی به استفاده از FormCollection نیست و متد بدون آرگومان زیر هم به خوبی کار خواهد کرد:
[HttpPost]
public ActionResult LoginResultUpdateModel()
{
var account = new Account();
this.UpdateModel(account);
if (account.Name == "Vahid" && account.Password == "123")
ViewBag.Message = "Succeeded";
else
ViewBag.Message = "Failed";
return View("Result");
}
استفاده از model binderها همینجا به پایان نمیرسد. نکات تکمیلی آنها در قسمت بعدی بررسی خواهند شد.
با توجه به افزایش کاربرد jQuery و دیگر کتابخانههای جاوا اسکریپت در برنامههای تحت وب، یکی از چالشهای همیشگی برنامه نویسان، فشرده سازی فایلهای دربرگیرنده کدهای جاوا اسکریپت و شیوه نامهها می باشد. برای این منظور راههای مختلفی مانند استفاده از ابزارهای آنلاین مانند این + و این + وجود دارند. اما یک روش خودکار هم وجود دارد که در زمان Build پروژههای دات نت میتوان از آن بهره گرفت.
Microsoft Ajax Minifier
یک ابزار رایگان جهت فشرده سازی فایلهای جاوا اسکریپت و شیوه نامهها است. شما میتوانید این ابزار را از صفحه خانگی آن در سایت asp.net دریافت کنید. جهت استفاده از این ابزار میتوان از طریق خط فرمان عمل کرد. اما روش سادهتر که هدف اصلی این مطلب است به شرح زیر است:
1. در VisualStudio.NET از طریق منو به مسیر Tools, Options, Projects and Solutions بروید و گزینه Always show solution را تیک بزنید.
2. از Solution Explorer بر روی عنوان پروژه کلیک راست کرده و گزینه Unload Project را انتخاب نمایید.
3. مجدداً روی عنوان پروژه کلیک راست کرده و گزینه Edit را انتخاب کنید و دستورات زیر را قبل از بسته شدن تگ Project اضافه کنید:
<Import Project="$(MSBuildExtensionsPath)\Microsoft\MicrosoftAjax\ajaxmin.tasks" /> <Target Name="AfterBuild"> <ItemGroup> <JS Include="**\*.js" Exclude="**\*.min.js;Scripts\*.js" /> </ItemGroup> <ItemGroup> <CSS Include="**\*.css" Exclude="**\*.min.css" /> </ItemGroup> <AjaxMin JsSourceFiles="@(JS)" JsSourceExtensionPattern="\.js$" JsTargetExtension=".min.js" CssSourceFiles="@(CSS)" CssSourceExtensionPattern="\.css$" CssTargetExtension=".min.css" /> </Target>
4. دوباره بر روی عنوان پروژه کلیک راست کرده و گزینه Reload Project را انتخاب کنید.
توجه کنید که با این کار ما یک MSBuild task با عنوان ajaxmini به پروژه اضافه کردیم. این وظیفه که در زمان Build پروژه اجرا خواهد شد فایلهای جاوا اسکریپت را فشرده و با پسوند .min.js و همچنین فایلهای CSS را پس از فشرده سازی با پسوند .min.css در همان مسیر فایل مادر بطور خودکار ذخیره میکند.
نکته:
اگر به دستورات تنظیمات فوق نگاه دقیقتری بیندازیم، متوجه عبارات Include و Exclude می شویم. توسط این دو صفت شما میتوانید الگوهایی را جهت فشرده سازی و یا عدم فشرده سازی تعریف کنید. بدین معنا که توسط الگویهای ذکر شده در تنظیمات فوق از فشرده سازی فایلهای با پسوند .min.css و .min.js خودداری میشود.
در این شرایط در حین توسعه برنامه، شما میتوانید از فایلهای با کد خوانا استفاده نمایید و زمان انتشار و Build پروژه بصورت خودکار آنها را با فایلهای فشرده جایگزین کنید.
این ابزار تمامی فضاهای خالی، ';' و '{ }'های اضافی و توضیحات را از کدهای شما حذف میکند. متغیرها و توابع شما را به اسامی کوجکتر تغییر نام میدهد. و ...
همچنین شما از کتابخانه این پروژه میتوانید در زمان اجرا و سورس برنامه خود استفاده کنید. جهت اطلاعات بیشتر میتوانید به سایت مربوطه مراجعه نمایید.
اگر به یک سری از کتابخانهها دقت کنید، تمام کلاسهای آنها دارای یک پیشوند تکراری هستند؛ مثلا SmurfXMLDataRow، SmurfXMLElement و الی آخر در مورد تمام کلاسهای موجود در پروژه. به این رویه «Smurf Naming Convention» گفته میشود!
در این نوع کتابخانهها زمانیکه کاربری بر روی دکمهای کلیک میکند، SmurfAccountView اطلاعات SmurfAccountDTO را به SmurfAccountController منتقل میکند. در ادامه از خاصیت SmurfID دریافتی، مقدار SmurfOrderHistory دریافت شده و به SmurfHistoryReportingView جهت نمایش ارسال خواهد شد. اگر استثنای SmurfErrorEvent رخ دهد، توسط SmurfErrorLogger در فایلی به نام log/smurf/smurflog.log ثبت خواهد شد.
کلمه Smurf هم از شخصیتی کارتونی به همین نام اخذ شده است که در زبان مخصوص آنها اکثر افعال و نامها از کلمه Smurf مشتق میشود! برای مثال در مورد ماهیگیری کردن در یک رودخانه عنوان میکنند «We're going smurfing on the River Smurf today».
خوب، چکار باید کرد؟ روش صحیح معرفی نام یک شرکت در حین طراحی و نامگذاری کلاسهای یک کتابخانه چیست؟
در مطلب بسیار جامع و عالی «اصول و قراردادهای نامگذاری در داتنت» عنوان شده است که اساس نامگذاری فضاهای نام باید از قاعده زیر پیروی کند:
مثلا مایکروسافت یکبار فضای نام Microsoft.Reporting.WebForms را تعریف کرده است و ... همین! دیگر به ابتدای هر کلاسی در این کتابخانه، پیشوند Microsoft یا MS و امثال آن اضافه نشده است تا بر روی اعصاب و روان استفاده کننده تاثیر منفی داشته باشد.
در این نوع کتابخانهها زمانیکه کاربری بر روی دکمهای کلیک میکند، SmurfAccountView اطلاعات SmurfAccountDTO را به SmurfAccountController منتقل میکند. در ادامه از خاصیت SmurfID دریافتی، مقدار SmurfOrderHistory دریافت شده و به SmurfHistoryReportingView جهت نمایش ارسال خواهد شد. اگر استثنای SmurfErrorEvent رخ دهد، توسط SmurfErrorLogger در فایلی به نام log/smurf/smurflog.log ثبت خواهد شد.
کلمه Smurf هم از شخصیتی کارتونی به همین نام اخذ شده است که در زبان مخصوص آنها اکثر افعال و نامها از کلمه Smurf مشتق میشود! برای مثال در مورد ماهیگیری کردن در یک رودخانه عنوان میکنند «We're going smurfing on the River Smurf today».
خوب، چکار باید کرد؟ روش صحیح معرفی نام یک شرکت در حین طراحی و نامگذاری کلاسهای یک کتابخانه چیست؟
در مطلب بسیار جامع و عالی «اصول و قراردادهای نامگذاری در داتنت» عنوان شده است که اساس نامگذاری فضاهای نام باید از قاعده زیر پیروی کند:
<Company>.<Technology|Produt|Project>[.<Feature>][.<SubNamespace>]
مطالب
EF Code First #3
بررسی تعاریف نگاشتها به کمک متادیتا در EF Code first
در قسمت قبل مروری سطحی داشتیم بر امکانات مهیای جهت تعاریف نگاشتها در EF Code first. در این قسمت، حالت استفاده از متادیتا یا همان data annotations را با جزئیات بیشتری بررسی خواهیم کرد.
برای این منظور پروژه کنسول جدیدی را آغاز نمائید. همچنین به کمک NuGet، ارجاعات لازم را به اسمبلی EF، اضافه کنید. در ادامه مدلهای زیر را به پروژه اضافه نمائید؛ یک شخص که تعدادی پروژه منتسب میتواند داشته باشد:
using System;
using System.Collections.Generic;
namespace EF_Sample02.Models
{
public class User
{
public int Id { set; get; }
public DateTime AddDate { set; get; }
public string Name { set; get; }
public string LastName { set; get; }
public string Email { set; get; }
public string Description { set; get; }
public byte[] Photo { set; get; }
public IList<Project> Projects { set; get; }
}
}
using System;
namespace EF_Sample02.Models
{
public class Project
{
public int Id { set; get; }
public DateTime AddDate { set; get; }
public string Title { set; get; }
public string Description { set; get; }
public virtual User User { set; get; }
}
}
به خاصیت public virtual User User در کلاس Project اصطلاحا Navigation property هم گفته میشود.
دو کلاس زیر را نیز جهت تعریف کلاس Context که بیانگر کلاسهای شرکت کننده در تشکیل بانک اطلاعاتی هستند و همچنین کلاس آغاز کننده بانک اطلاعاتی سفارشی را به همراه تعدادی رکورد پیش فرض مشخص میکنند، به پروژه اضافه نمائید.
using System;
using System.Collections.Generic;
using System.Data.Entity;
using EF_Sample02.Models;
namespace EF_Sample02
{
public class Sample2Context : DbContext
{
public DbSet<User> Users { set; get; }
public DbSet<Project> Projects { set; get; }
}
public class Sample2DbInitializer : DropCreateDatabaseAlways<Sample2Context>
{
protected override void Seed(Sample2Context context)
{
context.Users.Add(new User
{
AddDate = DateTime.Now,
Name = "Vahid",
LastName = "N.",
Email = "name@site.com",
Description = "-",
Projects = new List<Project>
{
new Project
{
Title = "Project 1",
AddDate = DateTime.Now.AddDays(-10),
Description = "..."
}
}
});
base.Seed(context);
}
}
}
به علاوه در فایل کانفیگ برنامه، تنظیمات رشته اتصالی را نیز اضافه نمائید:
<connectionStrings>
<add
name="Sample2Context"
connectionString="Data Source=(local);Initial Catalog=testdb2012;Integrated Security = true"
providerName="System.Data.SqlClient"
/>
</connectionStrings>
همانطور که ملاحظه میکنید، در اینجا name به نام کلاس مشتق شده از DbContext اشاره میکند (یکی از قراردادهای توکار EF Code first است).
یک نکته:
مرسوم است کلاسهای مدل را در یک class library جداگانه اضافه کنند به نام DomainClasses و کلاسهای مرتبط با DbContext را در پروژه class library دیگری به نام DataLayer. هیچکدام از این پروژهها نیازی به فایل کانفیگ و تنظیمات رشته اتصالی ندارند؛ زیرا اطلاعات لازم را از فایل کانفیگ پروژه اصلی که این دو پروژه class library را به خود الحاق کرده، دریافت میکنند. دو پروژه class library اضافه شده تنها باید ارجاعاتی را به اسمبلیهای EF و data annotations داشته باشند.
در ادامه به کمک متد Database.SetInitializer که در قسمت دوم به بررسی آن پرداختیم و با استفاده از کلاس سفارشی Sample2DbInitializer فوق، نسبت به ایجاد یک بانک اطلاعاتی خالی تشکیل شده بر اساس تعاریف کلاسهای دومین پروژه، اقدام خواهیم کرد:
using System;
using System.Data.Entity;
namespace EF_Sample02
{
class Program
{
static void Main(string[] args)
{
Database.SetInitializer(new Sample2DbInitializer());
using (var db = new Sample2Context())
{
var project1 = db.Projects.Find(1);
Console.WriteLine(project1.Title);
}
}
}
}
تا زمانیکه وهلهای از Sample2Context ساخته نشود و همچنین یک کوئری نیز به بانک اطلاعاتی ارسال نگردد، Sample2DbInitializer در عمل فراخوانی نخواهد شد.
ساختار بانک اطلاعاتی پیش فرض تشکیل شده نیز مطابق اسکریپت زیر است:
CREATE TABLE [dbo].[Users](
[Id] [int] IDENTITY(1,1) NOT NULL,
[AddDate] [datetime] NOT NULL,
[Name] [nvarchar](max) NULL,
[LastName] [nvarchar](max) NULL,
[Email] [nvarchar](max) NULL,
[Description] [nvarchar](max) NULL,
[Photo] [varbinary](max) NULL,
CONSTRAINT [PK_Users] PRIMARY KEY CLUSTERED
(
[Id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF,
IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
CREATE TABLE [dbo].[Projects](
[Id] [int] IDENTITY(1,1) NOT NULL,
[AddDate] [datetime] NOT NULL,
[Title] [nvarchar](max) NULL,
[Description] [nvarchar](max) NULL,
[User_Id] [int] NULL,
CONSTRAINT [PK_Projects] PRIMARY KEY CLUSTERED
(
[Id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF,
IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[Projects] WITH CHECK ADD CONSTRAINT [FK_Projects_Users_User_Id] FOREIGN KEY([User_Id])
REFERENCES [dbo].[Users] ([Id])
GO
ALTER TABLE [dbo].[Projects] CHECK CONSTRAINT [FK_Projects_Users_User_Id]
GO
توضیحاتی در مورد ساختار فوق، جهت یادآوری مباحث دو قسمت قبل:
- خواصی با نام Id تبدیل به primary key و identity field شدهاند.
- نام جداول، همان نام خواص تعریف شده در کلاس Context است.
- تمام رشتهها به nvarchar از نوع max نگاشت شدهاند و null پذیر میباشند.
- خاصیت تصویر که با آرایهای از بایتها تعریف شده به varbinary از نوع max نگاشت شده است.
- بر اساس ارتباط بین کلاسها فیلد User_Id در جدول Projects اضافه شده است که توسط قیدی به نام FK_Projects_Users_User_Id، جهت تعریف کلید خارجی عمل میکند. این نام گذاری پیش فرض هم بر اساس نام خواص در دو کلاس انجام میشود.
- schema پیش فرض بکارگرفته شده، dbo است.
- null پذیری پیش فرض فیلدها بر اساس اصول زبان مورد استفاده تعیین شده است. برای مثال در سی شارپ، نوع int نال پذیر نیست یا نوع DateTime نیز به همین ترتیب یک value type است. بنابراین در اینجا این دو نوع به صورت not null تعریف شدهاند (صرفنظر از اینکه در SQL Server هر دو نوع یاد شده، null پذیر هم میتوانند باشند). بدیهی است امکان تعریف nullable types نیز وجود دارد.
مروری بر انواع متادیتای قابل استفاده در EF Code first
1) Key
همانطور که ملاحظه کردید اگر نام خاصیتی Id یا ClassName+Id باشد، به صورت خودکار به عنوان primary key جدول، مورد استفاده قرار خواهد گرفت. این یک قرارداد توکار است.
اگر یک چنین خاصیتی با نامهای ذکر شده در کلاس وجود نداشته باشد، میتوان با مزین سازی خاصیتی مفروض با ویژگی Key که در فضای نام System.ComponentModel.DataAnnotations قرار دارد، آنرا به عنوان Primary key معرفی نمود. برای مثال:
public class Project
{
[Key]
public int ThisIsMyPrimaryKey { set; get; }
و ضمنا باید دقت داشت که حین کار با ORMs فرقی نمیکند EF باشد یا سایر فریم ورکهای دیگر، داشتن یک key جهت عملکرد صحیح فریم ورک، ضروری است. بر اساس یک Key است که Entity معنا پیدا میکند.
2) Required
ویژگی Required که در فضای نام System.ComponentModel.DataAnnotations تعریف شده است، سبب خواهد شد یک خاصیت به صورت not null در بانک اطلاعاتی تعریف شود. همچنین در مباحث اعتبارسنجی برنامه، پیش از ارسال اطلاعات به سرور نیز نقش خواهد داشت. در صورت نال بودن خاصیتی که با ویژگی Required مزین شده است، یک استثنای اعتبارسنجی پیش از ذخیره سازی اطلاعات در بانک اطلاعاتی صادر میگردد. این ویژگی علاوه بر EF Code first در ASP.NET MVC نیز به نحو یکسانی تاثیرگذار است.
3) MaxLength و MinLength
این دو ویژگی نیز در فضای نام System.ComponentModel.DataAnnotations قرار دارند (اما در اسمبلی EntityFramework.dll تعریف شدهاند و جزو اسمبلی پایه System.ComponentModel.DataAnnotations.dll نیستند). در ذیل نمونهای از تعریف اینها را مشاهده میکنید. همچنین باید درنظر داشت که روش دیگر تعریف متادیتا، ترکیب آنها در یک سطر نیز میباشد. یعنی الزامی ندارد در هر سطر یک متادیتا را تعریف کرد:
[MaxLength(50, ErrorMessage = "حداکثر 50 حرف"), MinLength(4, ErrorMessage = "حداقل 4 حرف")]
public string Title { set; get; }
ویژگی MaxLength بر روی طول فیلد تعریف شده در بانک اطلاعاتی تاثیر دارد. برای مثال در اینجا فیلد Title از نوع nvarchar با طول 30 تعریف خواهد شد.
ویژگی MinLength در بانک اطلاعاتی معنایی ندارد.
هر دوی این ویژگیها در پروسه اعتبار سنجی اطلاعات مدل دریافتی تاثیر دارند. برای مثال در اینجا اگر طول عنوان کمتر از 4 حرف باشد، یک استثنای اعتبارسنجی صادر خواهد شد.
ویژگی دیگری نیز به نام StringLength وجود دارد که جهت تعیین حداکثر طول رشتهها به کار میرود. این ویژگی سازگاری بیشتر با ASP.NET MVC دارد از این جهت که Client side validation آنرا نیز فعال میکند.
4) Table و Column
این دو ویژگی نیز در فضای نام System.ComponentModel.DataAnnotations قرار دارند، اما در اسمبلی EntityFramework.dll تعریف شدهاند. بنابراین اگر تعاریف مدلهای شما در پروژه Class library جداگانهای قراردارند، نیاز خواهد بود تا ارجاعی را به اسمبلی EntityFramework.dll نیز داشته باشند.
اگر از نام پیش فرض جداول تشکیل شده خرسند نیستید، ویژگی Table را بر روی یک کلاس قرار داده و نام دیگری را تعریف کنید. همچنین اگر Schema کاربری رشته اتصالی به بانک اطلاعاتی شما dbo نیست، باید آنرا در اینجا صریحا ذکر کنید تا کوئریهای تشکیل شده به درستی بر روی بانک اطلاعاتی اجرا گردند:
[Table("tblProject", Schema="guest")]
public class Project
توسط ویژگی Column سه خاصیت یک فیلد بانک اطلاعاتی را میتوان تعیین کرد:
[Column("DateStarted", Order = 4, TypeName = "date")]
public DateTime AddDate { set; get; }
به صورت پیش فرض، خاصیت فوق با همین نام AddDate در بانک اطلاعاتی ظاهر میگردد. اگر برای مثال قرار است از یک بانک اطلاعاتی قدیمی استفاده شود یا قرار نیست از شیوه نامگذاری خواص در سی شارپ در یک بانک اطلاعاتی پیروی شود، توسط ویژگی Column میتوان این تعاریف را سفارشی نمود.
توسط پارامتر Order آن که از صفر شروع میشود، ترتیب قرارگیری فیلدها در حین تشکیل یک جدول مشخص میگردد.
اگر نیاز است نوع فیلد تشکیل شده را نیز سفارشی سازی نمائید، میتوان از پارامتر TypeName استفاده کرد. برای مثال در اینجا علاقمندیم از نوع date مهیا در SQL Server 2008 استفاده کنیم و نه از نوع datetime پیش فرض آن.
نکتهای در مورد Order:
Order پیش فرض تمام خواصی که قرار است به بانک اطلاعاتی نگاشت شوند، به int.MaxValue تنظیم شدهاند. به این معنا که تنظیم فوق با Order=4 سبب خواهد شد تا این فیلد، پیش از تمام فیلدهای دیگر قرار گیرد. بنابراین نیاز است Order اولین خاصیت تعریف شده را به صفر تنظیم نمود. (البته اگر واقعا نیاز به تنظیم دستی Order داشتید)
نکاتی در مورد تنظیمات ارث بری در حالت استفاده از متادیتا:
حداقل سه حالت ارث بری را در EF code first میتوان تعریف و مدیریت کرد:
الف) Table per Hierarchy - TPH
حالت پیش فرض است. نیازی به هیچگونه تنظیمی ندارد. معنای آن این است که «لطفا تمام اطلاعات کلاسهایی را که از هم ارث بری کردهاند در یک جدول بانک اطلاعاتی قرار بده». فرض کنید یک کلاس پایه شخص را دارید که کلاسهای بازیکن و مربی از آن ارث بری میکنند. زمانیکه کلاس پایه شخص توسط DbSet در کلاس مشتق شده از DbContext در معرض استفاده EF قرار میگیرد، بدون نیاز به هیچ تنظیمی، تمام این سه کلاس، تبدیل به یک جدول شخص در بانک اطلاعاتی خواهند شد. یعنی یک table به ازای سلسله مراتبی (Hierarchy) که تعریف شده.
ب) Table per Type - TPT
به این معنا است که به ازای هر نوع، باید یک جدول تشکیل شود. به عبارتی در مثال قبل، یک جدول برای شخص، یک جدول برای مربی و یک جدول برای بازیکن تشکیل خواهد شد. دو جدول مربی و بازیکن با یک کلید خارجی به جدول شخص مرتبط میشوند. تنها تنظیمی که در اینجا نیاز است، قرار دادن ویژگی Table بر روی نام کلاسهای بازیکن و مربی است. به این ترتیب حالت پیش فرض الف (TPH) اعمال نخواهد شد.
ج) Table per Concrete Type - TPC
در این حالت فقط دو جدول برای بازیکن و مربی تشکیل میشوند و جدولی برای شخص تشکیل نخواهد شد. خواص کلاس شخص، در هر دو جدول مربی و بازیکن به صورت جداگانهای تکرار خواهد شد. تنظیم این مورد نیاز به استفاده از Fluent API دارد.
توضیحات بیشتر این موارد به همراه مثال، موکول خواهد شد به مباحث استفاده از Fluent API که برای تعریف تنظیمات پیشرفته نگاشتها طراحی شده است. استفاده از متادیتا تنها قسمت کوچکی از تواناییهای Fluent API را شامل میشود.
5) ConcurrencyCheck و Timestamp
هر دوی این ویژگیها در فضای نام System.ComponentModel.DataAnnotations و اسمبلی به همین نام تعریف شدهاند.
در EF Code first دو راه برای مدیریت مسایل همزمانی وجود دارد:
[ConcurrencyCheck]
public string Name { set; get; }
[Timestamp]
public byte[] RowVersion { set; get; }
زمانیکه از ویژگی ConcurrencyCheck استفاده میشود، تغییر خاصی در سمت بانک اطلاعاتی صورت نخواهد گرفت، اما در برنامه، کوئریهای update و delete ایی که توسط EF صادر میشوند، اینبار اندکی متفاوت خواهند بود. برای مثال برنامه جاری را به نحو زیر تغییر دهید:
using System;
using System.Data.Entity;
namespace EF_Sample02
{
class Program
{
static void Main(string[] args)
{
Database.SetInitializer(new Sample2DbInitializer());
using (var db = new Sample2Context())
{
//update
var user = db.Users.Find(1);
user.Name = "User name 1";
db.SaveChanges();
}
}
}
}
متد Find بر اساس primary key عمل میکند. به این ترتیب، اول رکورد یافت شده و سپس نام آن تغییر کرده و در ادامه، اطلاعات ذخیره خواهند شد.
اکنون اگر توسط SQL Server Profiler کوئری update حاصل را بررسی کنیم، به نحو زیر خواهد بود:
exec sp_executesql N'update [dbo].[Users]
set [Name] = @0
where (([Id] = @1) and ([Name] = @2))
',N'@0 nvarchar(max) ,@1 int,@2 nvarchar(max) ',@0=N'User name 1',@1=1,@2=N'Vahid'
همانطور که ملاحظه میکنید، برای به روز رسانی فقط از primary key جهت یافتن رکورد استفاده نکرده، بلکه فیلد Name را نیز دخالت داده است. از این جهت که مطمئن شود در این بین، رکوردی که در حال به روز رسانی آن هستیم، توسط کاربر دیگری در شبکه تغییر نکرده باشد و اگر در این بین تغییری رخ داده باشد، یک استثناء صادر خواهد شد.
همین رفتار در مورد delete نیز وجود دارد:
//delete
var user = db.Users.Find(1);
db.Users.Remove(user);
db.SaveChanges();
exec sp_executesql N'delete [dbo].[Users]
where (([Id] = @0) and ([Name] = @1))',N'@0 int,@1 nvarchar(max) ',@0=1,@1=N'Vahid'
در اینجا نیز به علت مزین بودن خاصیت Name به ویژگی ConcurrencyCheck، فقط همان رکوردی که یافت شده باید حذف شود و نه نمونه تغییر یافته آن توسط کاربری دیگر در شبکه.
البته در این مثال شاید این پروسه تنها چند میلی ثانیه به نظر برسد. اما در برنامهای با رابط کاربری، شخصی ممکن است اطلاعات یک رکورد را در یک صفحه دریافت کرده و 5 دقیقه بعد بر روی دکمه save کلیک کند. در این بین ممکن است شخص دیگری در شبکه همین رکورد را تغییر داده باشد. بنابراین اطلاعاتی را که شخص مشاهده میکند، فاقد اعتبار شدهاند.
ConcurrencyCheck را بر روی هر فیلدی میتوان بکاربرد، اما ویژگی Timestamp کاربرد مشخص و محدودی دارد. باید به خاصیتی از نوع byte array اعمال شود (که نمونهای از آنرا در بالا در خاصیت public byte[] RowVersion مشاهده نمودید). علاوه بر آن، این ویژگی بر روی بانک اطلاعاتی نیز تاثیر دارد (نوع فیلد را در SQL Server تبدیل به timestamp میکند و نه از نوع varbinary مانند فیلد تصویر). SQL Server با این نوع فیلد به خوبی آشنا است و قابلیت مقدار دهی خودکار آنرا دارد. بنابراین نیازی نیست در حین تشکیل اشیاء در برنامه، قید شود.
پس از آن، این فیلد مقدار دهی شده به صورت خودکار توسط بانک اطلاعاتی، در تمام updateها و deleteهای EF Code first حضور خواهد داشت:
exec sp_executesql N'delete [dbo].[Users]
where ((([Id] = @0) and ([Name] = @1)) and ([RowVersion] = @2))',N'@0 int,@1 nvarchar(max) ,
@2 binary(8)',@0=1,@1=N'Vahid',@2=0x00000000000007D1
از این جهت که اطمینان حاصل شود، واقعا مشغول به روز رسانی یا حذف رکوردی هستیم که در ابتدای عملیات از بانک اطلاعاتی دریافت کردهایم. اگر در این بین RowVesrion تغییر کرده باشد، یعنی کاربر دیگری در شبکه این رکورد را تغییر داده و ما در حال حاضر مشغول به کار با رکوردی غیرمعتبر هستیم.
بنابراین استفاده از Timestamp را میتوان به عنوان یکی از best practices طراحی برنامههای چند کاربره ASP.NET درنظر داشت.
6) NotMapped و DatabaseGenerated
این دو ویژگی نیز در فضای نام System.ComponentModel.DataAnnotations قرار دارند، اما در اسمبلی EntityFramework.dll تعریف شدهاند.
به کمک ویژگی DatabaseGenerated، مشخص خواهیم کرد که این فیلد قرار است توسط بانک اطلاعاتی تولید شود. برای مثال خواصی از نوع public int Id به صورت خودکار به فیلدهایی از نوع identity که توسط بانک اطلاعاتی تولید میشوند، نگاشت خواهند شد و نیازی نیست تا به صورت صریح از ویژگی DatabaseGenerated جهت مزین سازی آنها کمک گرفت. البته اگر علاقمند نیستید که primary key شما از نوع identity باشد، میتوانید از گزینه DatabaseGeneratedOption.None استفاده نمائید:
[DatabaseGenerated(DatabaseGeneratedOption.None)]
public int Id { set; get; }
DatabaseGeneratedOption در اینجا یک enum است که به نحو زیر تعریف شده است:
public enum DatabaseGeneratedOption
{
None = 0,
Identity = 1,
Computed = 2
}
تا اینجا حالتهای None و Identity آن، بحث شدند.
در SQL Server امکان تعریف فیلدهای محاسباتی و Computed با T-SQL نویسی نیز وجود دارد. این نوع فیلدها در هربار insert یا update یک رکورد، به صورت خودکار توسط بانک اطلاعاتی مقدار دهی میشوند. بنابراین اگر قرار است خاصیتی به این نوع فیلدها در SQL Server نگاشت شود، میتوان از گزینه DatabaseGeneratedOption.Computed استفاده کرد.
یا اگر برای فیلدی در بانک اطلاعاتی default value تعریف کردهاید، مثلا برای فیلد date متد getdate توکار SQL Server را به عنوان پیش فرض درنظر گرفتهاید و قرار هم نیست توسط برنامه مقدار دهی شود، باز هم میتوان آنرا از نوع DatabaseGeneratedOption.Computed تعریف کرد.
البته باید درنظر داشت که اگر خاصیت DateTime تعریف شده در اینجا به همین نحو بکاربرده شود، اگر مقداری برای آن در حین تعریف یک وهله جدید از کلاس User درکدهای برنامه درنظر گرفته نشود، یک مقدار پیش فرض حداقل به آن انتساب داده خواهد شد (چون value type است). بنابراین نیاز است این خاصیت را از نوع nullable تعریف کرد (public DateTime? AddDate).
همچنین اگر یک خاصیت محاسباتی در کلاسی به صورت ReadOnly تعریف شده است (توسط کدهای مثلا سی شارپ یا وی بی):
[NotMapped]
public string FullName
{
get { return Name + " " + LastName; }
}
بدیهی است نیازی نیست تا آنرا به یک فیلد بانک اطلاعاتی نگاشت کرد. این نوع خواص را با ویژگی NotMapped میتوان مزین کرد.
همچنین باید دقت داشت در این حالت، از این نوع خواص دیگر نمیتوان در کوئریهای EF استفاده کرد. چون نهایتا این کوئریها قرار هستند به عبارات SQL ترجمه شوند و چنین فیلدی در جدول بانک اطلاعاتی وجود ندارد. البته بدیهی است امکان تهیه کوئری LINQ to Objects (کوئری از اطلاعات درون حافظه) همیشه مهیا است و اهمیتی ندارد که این خاصیت درون بانک اطلاعاتی معادلی دارد یا خیر.
7) ComplexType
ComplexType یا Component mapping مربوط به حالتی است که شما یک سری خواص را در یک کلاس تعریف میکنید، اما قصد ندارید اینها واقعا تبدیل به یک جدول مجزا (به همراه کلید خارجی) در بانک اطلاعاتی شوند. میخواهید این خواص دقیقا در همان جدول اصلی کنار مابقی خواص قرار گیرند؛ اما در طرف کدهای ما به شکل یک کلاس مجزا تعریف و مدیریت شوند.
یک مثال:
کلاس زیر را به همراه ویژگی ComplexType به برنامه مطلب جاری اضافه نمائید:
using System.ComponentModel.DataAnnotations;
namespace EF_Sample02.Models
{
[ComplexType]
public class InterestComponent
{
[MaxLength(450, ErrorMessage = "حداکثر 450 حرف")]
public string Interest1 { get; set; }
[MaxLength(450, ErrorMessage = "حداکثر 450 حرف")]
public string Interest2 { get; set; }
}
}
سپس خاصیت زیر را نیز به کلاس User اضافه کنید:
public InterestComponent Interests { set; get; }
همانطور که ملاحظه میکنید کلاس InterestComponent فاقد Id است؛ بنابراین هدف از آن تعریف یک Entity نیست و قرار هم نیست در کلاس مشتق شده از DbContext تعریف شود. از آن صرفا جهت نظم بخشیدن به یک سری خاصیت مرتبط و همخانواده استفاده شده است (مثلا آدرس یک، آدرس 2، تا آدرس 10 یک شخص، یا تلفن یک تلفن 2 یا موبایل 10 یک شخص).
اکنون اگر پروژه را اجرا نمائیم، ساختار جدول کاربر به نحو زیر تغییر خواهد کرد:
CREATE TABLE [dbo].[Users](
---...
[Interests_Interest1] [nvarchar](450) NULL,
[Interests_Interest2] [nvarchar](450) NULL,
---...
در اینجا خواص کلاس InterestComponent، داخل همان کلاس User تعریف شدهاند و نه در یک جدول مجزا. تنها در سمت کدهای ما است که مدیریت آنها منطقیتر شدهاند.
یک نکته:
یکی از الگوهایی که حین تشکیل مدلهای برنامه عموما مورد استفاده قرار میگیرد، null object pattern نام دارد. برای مثال:
namespace EF_Sample02.Models
{
public class User
{
public InterestComponent Interests { set; get; }
public User()
{
Interests = new InterestComponent();
}
}
}
در اینجا در سازنده کلاس User، به خاصیت Interests وهلهای از کلاس InterestComponent نسبت داده شده است. به این ترتیب دیگر در کدهای برنامه مدام نیازی نخواهد بود تا بررسی شود که آیا Interests نال است یا خیر. همچنین استفاده از این الگو حین کار با یک ComplexType ضروری است؛ زیرا EF امکان ثبت رکورد جاری را در صورت نال بودن خاصیت Interests (صرفنظر از اینکه خواص آن مقدار دهی شدهاند یا خیر) نخواهد داد.
8) ForeignKey
این ویژگی نیز در فضای نام System.ComponentModel.DataAnnotations قرار دارد، اما در اسمبلی EntityFramework.dll تعریف شدهاست.
اگر از قراردادهای پیش فرض نامگذاری کلیدهای خارجی در EF Code first خرسند نیستید، میتوانید توسط ویژگی ForeignKey، نامگذاری مورد نظر خود را اعمال نمائید. باید دقت داشت که ویژگی ForeignKey را باید به یک Reference property اعمال کرد. همچنین در این حالت، کلید خارجی را با یک value type نیز میتوان نمایش داد:
[ForeignKey("FK_User_Id")]
public virtual User User { set; get; }
public int FK_User_Id { set; get; }
در اینجا فیلد اضافی دوم FK_User_Id به جدول Project اضافه نخواهد شد (چون توسط ویژگی ForeignKey تعریف شده است و فقط یکبار تعریف میشود). اما در این حالت نیز وجود Reference property ضروری است.
9) InverseProperty
این ویژگی نیز در فضای نام System.ComponentModel.DataAnnotations قرار دارد، اما در اسمبلی EntityFramework.dll تعریف شدهاست.
از ویژگی InverseProperty برای تعریف روابط دو طرفه استفاده میشود.
برای مثال دو کلاس زیر را درنظر بگیرید:
public class Book
{
public int ID {get; set;}
public string Title {get; set;}
[InverseProperty("Books")]
public Author Author {get; set;}
}
public class Author
{
public int ID {get; set;}
public string Name {get; set;}
[InverseProperty("Author")]
public virtual ICollection<Book> Books {get; set;}
}
این دو کلاس همانند کلاسهای User و Project فوق هستند. ذکر ویژگی InverseProperty برای مشخص سازی ارتباطات بین این دو غیرضروری است و قراردادهای توکار EF Code first یک چنین مواردی را به خوبی مدیریت میکنند.
اما اکنون مثال زیر را درنظر بگیرید:
public class Book
{
public int ID {get; set;}
public string Title {get; set;}
public Author FirstAuthor {get; set;}
public Author SecondAuthor {get; set;}
}
public class Author
{
public int ID {get; set;}
public string Name {get; set;}
public virtual ICollection<Book> BooksAsFirstAuthor {get; set;}
public virtual ICollection<Book> BooksAsSecondAuthor {get; set;}
}
این مثال ویژهای است از کتابخانهای که کتابهای آن، تنها توسط دو نویسنده نوشته شدهاند. اگر برنامه را بر اساس این دو کلاس اجرا کنیم، EF Code first قادر نخواهد بود تشخیص دهد، روابط کدام به کدام هستند و در جدول Books چهار کلید خارجی را ایجاد میکند. برای مدیریت این مساله و تعین ابتدا و انتهای روابط میتوان از ویژگی InverseProperty کمک گرفت:
public class Book
{
public int ID {get; set;}
public string Title {get; set;}
[InverseProperty("BooksAsFirstAuthor")]
public Author FirstAuthor {get; set;}
[InverseProperty("BooksAsSecondAuthor")]
public Author SecondAuthor {get; set;}
}
public class Author
{
public int ID {get; set;}
public string Name {get; set;}
[InverseProperty("FirstAuthor")]
public virtual ICollection<Book> BooksAsFirstAuthor {get; set;}
[InverseProperty("SecondAuthor")]
public virtual ICollection<Book> BooksAsSecondAuthor {get; set;}
}
اینبار اگر برنامه را اجرا کنیم، بین این دو جدول تنها دو رابطه تشکیل خواهد شد و نه چهار رابطه؛ چون EF اکنون میداند که ابتدا و انتهای روابط کجا است. همچنین ذکر ویژگی InverseProperty در یک سر رابطه کفایت میکند و نیازی به ذکر آن در طرف دوم نیست.