بررسی اجزای اولین آزمایش با Postman
آزمونهای Postman، عموما یک سری Assertion هستند؛ به این معنا که در آنها، مقداری از Response دریافتی از سرور را با مقداری مشخص و مورد انتظار، مقایسه میکنیم:
pm.test("Status code is 200", function () { pm.response.to.have.status(200); });
چند نکته:
- آزمونهای Postman، با متد pm.test شروع میشوند. هدف از آن، نوشتن بدنهی یک آزمون متشکل از چندین Assertion است. اولین پارامتر آن، نام رشتهای آزمون است. پارامتر دوم آن، یک callback function است که پس از پایان درخواست جاری، اجرا میشود.
- روش اجرای آزمونها در اینجا non-blocking است. یعنی آزمونهای نوشته شده، به موازات هم اجرا شده و نتایج و حتی خطاهای آنها بر روی یکدیگر تاثیرگذار نیستند.
- برای یک Response و اجزای مختلف آن، میتوان چندین آزمون را نوشت و هر آزمون میتواند چندین Assertion را داشته باشد.
- در Postman، آزمونها تنها پس از پایان اجرای درخواستها، اجرا میشوند.
- به شیء pm.response در اینجا، response assertion API میگویند. توسط آن میتوان به اجزای مختلف response مانند status code، هدرها و یا بدنهی بازگشتی از سمت سرور، دسترسی یافت و برای آنها یک Assertion را نوشت.
لیستی از بررسیهای متداول، در حین نوشتن آزمونهای Postman
تا اینجا روش بررسی status code را در حین نوشتن آزمونهای Postman بررسی کردیم. در جدول زیر، مهمترین حالاتی را که جهت بررسی خروجی یک API میتوان مدنظر داشت، برشمرده شدهاند:
نوع بررسی | Response assertions |
بررسی مقدار status code دریافتی از سرور با مقدار مورد انتظار | pm.response.to.have.status(200); |
آیا status code دریافتی، معادل یکی از مقادیر مشخص شدهاست؟ | pm.expect(pm.response.code).to.be.oneOf([201,202]); |
آیا status name دریافتی از سرور، معادل عبارت مشخصی است؟ | response.to.have.status("Created"); |
مقایسهی مقدار responseTime با مقدار مورد انتظار | pm.expect(pm.response.responseTime).to.be.below(200); |
آیا هدر تنظیم شدهی توسط response، دارای کلید مورد انتظار است؟ | pm.response.to.have.header("X-Cache"); |
آیا هدر تنظیم شدهی توسط response، دارای کلید و مقدار مشخصی است؟ | pm.response.to.have.header("X-Cache", "HIT"); |
آیا نام یکی از کوکیهای تنظیم شدهی توسط response، معادل مقدار مورد انتظار است؟ | pm.expect(pm.cookies.has("sessionId")).to.be.true; |
آیا نام و مقدار یکی از کوکیهای تنظیم شدهی توسط response، معادل مقادیر مشخصی هستند؟ | pm.expect(pm.cookies.get("sessionId")).to.equal("abcb9s"); |
آیا بدنهی response، دقیقا معادل مقدار مشخص است؟ | pm.response.to.have.body("OK"); |
آیا بدنهی response، حاوی مقدار مشخصی است؟ | pm.expect(pm.response.text()).to.include("Order placed."); |
یک نکته: در رابط کاربری Postman، زمانیکه برگهی Tests را انتخاب میکنیم، کنار آن لیستی از code snippets نیز قرار دارند که با کلیک بر روی آنها، میتوان حالت عمومی اکثر موارد فوق را به صورت خودکار تولید کرد:
روش بررسی اجزای خروجی با فرمت JSON از سرور
فرض کنید API شما یک چنین خروجی JSON ای را بازگشت میدهد:
{ "id": 12, "name": "DNT", "isDeleted": false, "prefs": { "comments": "members", "voting": "disabled" } }
pm.test("Your test name", function () { var jsonData = pm.response.json(); pm.expect(jsonData.name).to.eql("DNT"); pm.expect(jsonData.prefs.voting).to.eql("disabled"); pm.expect(jsonData.isDeleted).to.eql(false); });
ساماندهی بهتر آزمونهای نوشته شده
البته میتوان تمام Response assertions مدنظر را داخل یک callback function نیز قرار داد، اما بهتر است هر کدام را و یا گروهی از آنها را که به هم مرتبط هستند، توسط یک pm.test جدید تعریف کرد تا بتوان به ساماندهی بهتر رسید و همچنین زمانیکه این آزمونها بررسی میشوند، گزارش بهتری را نیز مشاهده نمود. به همین جهت برای نمونه میتوان آزمایش فوق را به دو آزمایش مجزا تبدیل کرد که در یکی ایجاد مطلب جدید و در دیگری، ویژگیهای آن مطلب بررسی شدهاند:
pm.test("Post should be created", function () { var jsonData = pm.response.json(); pm.expect(jsonData.name).to.eql("DNT"); pm.expect(jsonData.isDeleted).to.eql(false); }); pm.test("Post's voting feature should be disabled", function () { var jsonData = pm.response.json(); pm.expect(jsonData.prefs.voting).to.eql("disabled"); });
ساده سازی و همچنین بهبود کارآیی آزمونهای نوشته شده
چون در اینجا چندینبار از ()var jsonData = pm.response.json داخل هر آزمایش استفاده شدهاست و در عمل یک شیء response نیز بیشتر وجود ندارد، میتوان جهت کاهش این تکرار و بهبود کارآیی آزمونهای نوشته شده، آنرا به صورت یک ثابت، به پیش از تمام آزمایشها منتقل کرد:
const jsonData = pm.response.json(); pm.test("Post should be created", function () { pm.expect(jsonData.name).to.eql("DNT"); pm.expect(jsonData.isDeleted).to.eql(false); }); pm.test("Post's voting feature should be disabled", function () { pm.expect(jsonData.prefs.voting).to.eql("disabled"); });
سیستم عامل غالب مشتریهای شما کدام است؟
ویندوز 7
ویندوز 8
ویندوز 10
ویندوز سرور 2003
ویندوز سرور 2008
ویندوز سرور 2012
لینوکس
مک
کار با کلیدهای اصلی و خارجی در EF Code first
اگر برای دیتابیس موجود قصد دارید mapping تعریف کنید ممکن است کلیدهای تعریف شده در آن کم یا زیاد باشند. بهتر است یک خروجی مستقل از کلاسهای فوق تهیه کنید (اجازه بدید EF دیتابیس را تولید کند) و بعد با کار خودتون مقایسه کنید که چه چیزهایی را کم و زیاد دارد.
اگر code-first عمل میکنید و دیتابیس قرار است از روی کدهای فوق تهیه شود، تمام نگاشتها را حذف کنید (کلاسهای Map تعریف شده را)، EF به راحتی روابط man-to-many را تشخیص داده و کلیدهای خارجی و جدول واسط را تهیه میکند. نامهای پیش فرض آن هم از نظر من بسیار مناسب است و نیازی به تغییر ندارند. (تنها تغییری که با بودن کلاسهای Map فوق حاصل میشه، تعیین نام فیلدهای جدول واسط است و زمانیکه code-first کار میکنید این نامها مهم نیستند؛ چون با LINQ نهایتا قرار است کار کنید و خواص کلاسها)
«من از کنترلهای تلریک استفاده میکنم که یک سری اسکریپت را بصورت
http://localhost:1244/WebResource.axd?d=aklE6L8AEfPEgIS3T-oXc6mevPfbpi6VRp_ZTP2nBVrnt5ULOFYD3GNWRrDHwANC3VDQlL8dLAa5g35dzgHyuzAgAguIpYrf-_NXIJwNNu0YRSnH3-MgKMfnwKBKF_Lk2E5oeIcLL78uDlQ0se_GxQ2&t=635231470568640000
به فرم تزریق میکند و بعضی وقتها داخلش xp و یا یک سری دستورات اسکیوال تولید میشوند. در این حالت این مسیرها توسط ISA Server در شبکه داخلی حمله تشخیص داده شده و بلاک خواهند شد و عملا برنامه از کار میافتد. آیا راهی برای خلاصی از دست آنها هست؟»
پاسخ: بلی. از دات نت 3 و نیم به بعد، امکان جایگزینی کامل اسکریپتهای خودکار مدفون شده در اسمبلیها با فایلهای استاتیک پیش بینی شدهاست که در ادامه نحوهی استخراج و کار با آنها را بررسی خواهیم کرد.
الف) یافتن اسکریپتهای مدفون در اسمبلیها
در ابتدا اسمبلی حاوی کنترلهای وب فرم مدنظر خود را باید توسط برنامههای Reflector یا ILSpy و امثال آنها گشوده و نام دقیق منبع و همچنین محتوای آن فایل اسکریپت را استخراج کنید. برای مثال:
در این تصویر، اسمبلی استاندارد System.Web.Extensions مورد بررسی قرار گرفته است. برای نمونه اگر بخواهید اسکریپتهای متناظر با ScriptManager و UpdatePanel را با معادلهای استاتیک آنها جایگزین کنید، باید دو فایل MicrosoftAjaxWebForms.js و MicrosoftAjax.js را از این اسمبلی استخراج نمائید. (برنامههای یاد شده امکان ذخیره سازی منابع را نیز میدهند)
ب) وادار کردن ASP.NET به استفاده از نسخهی استاتیک منابع
<asp:ScriptManager ID="Scriptmanager1" runat="server"> <Scripts> <asp:ScriptReference Name="MicrosoftAjaxWebForms.js" Assembly="System.Web.Extensions" Path="~/staticJS1.js" /> <asp:ScriptReference Name="MicrosoftAjax.js" Assembly="System.Web.Extensions" Path="~/staticJS2.js" /> </Scripts> </asp:ScriptManager>
The assembly 'System.Web.Extensions' does not contain a Web resource that has the name 'xyz.js'. Make sure that the resource name is spelled correctly. Make sure that the application references the correct version of an ASP.NET AJAX Framework assembly.
<script src="staticJS1.js" type="text/javascript"></script> <script src="staticJS2.js" type="text/javascript"></script>
یک نکتهی تکمیلی
در مطلب «ASP.NET 4.5 ScriptManager Improvements in WebForms » مشاهده خواهید کرد که از ASP.NET 4.5 به بعد، طی دو بستهی نیوگت که هر از چندگاهی به روز میشوند، کلیه اسکریپتهای System.Web و System.Web.Extensions خارج از این اسمبلیها نیز قابل دریافت بوده و با استفاده از سیستم bunding & minification میتوان آنها را فشرده و یکی کرد.
مدل EAV چیست؟
این روحیه شما جستجوگری را از بین میبرد. تفکر در مورد راههای مختلف را منع میکند. اقناع به روشهای عهد عتیق طراحی را که الزاما بهینه نیستند، ترویج میکند. جستجوی در مورد راههای NoSQL الزاما به معنای استفاده از آنها نیست ولی حداقل دید شخص را نسبت به الگوریتمها و طرز تفکرهای مختلف موجود جهت حل مسایل باز میکند. خیلیها مثلا جبهه میگیرند در مورد ORMها. به این افراد باید گفت، اشکالی نداره. استفاده نکنید. حداقل طراحی اونها رو مطالعه کنید که توسط بزرگان دنیا انجام شده و ازش درس یاد بگیرید تا کدهای SQL Helper مشکل داری رو طراحی نکنید. برید SQL بنویسید بجای LINQ. اما حداقل یادبگیرید اونی که اومده لایه DAL جنریک درست کرده، طراحیاش چطوری بوده. دو تا نکته ازش یاد بگیرید. نمیخواین با MVC کار کنید، مهم نیست. حداقل طراحیاش رو بررسی کنید که چطور تونسته ViewState رو حذف کنه اما باز هم بعد از post back به سرور میتونه مقادیر وارد شده در فرمها رو در صورت نیاز حفظ کنه.
مورد دوم اینکه اون تعداد کشتهها ربط مستقیم داره به میزان بیسوادی در کشور. مطابق نظر معاون وزیر آموزش و پرورش در سال قبل «در کشور نزدیک به 9 میلیون و 700 هزار نفر خواندن و نوشتن بلد نیستند و بیش از 10 میلیون نفر نیز تحصیلات حداکثر پنجم ابتدایی دارند.» خوب اینها مسلما مشکلزا هستند. همه چیز تقصیر ماشین و جاده نیست. اینها هم کسانی هستند که قانع هستند به آنچه که دارند و نیازی برای پیشرفت حس نمیکنند.
refusing to allow an OAuth App to create or update workflow `.github/workflows/dotnetcore.yml` without `workflow` scope
namespace EntitySample1.DomainClasses { public class Person { public int Id { get; set; } public string FirstName { get; set; } public string LastName { get; set; } public DateTime BirthDate { get; set; } public virtual PersonInfo PersonInfo { get; set; } public virtual ICollection<PhoneNumber> PhoneNumbers { get; set; } public virtual ICollection<Address> Addresses { get; set; } } }
namespace EntitySample1.DomainClasses { public class PersonInfo { public int Id { get; set; } public string Note { get; set; } public string Major { get; set; } } }
namespace EntitySample1.DomainClasses { public enum PhoneType { Home, Mobile, Work } public class PhoneNumber { public int Id { get; set; } public string Number { get; set; } public PhoneType PhoneType { get; set; } public virtual Person Person { get; set; } } }
namespace EntitySample1.DomainClasses { public class Address { public int Id { get; set; } public string City { get; set; } public string Street { get; set; } public virtual ICollection<Person> Persons { get; set; } } }
namespace EntitySample1.DataLayer { public class PhoneBookDbContext : DbContext { public DbSet<Person> Persons { get; set; } public DbSet<PhoneNumber> PhoneNumbers { get; set; } public DbSet<Address> Addresses { get; set; } } }
استفاده از ردیابی تغییر عکس فوری
ردیابی تغییر عکس فوری، وابسته به این است که EF بفهمد، چه زمانی تغییرات رخ داده است. رفتار پیش فرض DbContext API ، این هست که به صورت خودکار بازرسی لازم را در نتیجهی رخدادهای DbContext انجام دهد. DetectChanges تنها اطلاعات مدیریت حالت context، که وظیفهی انعکاس تغییرات صورت گرفته به پایگاه داده را دارد، به روز نمیکند، بلکه اصلاح رابطه(ralationship) ترکیبی از خواص راهبری مرجع ، مجموعه ای و کلیدهای خارجی را انجام میدهد. این خیلی مهم خواهد بود که درک روشنی داشته باشیم از این که چگونه و چه زمانی تغییرات تشخیص داده میشوند،چه چیزی باید از آن انتظار داشته باشیم و چگونه کنترلش کنیم.
چه زمانی تشخیص خودکار تغییرات اجرا میشود؟
متد DetectChanges کلاس ObjectContext، از EF نسخهی 4 به عنوان بخشی از الگوی ردیابی تغییر عکس فوری اشیای POCO ،در دسترس بوده است. تفاوتی که در مورد DataContext.ChangeTracker.DetectChanges( در حقیقت ObjectContext.DetectChanges فراخوانی میشود) وجود دارد این است که، رویدادهای خیلی بیشتری وجود دارند که به صورت خودکار DetectChanges را فراخوانی میکنند.
لیستی از متدهایی که باعث انجام عمل تشخیص تغییرات (DetectChanges)، میشوند را در ادامه مشاهده میکنید:
• DbSet.Add
• DbSet.Find
• DbSet.Remove
• DbSet.Local
• DbSet.SaveChanges
• فراخوانی Linq Query از DbSet
• DbSet.Attach
• DbContext.GetValidationErrors
• DbContext.Entry
• DbChangeTracker.Entries
کنترل زمان فراخوانی DetectChanges
بیشترین زمانی که EF احتیاج به فهمیدن تغییرات دارد، در زمان SaveChanges است، اما حالتهای زیاد دیگری نیز هست. برای مثال، اگر ما از ردیاب تغییرات، درخواست وضعیت فعلی یک شی را بکنیم،EF احتیاج به اسکن کردن و بررسی تغییرات رخ داده را دارد. همچنین وضعیتی را در نظر بگیرید که شما از پایگاه داده یک شماره تلفن را واکشی میکنید و سپس آن را به مجموعه شماره تلفنهای یک شخص جدید اضافه میکنید.آن شماره تلفن اکنون تغییر کرده است، چرا که انتساب آن به یک شخص جدید،خاصیت PersonId آن را تغییر داده است. ولی EF برای اینکه بفهمد تغییر رخ داده است(یا حتی نداده است) ، احتیاج به اسکن کردن همهی اشیا Person دارد.
بیشتر عملیاتی که بر روی DbContext API انجام میدهید، موجب فراخوانی DetectChanges میشود. در بیشتر موارد DetectChanges به اندازه کافی سریع هست تا باعث ایجاد مشکل کارایی نشود. با این حال ممکن است ، شما تعداد خیلی زیادی اشیا در حافظه داشته باشید، و یا تعداد زیادی عملیات در DbContext ، در مدت خیلی کوتاهی انجام دهید، رفتار تشخیص خودکار تغییرات ممکن است، باعث نگرانیهای کارایی شود. خوشبختانه گزینه ای برای خاموش کردن رفتار تشخیص خودکار تغییرات وجود دارد و هر زمانی که میدانید لازم است، میتوانید آن را به صورت دستی فراخوانی کنید.
EF بر مبنای این فرض ساخته شده است که شما ، در صورتی که در فراخوانی آخرین API، موجودیتی تغییر پیدا کرده است، قبل از فراخوانی API جدید، باید DetectChanges صدا زده شود. این شامل فراخوانی DetectChanges، قبل از اجرای هر query نیز میشود.اگر این عمل ناموفق یا نابجا انجام شود،ممکن است عواقب غیر منتظره ای در بر داشته باشد. DbContext انجام این وظیفه را بر عهده گرفته است و به همین دلیل به طور پیش فرض تشخیص تغییرات خودکار آن فعال است.
نکته: تشخیص اینکه چه زمانی احتیاج به فراخوانی DetectChanges است،آن طور که ساده و بدیهی به نظر میآید نیست. تیم EF شدیدا توصیه کرده اند که فقط، وقتی با مشکلات عدم کارایی روبرو شدید، تشخیص تغییرات را به حالت دستی در بیاورید.همچنین توصیه شده که در چنین مواقعی، تشخیص خودکار تغییرات را فقط برای قسمتی از کد که با کارایی پایین مواجه شدید خاموش کنید و پس از اینکه اجرای آن قسمت از کد تمام شد،دوباره آن را روشن کنید.
برای خاموش یا روشن کردن تشخیص خودکار تغییرات، باید متغیر بولین DbContext.Configuration.AutoDetectChangesEnabled را تنظیم کنید.
در مثال زیر، ما در متد ManualDetectChanges، تشخیص خودکار تغییرات را خاموش کرده ایم و تاثیرات آن را بررسی کرده ایم.
private static void ManualDetectChanges() { using (var context = new PhoneBookDbContext()) { context.Configuration.AutoDetectChangesEnabled = false; // turn off Auto Detect Changes var p1 = context.Persons.Single(p => p.FirstName == "joe"); p1.LastName = "Brown"; Console.WriteLine("Before DetectChanges: {0}", context.Entry(p1).State); context.ChangeTracker.DetectChanges(); // call detect changes manually Console.WriteLine("After DetectChanges: {0}", context.Entry(p1).State); } }
در کدهای بالا ابتدا تشخیص خودکار تغییرات را خاموش کرده ایم و سپس یک شخص با نام joe را از دیتابیس فراخواندیم و سپس نام خانوادگی آن را به Brown تغییر دادیم. سپس در خط بعد، وضعیت فعلی موجودیت p1 را از context جاری پرسیدیم. در خط بعدی، DetectChanges را به صورت دستی صدا زده ایم و دوباره همان پروسه را برای به دست آوردن وضیعت شی p1، انجام داده ایم. همان طور که میبینید ، برای به دست آوردن وضعیت فعلی شی مورد نظر از متد Entry متعلق به ChangeTracker API استفاده میکنیم، که در آینده مفصل در مورد آن بحث خواهد شد. اگر شما متد Main را با صدا زدن ManualDetectChanges ویرایش کنید ، خروجی زیر را مشاهده خواهید کرد:
Before DetectChanges: Unchanged After DetectChanges: Modified
همان طور که انتظار میرفت، به دلیل خاموش کردن تشخیص خودکار تغییرات، context قادر به تشخیص تغییرات صورت گرفته در شی p1 نیست، تا زمانی که متد DetectChanges را به صورت دستی صدا بزنیم. دلیل این که در دفعه اول، ما نتیجهی غلطی مشاهده میکنیم، این است که ما قانون را نقض کرده ایم و قبل از صدا زدن هر API ، متد DetectChanges را صدا نزده ایم. خوشبختانه چون ما در اینجا وضعیت یک شی را بررسی کردیم، با عوارض جانبی آن روبرو نشدیم.
نکته: به این نکته توجه داشته باشید که متد Entry به صورت خودکار، DetectChanges را فراخوانی میکند. برای اینکه دانسته بخواهیم این رفتار را غیر فعال کنیم، باید AutoDetectChangesEnabled را غیر فعال کنیم.
در مثال فوق ،خاموش کردن تشخیص خودکار تغییرات، برای ما مزیتی به همراه نداشت و حتی ممکن بود برای ما دردسر ساز شود. ولی حالتی را در نظر بگیرید که ما یک سری API را فراخوانی میکنیم ،بدون این که در این بین ،در حالت اشیا تغییری ایجاد کنیم.در نتیجه میتوانیم از فراخوانیهای بی جهت DetectChanges جلوگیری کنیم.
در متد AddMultiplePersons مثال بعدی، این کار را نشان داده ام:
private static void AddMultiplePerson() { using (var context = new PhoneBookDbContext()) { context.Configuration.AutoDetectChangesEnabled = false; context.Persons.Add(new Person { FirstName = "brad", LastName = "watson", BirthDate = new DateTime(1990, 6, 8) }); context.Persons.Add(new Person { FirstName = "david", LastName = "brown", BirthDate = new DateTime(1990, 6, 8) }); context.Persons.Add(new Person { FirstName = "will", LastName = "smith", BirthDate = new DateTime(1990, 6, 8) }); context.SaveChanges(); } }
استفاده از DetectChanges برای فراخوانی اصلاح رابطه
DetectChanges همچنین مسئولیت انجام اصلاح رابطه ، برای هر رابطه ای که تشخیص دهد تغییر کرده است را دارد.اگر شما بعضی از روابط را تغییر دادید و مایل بودید تا همهی خواص راهبری و خواص کلید خارجی را منطبق کنید، DetectChanges این کار را برای شما انجام میدهد. این قابلیت میتواند برای سناریوهای data-binding که در آن ممکن است در رابط کاربری(UI) یکی از خواص راهبری (یا حتی یک کلید خارجی) تغییر کند، و شما بخواهید که خواص دیگری این رابطه به روز شوند و تغییرات را نشان دهند، مفید واقع شود.
متد DetectRelationshipChanges در مثال زیر از DetectChanges برای انجام اصلاح رابطه استفاده میکند.
private static void DetectRelationshipChanges() { using (var context = new PhoneBookDbContext()) { var phone1 = context.PhoneNumbers.Single(x => x.Number == "09351234567"); var person1 = context.Persons.Single(x => x.FirstName == "will"); person1.PhoneNumbers.Add(phone1); Console.WriteLine("Before DetectChanges: {0}", phone1.Person.FirstName); context.ChangeTracker.DetectChanges(); // ralationships fix-up Console.WriteLine("After DetectChanges: {0}", phone1.Person.FirstName); } }
در اینجا ابتدا ما شماره تلفنی را از دیتابیس لود میکنیم. سپس شخص دیگری را نیز با نام will از دیتابیس میخوانیم. قصد داریم شماره تلفن خوانده شده را به این شخص نسبت دهیم و مجموعه شماره تلفنهای وی اضافه کنیم و ما این کار را با افزودن phone1 به مجموعه شماره تلفنهای person1 انجام داده ایم. چون ما از اشیای POCO استفاده کرده ایم،EF نمیفهمد که ما این تغییر را ایجاد کرده ایم و در نتیجه کلید خارجی PersonId شی phone1 را اصلاح نمیکند. ما میتوانیم تا زمانی صبر کنیم تا متدی مثل SaveChanges، متد DetectChanges را فراخوانی کند،ولی اگر بخواهیم این عمل در همان لحظه انجام شود، میتوانیم DetectChanges را دستی صدا بزنیم.
اگر ما متد Main را با اضافه کردن فرخوانی DetectRealtionShipsChanges تغییر بدهیم و آن را اجرا کنیم، نتیجه زیر را مشاهده میکنید:
Before DetectChanges: david After DetectChanges: will
تا قبل از فراخوانی تشخیص تغییرات(DetectChanegs)، هنوز phone1 منتسب به شخص قدیمی(david) بوده، ولی پس از فراخوانی DetectChanges ، اصلاح رابطه رخ داده و همه چیز با یکدیگر منطبق میشوند.
فعال سازی و کار با پروکسیهای ردیابی تغییر
اگر پروفایلر کارایی شما، فراخوانیهای بیش از اندازه DetectChnages را به عنوان یک مشکل شناسایی کند، و یا شما ترجیح میدهید که اصلاح رابطه به صورت بلادرنگ صورت گیرد ، ردیابی تغییر پروکسیهای پویا، به عنوان گزینه ای دیگر مطرح میشود.فقط با چند تغییر کوچک در کلاسهای POCO، EF قادر به ساخت پروکسیهای پویا خواهد بود.پروکسیهای ردیابی تغییر به EF اجازه ردیابی تغییرات در همان لحظه ای که ما تغییری در اشیای خود میدهیم را میدهند و همچنین امکان انجام اصلاح رابطه را در هر زمانی که تغییرات روابط را تشخیص دهد، دارد.
برای اینکه پروکسی ردیابی تغییر بتواند ساخته شود، باید قوانین زیر رعایت شود:
• کلاس باید public باشد و seald نباشد.
• همهی خواص(properties) باید virtual تعریف شوند.
• همهی خواص باید getter و setter با سطح دسترسی public داشته باشند.
• همهی خواص راهبری مجموعه ای باید نوعشان، از نوع ICollection<T> تعریف شوند.
کلاس Person مثال خود را به گونه ای بازنویسی کرده ایم که تمام قوانین فوق را پیاده سازی کرده باشد.
نکته: توجه داشته باشید که ما دیگر در داخل سازنده کلاس ،کدی نمینویسیم و منطقی که باعث نمونه سازی اولیه خواص راهبری میشدند، را پیاده سازی نمیکنیم. این پروکسی ردیاب تغییر، همهی خواص راهبری مجموعه ای را تحریف کرده و ار نوع مجموعه ای مخصوص خود(EntityCollection<T>) استفاده میکند. این نوع مجموعه ای، هر تغییری که در این مجموعه صورت میگیرد را زیر نظر گرفته و به ردیاب تغییر گزارش میدهد. اگر تلاش کنید تا نوع دیگری مانند List<T> که معمولا در سازنده کلاس از آن استفاده میکردیم را به آن انتساب دهیم، پروکسی، استثنایی را پرتاب میکند.
namespace EntitySample1.DomainClasses { public class Person { public virtual int Id { get; set; } public virtual string FirstName { get; set; } public virtual string LastName { get; set; } public virtual DateTime BirthDate { get; set; } public virtual PersonInfo PersonInfo { get; set; } public virtual ICollection<PhoneNumber> PhoneNumbers { get; set; } public virtual ICollection<Address> Addresses { get; set; } } }
با این که احتیاجات رسیدن به پروکسیهای ردیابی تغییر خیلی ساده هستند، اما سادهتر از آن ها، فراموش کردن یکی از آن هاست.حتی از این هم سادهتر میشود که در آینده تغییری در آن کلاسها ایجاد کنید و ناخواسته یکی از آن قوانین را نقض کنید.به این خاطر، فکر خوبیست که یک آزمون واحد نیز اضافه کنیم تا مطمئن شویم که EF توانسته، پروکسی ردیابی تغییر را ایجاد کند یا نه.
در مثال زیر یک متد نوشته شده که این مورد را مورد آزمایش قرار میدهد. همچنین فراموش نکنید که فضای نام System.Data.Object.DataClasses را به usingهای خود اضافه کنید.
private static void TestForChangeTrackingProxy() { using (var context = new PhoneBookDbContext()) { var person = context.Persons.First(); var isProxy = person is IEntityWithChangeTracker; Console.WriteLine("person is a proxy: {0}", isProxy); } }
اکنون متد ManualDetectChanges را که کمی بالاتر بررسی کرده ایم را در نظر بگیرید و کد context.ChangeTracker.DetectChanges آن را حذف کنید و بار دیگر آن را فرا بخوانید و نتیجه را مشاهده کنید:
Before DetectChanges: Modified After DetectChanges: Modified
اکنون متد DetectRelationshipChanges را ویرایش کرده و برنامه را اجرا کنید:
Before DetectChanges: will After DetectChanges: will
نکته: زمانی که شما از پروکسیهای ردیابی تغییر استفاده میکنید،احتیاجی به غیرفعال کردن تشخیص خودکار تغییرات نیست. DetectChanges برای همه اشیایی که تغییرات را به صورت بلادرنگ گزارش میدهند،فرآیند تشخیص تغییرات را انجام نمیدهد. بنابراین فعال سازی پروکسیهای ردیابی تغییر،برای رسیدن به مزایای کارایی بالا در هنگام عدم استفاده از DetectChanges کافی است. در حقیقت زمانی که EF، یک پروکسی ردیابی پیدا میکند، از مقادیر خاصیت ها، عکس فوری نمیگیرد. همچنین DetectChanges این را نیز میداند که نباید تغییرات موجودیت هایی که عکسی از مقادیر اصلی آنها ندارد را اسکن کند.
تذکر: اگر شما موجودیت هایی داشته باشید که شامل انواع پیچیده(Complex Types) میشوند،EF هنوز هم از ردیابی تغییر عکس فوری، برای خواص موجود در نوع پیچیده استفاده میکند، و از این جهت لازم است کهEF، برای نمونهی نوع پیچیده، پروکسی ایجاد نمیکند.شما هنوز هم، تشخیص خودکار تغییرات خواصی که مستقیما درون آن موجودیت(Entity) تعریف شده اند را دارید، ولی تغییرات رخ داده درون نوع پیچیده، فقط از طریق DetectChanges قابل تشخیص است.
چگونگی اطمینان از اینکه نمونههای جدید ، پروکسیها را دریافت خواهند کرد
EF به صورت خودکار برای نتایج حاصل از کوئری هایی که شما اجرا میکنید، پروکسیها را ایجاد میکند. با این حال اگر شما فقط از سازندهی کلاس POCO خود برای ایجاد نمونهی جدید استفاده کنید،دیگر پروکسیها ایجاد نخواهند شد.بدین منظور برای دریافت پروکسی ها، شما باید از متد DbSet.Create برای دریافت نمونههای جدید آن موجودیت استفاده کنید.
نکته: اگر شما، پروکسیهای ردیابی تغییر را برای موجودیتی از مدلتان فعال کرده باشید،هنوز هم میتوانید،نمونههای فاقد پروکسی آن موجودیت را ایجاد و بیافزایید.خوشبختانه EF با موجودیتهای پروکسی و غیر پروکسی در همان مجموعه(set) کار میکند.شما باید آگاه باشید که ردیابی خودکار تغییرات و یا اصلاح رابطه، برای نمونه هایی که پروکسی هایی ردیابی تغییر نیستند، قابل استفاده نیستند.داشتن مخلوطی از نمونههای پروکسی و غیر پروکسی در همان مجموعه، میتواند گیج کننده باشد.بنابر این عموما توصیه میشود که برای ایجاد نمونههای جدید از DbSet.Create استفاده کنید، تا همهی موجودیتهای موجود در مجموعه، پروکسیهای ردیابی تغییر باشند.
متد CreateNewProxies را به برنامهی خود اضافه کرده و آن را اجرا کنید.
private static void CreateNewProxies() { using (var context = new PhoneBookDbContext()) { var phoneNumber = new PhoneNumber { Number = "987" }; var davidPersonProxy = context.Persons.Create(); davidPersonProxy.FirstName = "david"; davidPersonProxy.PhoneNumbers.Add(phoneNumber); Console.WriteLine(phoneNumber.Person.FirstName); } }
خروجی مثال فوق david خواهد بود.همان طور که میبینید با استفاده از context.Persons.Create، نمونهی ساخته شده، دیگر شی POCO نیست، بلکه davidPersonProxy، از جنس پروکسی ردیابی تغییر است و تغییرات آن به طور خودکار ردیابی شده و رابطه آن نیز به صورت خودکار اصلاح میشود.در اینجا نیز با افزودن phoneNumber به شماره تلفنهای davidPersonProxy، به طور خودکار رابطهی بین phoneNumber و davidPersonPeroxy بر قرار شده است. همان طور که میدانید این عملیات بدون استفاده از پروکسیهای ردیابی تغییرات امکان پذیر نیست و موجب بروز خطا میشود.
ایجاد نمونههای پروکسی برای انواع مشتق شده
اورلود جنریک دیگری برای DbSet.Create وجود دارد که برای نمونه سازی کلاسهای مشتق شده در مجموعه ما استفاده میشود .برای مثال، فراخوانی Create بر روی مجموعهی Persons ،نمونه ای از کلاس Person را بر میگرداند.ولی ممکن است کلاس هایی در مجموعهی Persons وجود داشته باشند، که از آن مشتق شده باشند، مانند Student. برای دریافت نمونهی پروکسی Student، از اورلود جنریک Create استفاده میکنیم.
var newStudent = context.Persons.Create<Student>();
تا به این جای کار باید متوجه شده باشید که ردیابی تغییرات، فرآیندی ساده و بدیهی نیست و مقداری سربار در کار است. در بعضی از بخشهای برنامه تان، احتمالا دادهها را به صورت فقط خواندنی در اختیار کاربران قرار میدهید و چون اطلاعات هیچ وقت تغییر نمیکنند، شما میخواهید که سربار ناشی از ردیابی تغییرات را حذف کنید.
خوشبختانه EF شامل متد AsNoTracking است که میتوان از آن برای اجرای کوئریهای بدون ردیابی استفاده کرد.یک کوئری بدون ردیابی، یک کوئری ساده هست که نتایج آن توسط context برای تشخیص تغییرات ردیابی نخواهد شد.
متد PrintPersonsWithoutChangeTracking را به برنامه اضافه کنید و آن را اجرا کنید:
private static void PrintPersonsWithoutChangeTracking() { using (var context = new PhoneBookDbContext()) { var persons = context.Persons.AsNoTracking().ToList(); foreach (var person in persons) { Console.WriteLine(person.FirstName); } } }
نکته: واکشی دادهها بدون ردیابی تغییرات،معمولا وقتی باعث افزایش قابل توجه کارایی میشود که بخواهیم تعداد خیلی زیادی داده را به صورت فقط خواندنی نمایش دهیم. اگر برنامهی شما داده ای را تغییر میدهد و میخواهد آن را ذخیره کند، باید از AsNoTracking استفاده نکنید.
AsNoTracking یک متد الحاقی است، که در <IQueryable<T تعریف شده است، در نتیجه شما میتوانید از آن، در کوئریهای LINQ نیز استفاده کنید. شما میتوانید از AsNoTracking، در انتهای DbSet ،در خط from کوئری استفاده کنید.
var query = from p in context.Persons.AsNoTracking() where p.FirstName == "joe" select p;
شما همچنین از AsNoTracking میتوانید برای تبدیل یک کوئری LINQ موجود، به یک کوئری فاقد ردیابی استفاده کنید. این نکته را به یاد داشته باشید که فقط AsNoTracking بر روی کوئری، فرانخوانده شده است، بلکه متغیر query را با نتیجهی حاصل از فراخوانی AsNoTracking بازنویسی(override) کرده است و این، از این جهت لازم است که AsNoTracking ،تغییری در کوئری ای که بر روی آن فراخوانده شده نمیدهد، بلکه یک کوئری جدید بر میگرداند.
var query = from p in context.Persons where p.FirstName == "joe" select p; query = query.AsNoTracking();
منبع: ترجمه ای آزاد از کتاب Programming Entity Framework: DbContext
حذف اعراب از حروف و کلمات
return stringBuilder.ToString();
سشن چیست؟
شیء سشن، مجموعهای از اشیاء serialized مرتبط با جلسهی کاری جاری یک کاربر است. این اشیاء عموما در حافظهی محلی سرور ذخیره میشوند؛ اما امکان ذخیره سازی توزیع شدهی آنها در بانکهای اطلاعاتی نیز پیش بینی شدهاست.
عموما استفادهی از اشیاء سشن توصیه نمیشوند. از این جهت که این نوع اشیاء بسیار شبیه هستند به متغیرهای سراسری و وجود این نوع متغیرها اساسا ضعف طراحی شیءگرا به حساب میآیند. اما با توجه به ماهیت stateless بودن برنامههای وب، به این معنا که با پایان رندر یک صفحه، تمام اشیاء مرتبط با آنها نیز در سمت سرور تخریب میشوند، نیاز است برای یک سری از دادههای عمومی کاربر، راه حلی را پیدا کرد تا بتوان از اطلاعات آنها استفادهی مجدد کرد. برای مثال نگهداری رشتهی اتصالی بانک اطلاعاتی که کاربر در حین لاگین به سیستم آنرا انتخاب کردهاست (اگر برنامه به ازای هر سال از یک بانک اطلاعاتی مجزا استفاده میکند) و یا زمانیکه کاربری captcha را پر میکند و مقدار آنرا به سمت سرور ارسال میکند، نیاز است مقدار ارسالی او را با مقدار ابتدایی captcha مقایسه کرد. یک چنین اطلاعاتی نباید با پایان رندر صفحه تخریب شوند و نیاز است تا زمانیکه جلسهی کاری کاربر به پایان نرسیدهاست، در دسترس باشند. به همین جهت است که مفهومی را به نام «اشیاء سشن» طراحی کردهاند.
درکل خارج از این موارد بهتر است از سشن استفاده نکنید و در جای جای برنامهی خود ردپای آنرا باقی نگذارید و به خاطر داشته باشید:
متغیر سشن = متغیر سراسری = ضعف طراحی شیءگرا
توصیهی به استفادهی از روشهای سبک وزنتر
سشنها تنها روش به اشتراک گذاری اطلاعات نیستند. اگر میخواهید اطلاعاتی را در بین میان افزارهای برنامه در طی یک درخواست به اشتراک بگذارید، شاید سشن هم یک راه حل باشد؛ اما راه حلی سنگین وزن. راه حل بهتر برای این موارد، استفادهی از HttpContext.Items است. HttpContext.Items نیز همانند سشن، یک key/value store است؛ اما طول عمر آن محدود است به طول عمر درخواست جاری و در تمام میان افزارهای برنامه در دسترس است.
برای مثال در یک میان افزار آنرا تنظیم میکنید:
app.Use(async (context, next) => { context.Items["isVerified"] = true; await next.Invoke(); });
app.Run(async (context) => { await context.Response.WriteAsync("Verified request? " + context.Items["isVerified"]); });
فعال سازی سشنها در ASP.NET Core
ASP.NET Core یک choose-what-you-need framework است. به این معنا که تا زمانیکه قابلیتی را به صورت صریح فعال سازی نکرده باشید، در دسترس نخواهد بود. همین مساله در نهایت به کاهش مصرف منابع این نوع برنامهها و همچنین طراحی ماژولار سیستم ختم میشوند. برای مثال در نگارشهای قبلی ASP.NET (تمام نگارشها)، سشنها به صورت پیش فرض فعال هستند، مگر آنکه HTTP Module آنرا در فایل web.config حذف کنید؛ اما در اینجا برعکس است.
اگر تنها در موارد خاصی که ذکر شد، نیاز به استفادهی از متغیرهای سشن را داشتید، روش فعال سازی آن به صورت ذیل است:
الف) نصب بستهی نیوگت Microsoft.AspNetCore.Session
برای این منظور وابستگی ذیل را به فایل project.json اضافه کنید:
{ "dependencies": { //same as before "Microsoft.AspNetCore.Session": "1.0.0" } }
برای این کار به کلاس آغازین برنامه مراجعه کرده و ابتدا سرویس سشنها را فعال کنید:
public void ConfigureServices(IServiceCollection services) { services.AddSession();
public void Configure(IApplicationBuilder app) { app.UseSession();
app.UseSession(options: new SessionOptions { IdleTimeout = TimeSpan.FromMinutes(30), CookieName = ".MyApplication" });
روش استفادهی از سشنها
در مثال ذیل نحوهی ذخیره سازی اطلاعات را در شیء سشن جلسهی جاری یک کاربر، ملاحظه میکنید:
public ActionResult TestSession() { this.HttpContext.Session.Set("key-1", BitConverter.GetBytes(DateTime.Now.Ticks)); this.HttpContext.Session.SetInt32("key-2", 1); this.HttpContext.Session.SetString("key-3", "DNT"); return Content("OK!"); }
public IActionResult Index() { byte[] key1 = this.HttpContext.Session.Get("key-1"); long key1Value = BitConverter.ToInt64(key1, 0); int? key2Value = this.HttpContext.Session.GetInt32("key-2"); string key3Value = this.HttpContext.Session.GetString("key-3"); return Content("OK!"); }
حالت Set آن آرایهای از بایتها را دریافت میکند و میتوان برای حالت serialization اشیاء، مفید باشد.
دقیقا معادل همین سه متد، متدهای Get، GetInt32 و GetString برای بازیابی مقادیر سشن طراحی شدهاند و باید دقت داشت که خروجیهای اینها میتوانند نال نیز باشند. به همین جهت خروجی GetInt32 آن نال پذیر است.
توسعهی متدهای پیش فرض کار با سشنها
سه متد یاد شدهی کار با سشنها در ASP.NET Core هرچند ضروری هستند، اما کافی نیستند. برای توسعهی آنها میتوان متدهای الحاقی را تدارک دید که نمونهای از آنها را ذیل مشاهده میکنید:
using System; using Microsoft.AspNetCore.Http; using Newtonsoft.Json; namespace Core1RtmEmptyTest.StartupCustomizations { public static class SessionExts { public static void SetDateTime(this ISession collection, string key, DateTime value) { collection.Set(key, BitConverter.GetBytes(value.Ticks)); } public static DateTime? GetDateTime(this ISession collection, string key) { var data = collection.Get(key); if (data == null) { return null; } var dateInt = BitConverter.ToInt64(data, 0); return new DateTime(dateInt); } public static void SetObject(this ISession session, string key, object value) { var stringValue = JsonConvert.SerializeObject(value); session.SetString(key, stringValue); } public static T GetObject<T>(this ISession session, string key) { var stringValue = session.GetString(key); return JsonConvert.DeserializeObject<T>(stringValue); } } }
و یا جهت کار با اشیاء پیچیدهتر میتوان از کتابخانهی JSON.NET استفاده کرد. به عبارتی در این نگارش از ASP.NET، کار سریالایز و دیسریالایز اشیاء، به برنامه نویس واگذار شدهاست و اینکه در پشت صحنه از چه کتابخانهای میخواهید استفاده کنید، در اختیار خودتان است.
البته باید دقت داشت که در اینجا وابستگی JSON.NET به صورت خودکار در دسترس است. از این جهت که بسیاری از وابستگیهای ASP.NET Core مانند مورد ذیل، به JSON.NET وابستهاند و نصب آنها به معنای نصب خودکار JSON.NET نیز هست:
{ "dependencies": { //same as before "Microsoft.Extensions.Configuration.Json": "1.0.0" } }
یک مطلب تکمیلی
در اینجا نیز امکان ذخیره سازی سشنها در بانک اطلاعاتی بجای حافظهی فرار سرور درنظر گرفته شدهاست و برای این حالت، بانکهای اطلاعاتی NoSQL ویژهای به نام key/value stores مانند بانک اطلاعاتی فوق سریع Redis پیشنهاد میشود؛ هرچند امکان کار با SQL Server نیز در اینجا وجود دارد، اما برای کش سرورهای مبتنی بر key/value ها، بانک اطلاعاتی Redis، انتخاب اول است.
Managing Application State