توی دریافت اطلاعات لیست دوستان از فیسبوک باید دقت داشت که طبق مستندات فیسبوک برای Graph API در اینجا ما فقط به اطلاعات دوستانی دسترسی خواهیم داشت که از Facebook Login استفاده کرده باشند.
البته این نکته رو هم باید اضافه کنم که برای دسترسی به هر اطلاعاتی از اکانت فیسبوک کاربر، باید مجوزش رو هم ارسال کنیم بنابراین برای دریافت اطلاعات مربوط به لیست دوستان باید دستور زیر رو هم به کلاس startUp اضافه کنیم
x.Scope.Add("user_friends");
اکثر متدهای این کلاس thread-safe طراحی شدهاند؛ اما با یک استثناء: متد GetOrAdd آن thread-safe نیست:
TValue GetOrAdd(TKey key, Func<TKey, TValue> valueFactory);
بررسی نحوهی کار با متد GetOrAdd
این متد یک کلید را دریافت کرده و سپس بررسی میکند که آیا این کلید در مجموعهی جاری وجود دارد یا خیر؟ اگر کلید وجود داشته باشد، مقدار متناظر با آن بازگشت داده میشود و اگر خیر، delegate ایی که به عنوان پارامتر دوم آن معرفی شدهاست، اجرا خواهد شد، سپس مقدار بازگشت داده شدهی توسط آن به مجموعه اضافه شده و در آخر این مقدار به فراخوان بازگشت داده میشود.
var dictionary = new ConcurrentDictionary<string, string>(); var value = dictionary.GetOrAdd("key1", x => "item 1"); Console.WriteLine(value); value = dictionary.GetOrAdd("key1", x => "item 2"); Console.WriteLine(value);
item 1 item 1
دسترسی همزمان به متد GetOrAdd امن نیست
ConcurrentDictionary برای اغلب متدهای آن به صورت توکار مباحث قفلگذاری چند ریسمانی را اعمال میکند؛ اما نه برای متد GetOrAdd. زمانیکه valueFactory آن در حال اجرا است، دسترسی همزمان به آن thread-safe نیست و ممکن است بیش از یکبار فراخوانی شود.
یک مثال:
using System; using System.Collections.Concurrent; using System.Threading.Tasks; namespace Sample { class Program { static void Main(string[] args) { var dictionary = new ConcurrentDictionary<int, int>(); var options = new ParallelOptions { MaxDegreeOfParallelism = 100 }; var addStack = new ConcurrentStack<int>(); Parallel.For(1, 1000, options, i => { var key = i % 10; dictionary.GetOrAdd(key, k => { addStack.Push(k); return i; }); }); Console.WriteLine($"dictionary.Count: {dictionary.Count}"); Console.WriteLine($"addStack.Count: {addStack.Count}"); } } }
dictionary.Count: 10 addStack.Count: 13
علت اینجا است که در این بین، متد GetOrAdd توسط ترد A فراخوانی میشود، اما key را در دیکشنری جاری پیدا نمیکند. به همین جهت شروع به اجرای valueFactory آن خواهد کرد. در همین زمان ترد B نیز به دنبال همین key است. ترد قبلی هنوز به پایان کار خودش نرسیدهاست که مجددا valueFactory متعلق به همین key اجرا خواهد شد. به همین جهت است که در ConcurrentStack اجرا شدهی در valueFactory، بیش از 10 آیتم موجود هستند.
الگویی برای مدیریت دسترسی همزمان امن به متد GetOrAdd
یک روش برای دسترسی همزمان امن به متد GetOrAdd، توسط تیم ASP.NET Core به صورت ذیل ارائه شدهاست:
// 'GetOrAdd' call on the dictionary is not thread safe and we might end up creating the pipeline more // once. To prevent this Lazy<> is used. In the worst case multiple Lazy<> objects are created for multiple // threads but only one of the objects succeeds in creating a pipeline. private readonly ConcurrentDictionary<Type, Lazy<RequestDelegate>> _pipelinesCache = new ConcurrentDictionary<Type, Lazy<RequestDelegate>>();
یک مثال:
namespace Sample { class Program { static void Main(string[] args) { var dictionary = new ConcurrentDictionary<int, Lazy<int>>(); var options = new ParallelOptions { MaxDegreeOfParallelism = 100 }; var addStack = new ConcurrentStack<int>(); Parallel.For(1, 1000, options, i => { var key = i % 10; dictionary.GetOrAdd(key, k => new Lazy<int>(() => { addStack.Push(k); return i; })); }); // Access the dictionary values to create lazy values. foreach (var pair in dictionary) Console.WriteLine(pair.Value.Value); Console.WriteLine($"dictionary.Count: {dictionary.Count}"); Console.WriteLine($"addStack.Count: {addStack.Count}"); } } }
10 1 2 3 4 5 6 7 8 9 dictionary.Count: 10 addStack.Count: 10
در این مثال دو تغییر صورت گرفتهاند:
الف) مقادیر ConcurrentDictionary به صورت Lazy معرفی شدهاند.
ب) متد GetOrAdd نیز یک مقدار Lazy را بازگشت میدهد.
زمانیکه از اشیاء Lazy استفاده میشود، خروجیهای بازگشتی از GetOrAdd، توسط این اشیاء Lazy محصور خواهند شد. اما نکتهی مهم اینجا است که هنوز value factory آنها فراخوانی نشدهاست. این فراخوانی تنها زمانی صورت میگیرد که به خاصیت Value یک شیء Lazy دسترسی پیدا کنیم و این دسترسی نیز به صورت thread-safe طراحی شدهاست. یعنی حتی اگر چند ترد new Lazy یک key مشخص را بازگشت دهند، تنها یکبار value factory متد GetOrAdd با دسترسی به خاصیت Value این اشیاء Lazy فراخوانی میشود و مابقی تردها منتظر مانده و تنها مقدار ذخیره شدهی در دیکشنری را دریافت میکنند و سبب اجرای مجدد value factory سنگین و زمانبر آن، نخواهند شد.
بر این مبنا میتوان یک LazyConcurrentDictionary را نیز به صورت ذیل طراحی کرد:
public class LazyConcurrentDictionary<TKey, TValue> { private readonly ConcurrentDictionary<TKey, Lazy<TValue>> _concurrentDictionary; public LazyConcurrentDictionary() { _concurrentDictionary = new ConcurrentDictionary<TKey, Lazy<TValue>>(); } public TValue GetOrAdd(TKey key, Func<TKey, TValue> valueFactory) { var lazyResult = _concurrentDictionary.GetOrAdd(key, k => new Lazy<TValue>(() => valueFactory(k), LazyThreadSafetyMode.ExecutionAndPublication)); return lazyResult.Value; } }
در مثال فوق، به صورت صریحی پارامتر LazyThreadSafetyMode نیز مقدار دهی شدهاست. هدف از آن اطمینان حاصل کردن از آغاز این شیء Lazy با دسترسی به خاصیت Value آن، تنها توسط یک ترد است.
نمونهی دیگر کار با خاصیت ویژهی Value شیء Lazy را در مطلب «پشتیبانی توکار از ایجاد کلاسهای Singleton از دات نت 4 به بعد» پیشتر در این سایت مطالعه کردهاید.
اجازه بدهید قبل از هر چیزی به دو مفهوم اصلی در IIS بپردزیم :
1. Worker Process
2. Application Pool
پروسههای کارگر w3wp.exe وظیفهی اجرای برنامههای asp.net را در IIS ، به عهده دارند. این پروسهها مسئولیت پردازش تمامی درخواست و پاسخها از/به کلاینت را دارند. هر کاری که باید در asp.net انجام بشود، توسط اینها صورت میگیرد. به بیان سادهتر این پروسهها قلب برنامههای ASP.Net بر روی IIS هستند .
Application Pool:این پولها در واقع ظرفی یا در برگیرنده ای برای پروسههای کارگر به حساب میآیند. این پولها پروسههای کارگر را از هم جدا و دسته بندی میکنند تا قابلیت اعتماد، امنیت و در دسترس بودن بدهند. موقعی که یک پروسه یا حتی یک پول دچار مشکل میشود، این اطمینان داده میشود که تاثیری بر دیگر پولها یا پروسههای کارگر، ندارد. یعنی موقعی که یک web application دچار مشکل شود، هیچ تاثیری بر اجرای web applicationهای دیگر ندارد. به یک application pool با چند پروسه کارگر web garden میگویند.
اصلا این WWW Service چه کاری انجام میدهد و به چه دردی میخورد؟
- HTTP administration and configuration
- Performance monitoring
- Process management
HTTP Administration and Configuration
در نسخههای جدیدتر IIS چکاری بر عهده WWW Service است؟
WAS در قسمت سوم این مقاله توضیح داده خواهد شد.
- کلمه عبور و سایر تنظیمات آن باید لحاظ شوند و گرنه موفق به ثبت اطلاعات نخواهید شد.
- نحوهی استخراج اطلاعات DbEntityValidationException
همیشه در حین توسعهی یک برنامه این سؤالات وجود دارند:
- چند درصد از برنامه تست شده است؟
- برای چه تعدادی از متدهای موجود آزمون واحد نوشتهایم؟
- آیا همین آزمونهای واحد نوشته شده و موجود، کامل هستند و تمام عملکردهای متدهای مرتبط را پوشش میدهند؟
این سؤالات به صورت خلاصه مفهوم Code coverage را در بحث Unit testing ارائه میدهند: برای چه قسمتهایی از برنامه آزمون واحد ننوشتهایم و میزان پوشش برنامه توسط آزمونهای واحد موجود تا چه حدی است؟
بررسی این سؤالات در یک پروژهی کم حجم، ساده بوده و به صورت بازبینی بصری ممکن است. اما در یک پروژهی بزرگ نیاز به ابزار دارد. به همین منظور تعدادی برنامه جهت بررسی code coverage مختص پروژههای دات نتی تابحال تولید شدهاند که در ادامه لیست آنها را مشاهده میکنید:
و ...
تمام اینها تجاری هستند. اما در این بین برنامهی PartCover سورس باز و رایگان بوده و همچنین مختص به NUnit نیز تهیه شده است. این برنامه را از اینجا میتوانید دریافت و نصب کنید. در ادامه نحوهی تنظیم آنرا بررسی خواهیم کرد:
الف) ایجاد یک پروژه آزمون واحد جدید
جهت توضیح بهتر سه سؤال مطرح شده در ابتدای این مطلب، بهتر است یک مثال ساده را در این زمینه مرور نمائیم: (پیشنیاز: (+))
یک Solution جدید در VS.NET آغاز شده و سپس دو پروژه جدید از نوعهای کنسول و Class library به آن اضافه شدهاند:
پروژه کنسول، برنامه اصلی است و در پروژه Class library ، آزمونهای واحد برنامه را خواهیم نوشت.
کلاس اصلی برنامه کنسول به شرح زیر است:
namespace TestPartCover
{
public class Foo
{
public int DoFoo(int x, int y)
{
int z = 0;
if ((x > 0) && (y > 0))
{
z = x;
}
return z;
}
public int DoSum(int x)
{
return ++x;
}
}
}
using NUnit.Framework;
namespace TestPartCover.Tests
{
[TestFixture]
public class Tests
{
[Test]
public void TestDoFoo()
{
var result = new Foo().DoFoo(-1, 2);
Assert.That(result == 0);
}
}
}
به نظر همه چیز خوب است! اما آیا واقعا این آزمون کافی است؟!
ب) در ادامه به کمک برنامهی PartCover میخواهیم بررسی کنیم میزان پوشش آزمونهای واحد نوشته شده تا چه حدی است؟
پس از نصب برنامه، فایل PartCover.Browser.exe را اجرا کرده و سپس از منوی فایل، گزینهی Run Target را انتخاب کنید تا صفحهی زیر ظاهر شود:
توضیحات:
در قسمت executable file آدرس فایل nunit-console.exe را وارد کنید. این برنامه چون در حال حاضر برای دات نت 2 کامپایل شده امکان بارگذاری dll های دات نت 4 را ندارد. به همین منظور فایل nunit-console.exe.config را باز کرده و تنظیمات زیر را به آن اعمال کنید (مهم!):
<configuration>
<startup>
<supportedRuntime version="v4.0.30319" />
</startup>
و همچنین
<runtime>
<loadFromRemoteSources enabled="true" />
در ادامه مقابل working directory ، آدرس پوشه bin پروژه unit test را تنظیم کنید.
در این حالت working arguments به صورت زیر خواهند بود (در غیراینصورت باید مسیر کامل را وارد نمائید):
TestPartCover.Tests.dll /framework=4.0.30319 /noshadow
نام dll وارد شده همان فایل class library تولیدی است. آرگومان بعدی مشخص میکند که قصد داریم یک پروژهی دات نت 4 را توسط NUnit بررسی کنیم (اگر ذکر نشود پیش فرض آن دات نت 2 خواهد بود و نمیتواند اسمبلیهای دات نت 4 را بارگذاری کند). منظور از noshadow این است که NUnit مجاز به تولید shadow copies از اسمبلیهای مورد آزمایش نیست. به این صورت برنامهی PartCover میتواند بر اساس StackTrace نهایی، سورس متناظر با قسمتهای مختلف را نمایش دهد.
اکنون نوبت به تنظیم Rules آن است که یک سری RegEx هستند؛ به عبارتی چه اسمبلیهایی آزمایش شوند و کدامها خیر:
+[TestPartCover]*
-[nunit*]*
-[log4net*]*
همانطور که ملاحظه میکنید در اینجا از اسمبلیهای NUnit و log4net صرفنظر شده است و تنها اسمبلی TestPartCover (همان برنامه کنسول، نه اسمبلی برنامه آزمون واحد) بررسی خواهد گردید.
اکنون بر روی دکمه Save در این صفحه کلیک کرده و فایل نهایی را ذخیره کنید (بعدا توسط دکمه Load در همین صفحه قابل بارگذاری خواهد بود). حاصل باید به صورت زیر باشد:
<PartCoverSettings>
<Target>D:\Prog\Libs\NUnit\bin\net-2.0\nunit-console.exe</Target>
<TargetWorkDir>D:\Prog\1390\TestPartCover\TestPartCover.Tests\bin\Debug</TargetWorkDir>
<TargetArgs>TestPartCover.Tests.dll /framework=4.0.30319 /noshadow</TargetArgs>
<Rule>+[TestPartCover]*</Rule>
<Rule>-[nunit*]*</Rule>
<Rule>-[log4net*]*</Rule>
</PartCoverSettings>
برای شروع به بررسی، بر روی دکمه Start کلیک نمائید. پس از مدتی، نتیجه به صورت زیر خواهد بود:
بله! آزمون واحد تهیه شده تنها 39 درصد اسمبلی TestPartCover را پوشش داده است. مواردی که با صفر درصد مشخص شدهاند، یعنی فاقد آزمون واحد هستند و نکته مهمتر پوشش 91 درصدی متد DoFoo است. برای اینکه علت را مشاهده کنید از منوی View ، گزینهی Coverage detail را انتخاب کنید تا تصویر زیر نمایان شود:
قسمت نارنجی در اینجا به معنای عدم پوشش آن در متد TestDoFoo تهیه شده است. تنها قسمتهای سبز را توانستهایم پوشش دهیم و برای بررسی تمام شرطهای این متد نیاز به آزمونهای واحد بیشتری میباشد.
روش نهایی کار نیز به همین صورت است. ابتدا آزمون واحد تهیه میشود. سپس میزان پوشش آن بررسی شده و در ادامه سعی خواهیم کرد تا این درصد را افزایش دهیم.
بوت استرپ (نگارش 3) چیست؟
این فایل را اگر به صورت معمولی در یک صفحه html بارگذاری شده از فایل سیستم اجرا کنید، پیام access is denied را دریافت خواهید کرد. علت این است که درخواستهای xmlHttpRequest آن برای اجرا نیاز به وب سرور دارند. بنابراین برای مواجه نشدن با این خطا، بهتر است مثال را در یک برنامه معمولی ASP.NET آزمایش کنید.
نوروز مبارک!
نورزتون مبارک امیدوارم سال خوبی داشته باشید.