BloggerToCHM 1.3
نگارش جدید برنامه BloggerToCHM را از اینجا میتوانید دریافت کنید.
تغییرات حاصل شده:
- پشتیبانی بهتر از تغییرات open search API که هر از چندگاهی توسط گوگل اعمال میشود.
- رفع مشکل تخریب اعداد فارسی در فایل تولیدی نهایی
- اضافه شدن چند گزینه جهت کنترل بر روی نمایش قسمت about در فایل نهایی حاصل و همچنین درج نظرات
- و ...
متدهای الحاقی و ترکیب کنندههای اعمال غیرهمزمان
متد WhenAll
کار آن ترکیب تعدادی Task است و اجرای آنها. تنها زمانی خاتمه مییابد که کلیهی Taskهای معرفی شده به آن خاتمه یافته باشند. هدف از آن اجرای همزمان و مستقل چندین Task است. برای مثال دریافت چندین فایل به صورت همزمان از اینترنت.
همچنین باید دقت داشت که در اینجا، هر Task کاری به نتایج Taskهای دیگر ندارد و کاملا مستقل اجرا میشود. اگر نیاز است Taskها مستقل اجرا شوند، از همان روش سریالی اجرای Taskها، توسط معرفی هر کدام به کمک await استفاده کنید.
به علاوه اگر در این بین استثنایی وجود داشته باشد، تنها پس از پایان عملیات تمام Taskها بازگشت داده میشود. این استثناء نیز از نوع Aggregate Exception است.
using System.Linq; using System.Threading.Tasks; namespace Async07 { public class EggBoiler { private const int BoilingTimeMs = 200; private static Task boilEgg() { var bolingTask = Task.Run(() => { Task.Delay(BoilingTimeMs); }); return bolingTask; } public async Task BoilEggsSequentialAsync(int count) { for (var i = 0; i < count; i++) { await boilEgg(); } } public async Task BoilEggsSimultaneousAsync(int count) { var tasksList = from egg in new[] { 1, 2, 3, 4, 5 } select boilEgg(); await Task.WhenAll(tasksList); // ... } } }
اما در متد BoilEggsSimultaneousAsync به علت بکارگیری Task.WhenAll پختن تمام تخم مرغهای مدنظر همزمان آغاز میشود و تا پایان عملیات (پخته شدن تمام تخم مرغها) صبر خواهد شد.
متد WhenAny
در حالت استفاده از متد WhenAny، هر کدام از Taskهای در حال پردازش که خاتمه یابند، کل عملیات خاتمه خواهد یافت. فرض کنید نیاز دارید تا دمای کنونی هوای منطقهی خاصی را از چند وب سرویس مختلف دریافت کنید. میتوان در این حالت تمام اینها را توسط WhenAny ترکیب کرد و هر کدام که زودتر خاتمه یابد، عملیات را پایان خواهد داد.
public class Downloader { private Task<string> downloadTask(string url) { return new WebClient().DownloadStringTaskAsync(url); } public async Task<int> GetTemperature() { var sites = new[] { "http://www.site1.com/svc", "http://www.site2.com/svc", "http://www.site3.com/svc", }; var tasksList = from site in sites select downloadTask(site); try { var finishedTask = await Task.WhenAny(tasksList); var result = await finishedTask; } catch (Exception ex) { } // todo: process result, get temperature return 10; // for example. } }
در این حالت اگر نیاز بود وضعیت سایر Taskها، مثلا در صورت شکست آنها، بررسی شوند، میتوان از یکی از دو قطعه کد زیر استفاده کرد:
foreach (var task in tasksList) { var ignored = task.ContinueWith( t => Console.WriteLine(t.Exception), TaskContinuationOptions.OnlyOnFaulted); } // or foreach (var task in tasksList) { var ignored = task.ContinueWith( t => { if (t.IsFaulted) Console.WriteLine(t.Exception); }); }
کاربرد دیگر WhenAny زمانی است که برای مثال میخواهید تعداد زیادی Url را پردازش کنید، اما نمیخواهید برای نمایش اطلاعات، تا پایان عملیات تمامی آنها مانند WhenAll صبر کنید. میخواهید به محض پایان کار یکی از Taskها، عملیات نمایش نتیجهی آنرا انجام دهید:
public async Task ShowTemperatures() { var sites = new[] { "http://www.site1.com/svc", "http://www.site2.com/svc", "http://www.site3.com/svc", }; var tasksList = sites.Select(site => downloadTask(site)).ToList(); while (tasksList.Any()) { try { var tempTask = await Task.WhenAny(tasksList); tasksList.Remove(tempTask); var result = await tempTask; //todo: show result } catch(Exception ex) { } } }
کاربرد سوم WhenAny کنترل تعداد وظایف همزمان است. برای مثال اگر قرار است هزاران تصویر از اینترنت دریافت شوند، نباید تمام وظایف را یکجا راه اندازی کرد. شاید نیاز باشد هربار فقط 15 وظیفهی همزمان عمل کنند و نه بیشتر. در این حالت، مثال قبلی دارای یک حلقهی کنترل کننده tasksList ارائه شده خواهد شد. هر بار تعداد معینی وظیفه به tasksList اضافه و پردازش میشوند و این روند تا پایان کار تعداد Urlها ادامه خواهد یافت (یک Take و Skip است؛ مانند صفحه بندی اطلاعات).
متدهای Run و FromResult
متد Task.Run اضافه شده در دات نت 4.5 به این معنا است که میخواهید Task ایجاد شده بر روی Thread pool اجرا شود. پارامتر آن میتواند یک delegate یا عبارت lambda و یا حتی یک Task باشد. خروجی آن نیز یک Task است و به همین جهت با async و await سی شارپ 5 سازگاری بهتری دارد.
استفاده از Task.Run نسبت به عملیات Threading متداول کارآیی بهتری دارد، زیرا ایجاد Threadهای جدید زمانبر بوده و زمانیکه به صورت خودکار از Thread pool استفاده میشود، تا حد امکان، استفادهی مجدد از تردهای بیکار در حال حاضر، مدنظر است.
متد Task.FromResult کار بازگشت یک Task را از نتایج متدهای مختلف فراهم میکند. فرض کنید یک متد async تعریف کردهاید که خروجی آن Task of T است. در اینجا اگر داخل متد، از یک متد معمولی که یک عدد int را ارائه میدهد استفاده کنیم، با استفاده از Task.FromResult بلافاصله میتوان یک Task of int را بازگشت داد.
متد Delay
پیشتر برای به خواب فرو بردن یک ترد از متد Thread.Sleep استفاده میشد. کار Thread.Sleep بلاک کردن ترد جاری است. در دات نت 4.5، بجای آن باید از Task.Delay استفاده شود که یک مکانیزم غیر قفل کننده را جهت صبر کردن به همراه بازگشت یک Task، ارائه میدهد.
یکی از کاربردهای Delay منهای صبر کردن تا مدت زمانی مشخص، ایجاد مکانیزم timeout است. برای مثال حالت Task.WhenAny را درنظر بگیرید. اگر در اینجا timeout مدنظر ما 3 ثانیه باشد، میتوان یکی از Taskها را Task.Delay با آرگومان مساوی 3000 معرفی کرد. اگر هر کدام از taskهای تعریف شده زودتر از 3 ثانیه پایان یافتند که بسیار خوب؛ در غیر اینصورت Task.Delay معرفی شده کار را تمام میکند.
متد Yield
متد Task.Yield بسیار شبیه به متد قدیمی DoEvents است که از آن برای اجازه دادن به سایر اعمال جهت اجرا، در بین یک عمل طولانی، استفاده میشد.
متد ConfigureAwait
به صورت پیش فرض ادامه یک عملیات همزمان، بر روی ترد ایجاد کنندهی آن اجرا میشود. برای نمونه اگر یک عملیات async در ترد UI آغاز شود، نتیجهی آن نیز در همان ترد UI بازگشت داده میشود. به این ترتیب دیگر نیازی نخواهد بود تا نگرانی در مورد نحوهی دسترسی به مقدار آن توسط عناصر UI داشته باشیم.
اگر به این مساله اهمیت نمیدهید، برای مثال اگر اعمال در حال انجام، کاری به عناصر UI ندارند، از متد ConfigureAwait با پارامتر false بر روی یک task پیش از فراخوانی await بر روی آن، استفاده کنید.
byte [] buffer = new byte[0x1000]; int numRead; while((numRead = await source.ReadAsync(buffer, 0, buffer.Length).ConfigureAwait(false)) > 0) { await source.WriteAsync(buffer, 0, numRead).ConfigureAwait(false); }
به صورت خلاصه در سی شارپ 5
- بجای task.Wait قدیمی، از await task برای صبر کردن تا پایان یک task استفاده کنید.
- بجای task.Result جهت دریافت یک نتیجهی یک task از await task کمک بگیرید.
- بجای Task.WaitAll از await Task.WhenAll و بجای Task.WaitAny از await Task.WhenAny استفاده نمائید.
- همچنین Thread.Sleep در اعمال async با await Task.Delay جایگزین شدهاست.
- در اعمال غیرهمزمان همیشه متد ConfigureAwait false را بکار بگیرید، مگر اینکه به Context نهایی آن واقعا نیاز داشته باشید.
و برای ایجاد یک Task جدید از Task.Run یا TaskFactory.StartNew استفاده نمائید.
Portable Class Library برای تولید Assembly مدیریت شده که قابیلت استفاده در اکثر تکنولوژیها نظیر (WP7(Windows Phone 7 و WPF و Silverlight و Windows Store App و حتی XBox را داراست استفاده میشود. این نوع پروژهها میزان استفاده مجدد از کدها رو به حداکثر ممکن میرسونه و در عوض تعداد پروژههای مورد نیاز رو به حداقل. مورد اصلی استفاده از اونها برای تولید Multi-Targeted Application هاست. برای مثال در تولید پروژههای تحت Windows که با تکنولوژی WPF پیاده سازی میشوند پروژه ViewModel و Model رو با این تکنولوژی پیاده سازی میکنند تا در آینده اگر نیاز بود قسمتی از پروژه با استفاده از Silverlight یا Windows Store App انجام بشه بتونیم Model , ViewModel نوشته شده رو به این پروژهها Reference بدیم. تا قبل از برای انجام این کار باید این دو بخش رو دوباره برای هر تکنولوژی بازنویسی میکردیم.
روش استفاده
زمانی که یک پروژه از نوع Portable Class Library رو ایجاد میکنیم باید حداقل 2 یا چند تا از Platformهای مورد نظر رو انتخاب کنیم. به صورت زیر :
بعد از انتخاب گزینه Portable Class Library و زدن کلید Enter فرم زیر ظاهر خواهد شد که در این قسمت باید Platformهای مورد نظر رو انتخاب کنیم.
در اینجا من 2 Platform رو انتخاب کردم. یکی Silverlight و Net 4.5. یعنی این Portable Class Library هم میتونه به پروژه Silverlight و هم به Class library .Net 4.5 رفرنس داده بشه.
حتما میپرسید چه طوری؟
در واقع Microsoft برای انجام این کار فقط یک سری از Referenceهای مشترک بین این 2 Platform رو به پروژه اضافه میکنه و همین موضوع باعث شده کار با این پروژهها نیاز به یکم مهارت داشته باشه.
برای مثال اگر قصد استفاده از تکنولوژی Async&Await رو دارید باید یکم به خودتون زحمت بدید و CTP مورد نظر رو نصب کنید.(حالا اگر از Net4 استفاده میکنید که باید از یک روش دیگه استفاده کنید که در یک مقاله جداگانه براتون توضیح خواهم داد).
به جدول زیر دقت کنید.
Xbox 360 | Windows Phone | Silverlight | Windows Store | .NET Framework | Feature |
√ | √ | √ | √ | √ | Core |
√ | √ | √ | √ | LINQ | |
Only 7.5 | √ | √ | √ | IQueryable | |
√ | √ | Only 4.5 | Dynamic keyword | ||
√ | √ | √ | Managed Extensibility Framework (MEF) | ||
√ | √ | √ | √ | Network Class Library (NCL) | |
√ | √ | √ | √ | Serialization | |
√ | √ | √ | √ | Windows Communication Foundation (WCF) | |
√ | √ | √ |
Only 4.5 | Model-View-View Model (MVVM) | |
√ | √ | Only 4.0.3 and 4.5 | Data annotations | ||
√ | √ | √ | √ | Only 4.0.3 and 4.5 | XLINQ |
در جدول بالا به صورت کامل مشخص شده که در هر پلاتفرم چه چیزی Support میشه. برای مثال Data Annotation فقط در Net4.3 , 4.5 قابل استفاده است.
اسمبلیهای زیر در یک Portable Class Library قابل استفاده هستند.
mscorlib.dll
System.dll
System.Core.dll
System.Xml.dll
System.ComponentModel.Composition.dll
System.Net.dll
System.Runtime.Serialization.dll
System.ServiceModel.dll
System.Xml.Serialization.dll
System.Windows.dll - From Silverlight
پیاده سازی یک مثال عملی
در این مثال قصد دارم یک کلاس برای مدیریت تاریخ شمسی درست کنم. مراحل زیر رو دنبال کنید
یک Portable Class Library به نام Common به پروژه اضافه کنید.
یک کلاس به نام PersianDate به برنامه اضافه کرده به صورت زیر
public class PersianDate<TCalendar> where TCalendar : System.Globalization.Calendar { public PersianDate() { this.CurentCalendar = System.Activator.CreateInstance<TCalendar>(); } public TCalendar CurentCalendar { get; private set; } public string GetDate() { return string.Format( "{0}/{1}/{2}", this.CurentCalendar.GetYear( DateTime.Today ).ToString( "####0000" ) , this.CurentCalendar.GetMonth( DateTime.Today ).ToString( "##00" ) , this.CurentCalendar.GetDayOfMonth( DateTime.Today ).ToString( "##00" ) ); } }
حالا یک پروژه از نوع Console Application به برنامه اضافه کنید و یک Reference به پروژه Common بدید و بعد کلاس زیر رو بنویسید.
public class CustomPersianDate { public CustomPersianDate() { } public static Common.PersianDate<System.Globalization.PersianCalendar> PersianCalendar { get { return _persianCalendar ?? ( _persianCalendar = new Common.PersianDate<System.Globalization.PersianCalendar>() ); } } private static Common.PersianDate<System.Globalization.PersianCalendar> _persianCalendar; }
حالا یک پروژه از نوع Silverlight به برنامه اضافه کنید و یک Reference به پروژه Common بدید و بعد کلاس بالا بدون تغییر بنویسید.
نمای کلی پروژه باید به صورت زیر باشد.
بعد پروژه ConsoleApplication رو به عنوان پروژه StartUp انتخاب کنید و فایل Program رو به صورت زیر تغییر بدید.
class Program { static void Main( string[] args ) { Console.WriteLine( "Today Is ?{0}", CustomPersianDate.PersianCalendar.GetDate() ); Console.ReadLine(); } }
خوب نتیجه به صورت زیر خواهد بود:
برای پروژه Silverlight هم نتیجه قطعا به همین صورت است.
همان طور که دید انتخاب نوع Calendar به خود Applicationها واگذار شد و شما میتونید هر نوع تقویم رو به عنوان TCalendar تعیین کنید.
امیدوارم شما هم مثل من به این تکنولوژی دلچسب علاقه پیدا کرده باشید.
using System; using System.Collections; using System.Web.Mvc; using System.Xml.Serialization; namespace Neoox.Core.SeoTools { [XmlRoot("urlset", Namespace = "http://www.sitemaps.org/schemas/sitemap/0.9")] public class Sitemap { private ArrayList map; public Sitemap() { map = new ArrayList(); } [XmlElement("url")] public Location[] Locations { get { Location[] items = new Location[map.Count]; map.CopyTo(items); return items; } set { if (value == null) return; Location[] items = (Location[])value; map.Clear(); foreach (Location item in items) map.Add(item); } } public int Add(Location item) { return map.Add(item); } } public class Location { public enum eChangeFrequency { always, hourly, daily, weekly, monthly, yearly, never } [XmlElement("loc")] public string Url { get; set; } [XmlElement("changefreq")] public eChangeFrequency? ChangeFrequency { get; set; } public bool ShouldSerializeChangeFrequency() { return ChangeFrequency.HasValue; } [XmlElement("lastmod")] public DateTime? LastModified { get; set; } public bool ShouldSerializeLastModified() { return LastModified.HasValue; } [XmlElement("priority")] public double? Priority { get; set; } public bool ShouldSerializePriority() { return Priority.HasValue; } } public class XmlResult : ActionResult { private object objectToSerialize; public XmlResult(object objectToSerialize) { this.objectToSerialize = objectToSerialize; } public object ObjectToSerialize { get { return this.objectToSerialize; } } public override void ExecuteResult(ControllerContext context) { if (this.objectToSerialize != null) { context.HttpContext.Response.Clear(); var xs = new System.Xml.Serialization.XmlSerializer(this.objectToSerialize.GetType()); context.HttpContext.Response.ContentType = "text/xml"; xs.Serialize(context.HttpContext.Response.Output, this.objectToSerialize); } } } }
public ActionResult Sitemap() { Sitemap sm = new Sitemap(); sm.Add(new Location() { Url = string.Format("http://www.TechnoDesign.ir/Articles/{0}/{1}", 1, "SEO-in-ASP.NET-MVC"), LastModified = DateTime.UtcNow, Priority = 0.5D }); return new XmlResult(sm); }
روشهای مختلف اطلاع رسانی به سیستم ردیابی تغییرات
متد DbSet.Add کار اطلاع رسانی تبدیل وهلههای ثبت شده را به کوئریهای Insert رکوردهای جدید، انجام میدهد:
using (var db = new BloggingContext()) { var blog = new Blog { Url = "http://sample.com" }; db.Blogs.Add(blog); db.SaveChanges(); }
سیستم ردیابی اطلاعات، اگر تغییراتی را در خواص اشیاء تحت نظر خود مشاهده کند، سبب تولید کوئریهای Update میگردد. یک چنین اشیایی تحت نظر Context هستند:
الف) اشیایی که در طول عمر Context از دیتابیس کوئری گرفته شدهاند.
ب) اشیایی که در طول عمر Context به آن اضافه شدهاند (حالت قبل).
using (var db = new BloggingContext()) { var blog = db.Blogs.First(); blog.Url = "http://sample.com/blog"; db.SaveChanges(); }
و متد DbSet.Remove کار اطلاع رسانی تبدیل وهلههای حذف شده را به کوئریهای Delete معادل، انجام میدهد:
using (var db = new BloggingContext()) { var blog = db.Blogs.First(); db.Blogs.Remove(blog); db.SaveChanges(); }
به علاوه امکان ترکیب متدهای Add، Remove و همچنین به روز رسانی اشیاء در طی یک Context و با فراخوانی یک SaveChanges در انتهای کار نیز وجود دارد. از این جهت که یک Context، الگوی واحد کار را پیاده سازی میکند و بیانگر یک تراکنش است. در این حالت ترکیبی، یا کل تراکنش با موفقیت به پایان میرسد و یا در صورت بروز مشکلی، هیچکدام از تغییرات درخواستی، اعمال نخواهند شد.
عملیات ردیابی، بر روی هر نوع Projections صورت نمیگیرد
اگر توسط LINQ Projections، نتیجهی نهایی کوئری را تغییر دادید، فقط در زمانی سیستم ردیابی بر روی آن فعال خواهد بود که projection نهایی حاوی اصل موجودیت مدنظر باشد. برای مثال در کوئری ذیل چون در Projection صورت گرفتهی در متد Select، هنوز در خاصیت Blog، به اصل موجودیت Blog اشاره میشود، نتیجهی این کوئری نیز تحت نظر سیستم ردیابی خواهد بود:
using (var context = new BloggingContext()) { var blog = context.Blogs .Select(b => new { Blog = b, Posts = b.Posts.Count() }); }
using (var context = new BloggingContext()) { var blog = context.Blogs .Select(b => new { Id = b.BlogId, Url = b.Url }); }
لغو سیستم ردیابی تغییرات، در زمانیکه به آن نیازی نیست
سیستم ردیابی تغییرات بر اساس مفاهیم AOP و تولید پروکسیهای آن کار میکند. این پروکسیها، اشیایی شفاف هستند که اشیاء شما را احاطه میکنند و هر تغییری را که اعمال میکنید، ابتدا از این غشاء رد شده و در سیستم ردیابی EF ثبت میشوند. سپس به وهلهی اصلی شیء موجود اعمال خواهند شد.
بدیهی است تولید این پروکسیها، دارای سربار است و اگر هدف شما صرفا کوئری گرفتن از اطلاعات، جهت نمایش آنها است، نیازی به تولید خودکار این پروکسیها را ندارید و این مساله سبب کاهش مصرف حافظهی برنامه و بالا رفتن سرعت آن میشود.
در قسمت قبل عنوان شد که «یک چنین اشیایی تحت نظر Context هستند: الف) اشیایی که در طول عمر Context از دیتابیس کوئری گرفته شدهاند.»
اگر میخواهید این حالت پیش فرض را لغو کنید، از متد AsNoTracking استفاده نمائید:
using (var context = new BloggingContext()) { var blogs = context.Blogs.AsNoTracking().ToList(); }
اگر میخواهید متد AsNoTracking را به صورت خودکار به تمام کوئریهای یک context خاص اعمال کنید، روش کار و تنظیم آن به صورت زیر است:
using (var context = new BloggingContext()) { context.ChangeTracker.QueryTrackingBehavior = QueryTrackingBehavior.NoTracking;
نکات به روز رسانی ارجاعات موجودیتها
دو حالت زیر را درنظر بگیرید که در اولی، blog از بانک اطلاعاتی واکشی شدهاست و post به صورت مستقیم وهله سازی شدهاست:
using (var context = new BloggingContext()) { var blog = context.Blogs.First(); var post = new Post { Title = "Intro to EF Core" }; blog.Posts.Add(post); context.SaveChanges(); }
using (var context = new BloggingContext()) { var blog = new Blog { Url = "http://blogs.msdn.com/visualstudio" }; var post = context.Posts.First(); blog.Posts.Add(post); context.SaveChanges(); }
در حالت دوم، ابتدا blog در بانک اطلاعاتی ثبت میشود (چون برخلاف حالت اول، تحت نظر context نیست) و سپس این post (که تحت نظر context است) به مجموعه مطالب آن اضافه میشود (بلاگ جدیدی اضافه شده و ارجاع مطلب موجودی به آن اضافه میشود).
وارد کردن یک موجودیت به سیستم ردیابی اطلاعات
در مثال قبل مشاهده کردیم که اگر موجودیتی تحت نظر context نباشد (برای مثال توسط یک کوئری به context وارد نشده باشد)، در حین ذخیره سازی ارجاعات، با آن به صورت یک وهلهی جدید رفتار شده و حتما در بانک اطلاعاتی به صورت یک رکورد جدید ذخیره میشود؛ حتی اگر Id آنرا دستی تنظیم کرده باشید که ندید گرفته خواهد شد.
اگر Id و سایر اطلاعات شیءایی را دارید، نیازی نیست تا حتما توسط یک کوئری ابتدا آنرا از بانک اطلاعاتی دریافت و سپس به صورت خودکار وارد سیستم ردیابی کنید؛ متد Attach نیز یک چنین کاری را انجام میدهد:
var blog = new Blog { Id = 2, Url = "https://www.dntips.ir" }; context.Blog.Attach(blog); context.SaveChanges();
علاوه بر متد Attach، متد AttachRange نیز برای افزودن لیستی از موجودیتها در حالت EntityState.Unchanged، پیش بینی شدهاست.
روش دیگر انجام اینکار به صورت ذیل است:
در اینجا ابتدا یک وهلهی جدید از Blog ایجاد شدهاست و سپس توسط متد Entry به Context وارد شده و همچنین حالت آن به صورت صریح، به تغییر یافته، مشخص گردیدهاست:
var blog = new Blog { Id = 2, Url = "https://www.dntips.ir" }; context.Entry(blog).State = EntityState.Modified ; context.SaveChanges();
var blog = new Blog { Id = 2, Url = "https://www.dntips.ir" }; context.Update(blog); context.SaveChanges();
به علاوه متد UpdateRange نیز برای افزودن لیستی از موجودیتها در حالت EntityState.Modified، پیش بینی شدهاست.
یک نکته: متدهای Attach و Update، هم بر روی یک DbSet و هم بر روی Context، قابل اجرا هستند. اگر بر روی Context اجرا شدند، نوع موجودیت دریافتی به نوع DbSet متناظر به صورت خودکار نگاشت شده و استفاده میشود (context.Set<T>().Attach(entity)). یعنی در حقیقت بین این دو حالت تفاوتی نیست و امکان فراخوانی این متدها بر روی Context، صرفا جهت سهولت کار درنظر گرفته شدهاست.
تفاوت رفتار context.Entry در EF Core با EF 6.x
متد context.Entry در EF 6.x هم وجود دارد. اما در EF core سبب تغییر وضعیت گراف متصل به یک شیء نمیشود و ضعیت روابط آنرا به روز رسانی نمیکند (برخلاف EF 6.x). اگر در EF Core نیاز به یک چنین به روز رسانی گراف مانندی را داشتید، باید از متد جدید context.ChangeTracker.TrackGraph به نحو ذیل استفاده نمائید:
context.ChangeTracker.TrackGraph(blog, e => e.Entry.State = EntityState.Added);
کوئری گرفتن از سیستم ردیابی اطلاعات
این سناریوها را درنظر بگیرید:
- میخواهم سیستمی شبیه به تریگرهای اس کیوال سرور را با EF داشته باشم.
- میخواهم اطلاعات تمام رکوردهای ثبت شده، حذف شده و به روز رسانی شده را لاگ کنم.
- میخواهم پس از ثبت رکوردی در هر جای برنامه، شبیه به مباحث SQL Server Service Broker و SqlDependency بلافاصله مطلع شده و توسط SignalR اطلاع رسانی کنم.
و در حالت کلی میخواهم پیش و یا پس از ثبت اطلاعات، بتوانم به تغییرات صورت گرفته دسترسی داشته باشم و عملیاتی را بر روی آنها انجام دهم. تمام این موارد و سناریوها را با کوئری گرفتن از سیستم ردیابی اطلاعات EF میتوان پیاده سازی کرد.
برای نمونه در مطلب قبل و قسمت «طراحی یک کلاس پایه، بدون تنظیمات ارث بری روابط»، یک کلاس پایه را که مقادیر پیش فرض خود را از SQL Server دریافت میکند، طراحی کردیم. در اینجا میخواهیم با استفاده از سیستم ردیابی EF، طراحی این کلاس پایه را عمومی کرده و سازگار با تمام بانکهای اطلاعاتی موجود کنیم.
جهت یادآوری، کلاس پایه موجودیتها، یک چنین شکلی را داشته:
public class BaseEntity { public int Id { set; get; } public DateTime? DateAdded { set; get; } public DateTime? DateUpdated { set; get; } }
public class Person : BaseEntity { public string FirstName { get; set; } public string LastName { get; set; } }
public class ApplicationDbContext : DbContext { // same as before public override int SaveChanges() { this.ChangeTracker.DetectChanges(); var modifiedEntries = this.ChangeTracker .Entries<BaseEntity>() .Where(x => x.State == EntityState.Modified); foreach (var modifiedEntry in modifiedEntries) { modifiedEntry.Entity.DateUpdated = DateTime.UtcNow; } var addedEntries = this.ChangeTracker .Entries<BaseEntity>() .Where(x => x.State == EntityState.Added); foreach (var addedEntry in addedEntries) { addedEntry.Entity.DateAdded = DateTime.UtcNow; } return base.SaveChanges(); } }
در اینجا کار با کوئری گرفتن از خاصیت ChangeTracker شروع میشود. سپس باید مشخص کنیم چه نوع موجودیتهایی را مدنظر داریم. چون تمام موجودیتهای ما از کلاس پایهی BaseEntity مشتق میشوند، بنابراین کوئری گرفتن بر روی این نوع، به معنای دسترسی به تمام موجودیتهای برنامه نیز هست. سپس در اینجا اگر حالتی EntityState.Modified بود، فقط مقدار خاصیت DateUpdated را به صورت خودکار مقدار دهی میکنیم و اگر حالتی EntityState.Added بود، تنها مقدار خاصیت DateAdded را به روز رسانی خواهیم کرد.
در یک چنین حالتی دیگر نیازی نیست تا مقادیر این خواص را در حین ثبت اطلاعات برنامه به صورت دستی مشخص کنیم.
یک نکته: اگر به ابتدای متد بازنویسی شده دقت کنید، فراخوانی متد this.ChangeTracker.DetectChanges در آن انجام شدهاست. علت اینجا است که این فراخوانی به صورت خودکار توسط متد base.SaveChanges انجام میشود، اما چون این مرحله را تا انتهای متد بازنویسی شده، به تاخیر انداختهایم، نیاز است خودمان به صورت دستی سبب محاسبهی مجدد تغییرات صورت گرفته شویم.
نکتهای در مورد بهبود کیفیت کدهای متد SaveChanges: استفادهی Change Tracker به این صورت با بازنویسی متد SaveChanges بسیار مرسوم است. اما پس از مدتی به متد SaveChanges ایی خواهید رسید که کنترل آن از دست خارج میشود. به همین جهت برای EF 6.x پروژههایی مانند EFHooks طراحی شدهاند تا کپسوله سازی بهتری را بتوان ارائه داد. انتقال کدهای آن به EF Core کار مشکلی نیست و اصل آن، بازنویسی HookedDbContext آن است که نحوهی مدیریت شکیلتر کوئری گرفتن از ChangeTracker را بیان میکند.
خواص سایهای یا Shadow properties
EF Core به همراه مفهوم کاملا جدیدی است به نام خواص سایهای. این نوع خواص در سمت کدهای ما و در کلاسهای موجودیتهای برنامه وجود خارجی نداشته، اما در سمت جداول بانک اطلاعاتی وجود دارند و اکنون امکان کوئری گرفتن و کار کردن با آنها در EF Core میسر شدهاست.
برای تعریف آنها، بجای افزودن خاصیتی به کلاسهای برنامه، کار از متد OnModelCreating به نحو ذیل شروع میشود:
protected override void OnModelCreating(ModelBuilder modelBuilder) { modelBuilder.Entity<Blog>().Property<DateTime>("DateAdded");
سپس برای کار کردن و کوئری گرفتن از آن میتوان از متد جدید EF.Property، به نحو ذیل استفاده کرد:
var blogs = context.Blogs.OrderBy(b => EF.Property<DateTime>(b, "DateAdded"));
context.Entry(myBlog).Property("DateAdded").CurrentValue = DateTime.Now;
foreach (var addedEntry in addedEntries) { addedEntry.Property("DateAdded").CurrentValue = DateTime.UtcNow; }
یکی از مواردی که در تمام برنامههای فارسی "باید" رعایت شود (مهم نیست به چه زبانی یا چه سکویی باشد یا چه بانک اطلاعاتی مورد استفاده است)، بحث اصلاح "ی" و "ک" دریافتی از کاربر و یکسان سازی آنها میباشد. به عبارتی برنامهی فارسی که اصلاح خودکار این دو مورد را لحاظ نکرده باشد دیر یا زود به مشکلات حادی برخورد خواهد کرد و "ناقص" است : اطلاعات بیشتر ؛ برای مثال شاید دوست نداشته باشید که دو کامران در سایت شما ثبت نام کرده باشند؛ یکی با ک فارسی و یکی با ک عربی! به علاوه همین کامران امروز میتواند لاگین کند و فردا با یک کامپیوتر دیگر و صفحه کلیدی دیگر پشت درب خواهد ماند. در حالیکه از دید این کامران، کلمه کامران همان کامران است!
بنابراین در دو قسمت "باید" این یکسان سازی صورت گیرد:
الف) پیش از ثبت اطلاعات در بانک اطلاعاتی (تا با دو کامران ثبت شده در بانک اطلاعاتی مواجه نشوید)
ب) پیش از جستجو (تا کامران روزی دیگر با صفحه کلیدی دیگر بتواند به برنامه وارد شود)
راه حل یکسان سازی هم شاید به نظر این باشد: رخداد فشرده شدن کلید را کنترل کنید و سپس جایگزینی را انجام دهید (مثلا ی عربی را با ی فارسی جایگزین کنید). این روش چند ایراد دارد:
الف) Silverlight به دلایل امنیتی اصلا چنین اجازهای را به شما نمیدهد! (تا نتوان کلیدی را جعل کرد)
ب) همیشه با یک TextBox ساده سر و کار نداریم. کنترلهای دیگری هم هستند که امکان ورود اطلاعات در آنها وجود دارد و آن وقت باید برای تمام آنها کد نوشت. ظاهر کدهای برنامه در این حالت در حجم بالا، اصلا جالب نخواهد بود و ضمنا ممکن است یک یا چند مورد فراموش شوند.
راه بهتر این است که دقیقا حین ثبت اطلاعات یا جستجوی اطلاعات در لایهای که تمام ثبتها یا اعمال کار با بانک اطلاعاتی برنامه به آنجا منتقل میشود، کار یکسان سازی صورت گیرد. به این صورت کار یکپارچه سازی یکبار باید انجام شود اما تاثیرش را بر روی کل برنامه خواهد گذاشت، بدون اینکه هرجایی که امکان ورود اطلاعات هست روالهای رخداد گردان هم حضور داشته باشند.
در مورد مقدمات WCF RIA Services که درSilverlight و ASP.NET کاربرد دارد میتوانید به این مطلب مراجعه کنید: +
جهت تکمیل این بحث متدی تهیه شده که کار یکسان سازی ی و ک دریافتی از کاربر را حین ثبت توسط امکانات WCF RIA Services انجام میدهد (دقیقا پیش از فراخوانی متد SubmitChanges باید بکارگرفته شود):
namespace SilverlightTests.RiaYeKe
{
public static class PersianHelper
{
public static string ApplyUnifiedYeKe(this string data)
{
if (string.IsNullOrEmpty(data)) return data;
return data.Replace("ی", "ی").Replace("ک", "ک");
}
}
}
using System.Linq;
using System.Windows.Controls;
using System.Reflection;
using System.ServiceModel.DomainServices.Client;
namespace SilverlightTests.RiaYeKe
{
public class RIAHelper
{
/// <summary>
/// یک دست سازی ی و ک در عبارات ثبت شده در بانک اطلاعاتی پیش از ورود به آن
/// این متد باید پیش از فراخوانی متد
/// SubmitChanges
/// استفاده شود
/// </summary>
/// <param name="dds"></param>
public static void ApplyCorrectYeKe(DomainDataSource dds)
{
if (dds == null)
return;
if (dds.DataView.TotalItemCount <= 0)
return;
//پیدا کردن موجودیتهای تغییر کرده
var changedEntities = dds.DomainContext.EntityContainer.GetChanges().Where(
c => c.EntityState == EntityState.Modified ||
c.EntityState == EntityState.New);
foreach (var entity in changedEntities)
{
//یافتن خواص این موجودیتها
var propertyInfos = entity.GetType().GetProperties(
BindingFlags.Public | BindingFlags.Instance
);
foreach (var propertyInfo in propertyInfos)
{
//اگر این خاصیت رشتهای است ی و ک آن را استاندارد کن
if (propertyInfo.PropertyType != typeof (string)) continue;
var propName = propertyInfo.Name;
var val = new PropertyReflector().GetValue(entity, propName);
if (val == null) continue;
new PropertyReflector().SetValue(
entity,
propName,
val.ToString().ApplyUnifiedYeKe());
}
}
}
}
}
توضیحات:
از آنجائیکه حین فراخوانی متد SubmitChanges فقط موجودیتهای تغییر کرده جهت ثبت ارسال میشوند، ابتدا این موارد یافت شده و سپس خواص عمومی تک تک این اشیاء توسط عملیات Reflection بررسی میگردند. اگر خاصیت مورد بررسی از نوع رشتهای بود، یکبار این یک دست سازی اطلاعات ی و ک دریافتی صورت خواهد گرفت (و از آنجائیکه این تعداد همیشه محدود است عملیات Reflection سربار خاصی نخواهد داشت).
اگر در کدهای خود از DomainDataSource استفاده نمیکنید باز هم تفاوتی نمیکند. متد ApplyCorrectYeKe را از قسمت DomainContext.EntityContainer به بعد دنبال کنید.
اکنون تنها مورد باقیمانده بحث جستجو است که با اعمال متد ApplyUnifiedYeKe به مقدار ورودی متد جستجوی خود، مشکل حل خواهد شد.
کلاس PropertyReflector بکارگرفته شده هم از اینجا به عاریت گرفته شد.
دریافت کدهای این بحث
using System.Web; using System.Web.Mvc; using BundlingAndMinifyingInlineCssJs.ResponseFilters; namespace UILayer.Filters { public class BundleMinifyingInlineCssJSAttribute : ActionFilterAttribute { public override void OnActionExecuting(ActionExecutingContext filterContext) { filterContext.HttpContext.Response.Filter = new BundleAndMinifyResponseFilter(filterContext.HttpContext.Response.Filter); } } }
[BundleMinifyingInlineCssJS] public partial class HomeController : Controller { }
EF Code First #7
pulbic class User { public int Id { get; set; } public string FullName { get; set; } public ICollection<Comment> Comments { get; set; } } public class Comment { public int Id { get; set; } public string Text { get; set; } public int UserId { get; set; } public int? UserId2 { get; set; } [ForeignKey(nameof(UserId)) public virtual User User { get; set; } [ForeignKey(nameof(UserId2)) public virtual User User2 { get; set; } }
public enum CustomerType { Person = 0, Company = 1 } public class Customer { public CustomerType Type { get; set; } }
با وجود چنین کلاسی از مشتری و نیاز به انجام فعالیتهای مختلفی بر روی آن، احتمالا نیاز خواهد بود که در بخشهای مختلف کد، گذارهی switch ای مانند زیر را اضافه کنید:
switch (customer.Type) { case CustomerType.Person: // calculate discount, or send message or edit customer or anything else break; case CustomerType.Company: // calculate discount, or send message or edit customer or anything else break; default: throw new ArgumentOutOfRangeException(); }
برای انجام فعالیتهای مختلفی مانند محاسبه تخفیف، ارسال پیام و یا ویرایش مشتری، نیاز خواهد بود این گذاره تکرار شود که خود این موضوع بوی بد duplicate code است و به الگوی shotgun surgery نیز ختم خواهد شد.
حال فرض کنید نیاز است مشتریان حقوقی، خود به دو نوع مشتری حقوقی بخش خصوصی و مشتری حقوقی بخش دولتی تقسیم شوند. در پیاده سازی ذکر شده باید به CustomerType یک آیتم افزوده شود و در تمامی switchها نیز در صورت نیاز شرط مربوط به آن اضافه شود.
برای حل این نوع از کد بد بو، معمولا یک کلاس پدر را به نام مشتری ایجاد کرده و کلاسهای مختص هر یک از انواع مشتری را از آن به ارث میبرند (Replace type code with subclass):
یا میتوان طراحی را کمی متفاوتتر و به صورت زیر انجام داد:
دلیل مشابه دیگر ایجاد این الگوی بد کد استفاده از type code به عنوان وضعیت یک تایپ است. که در این صورت میتوان بجای type code از state object استفاده کرد (Replace type code with strategy). به این مورد در مباحث مربوط به refactoring به طور مفصل پرداخته شده است.
جمع بندی
این کد بد بو در شرایط متفاوتی ایجاد میشود. با این حال یکی از پر تکرارترین آنها استفاده بد یا عدم استفاده از الگوهای طراحی شیء گرا است. تصحیص این الگوی بد، به خوانایی و نگهداری کد در بلند مدت کمک بسیار زیادی میکند.