EF Code First #12
یکی از دوستان در این قسمت نظری به شرح {در حین اجرای نمونه کدهای این مقاله در بخش MVC به خطای Value Cannot be null مواجه شدم } بیان کردند و راه حل نیز ارائه کردند و شما نیز پاسخی برای نظر ایشان ذکر کردید میشه در مورد وقوع این خطا بیشتر توضیح بدید ؟
با تشکر
مطالب پیشین مرتبط با لوسین را در اینجا میتوانید پیگیری کنید. آخرین نگارش آن که تا این تاریخ، 4.8 بتا است، با داتنت(Core) سازگار است و روش برپایی آغازین آن ... تغییرات قابل توجهی داشتهاست که خلاصهی آنها را در این مطلب بررسی خواهیم کرد.
1) بستههای جدید مورد نیاز
برای کار با لوسین جدید، نیاز است حداقل سهبستهی زیر را نصب کنیم تا به امکانات پایهای و کوئری گیریهای پیشرفتهی آن دسترسی داشته باشیم:
<PackageReference Include="Lucene.Net" Version="4.8.0-beta00016"/> <PackageReference Include="Lucene.Net.Analysis.Common" Version="4.8.0-beta00016"/> <PackageReference Include="Lucene.Net.QueryParser" Version="4.8.0-beta00016"/>
2) تهیه نگاشتهای لازم
فرض کنید شیء اصلی ما چنین ساختاری را دارد:
public class WhatsNewItemModel { public required int Id { set; get; } public required string OriginalTitle { set; get; } }
مرحلهی بعد کار با لوسین، تبدیل اشیاء سفارشی خود به شیء Document لوسین و برعکس است. به همین جهت به دو مپر برای این کارها نیاز است:
الف) نگاشتگر یک شیء سفارشی، به شیء Document
public static class LuceneDocumentMapper { public static Document MapToLuceneDocument(this WhatsNewItemModel post) { ArgumentNullException.ThrowIfNull(post); return [ new TextField(nameof(WhatsNewItemModel.OriginalTitle), post.OriginalTitle, Field.Store.YES), // Document StringField instances are sort of keywords, they are not analyzed, they indexed as is (in its original case). new StringField(nameof(WhatsNewItemModel.Id), post.Id.ToString(CultureInfo.InvariantCulture), Field.Store.YES), ]; } }
در اینجا یک متدالحاقی را تهیه کردهایم تا شیءای از نوع WhatsNewItemModel ما را به یک شیء Document لوسین، تبدیل کند.
چند نکته در اینجا حائز اهمیت هستند:
- در نگارش جدید لوسین، با اشیاء TextField و StringField جدید سروکار داریم و شیء قدیمی Field نگارشهای قبلی لوسین، منسوخ شده درنظر گرفته میشود.
- زمانی از شیء TextField استفاده میکنیم که قرار است توسط لوسین، تحلیل شده و در جستجوهای پیچیده استفاده شود.
- اگر فقط قرار است، مقداری را در این ایندکس ذخیره کنیم و قصد تحلیل آنها را نداریم و حداکثر یک کوئری سادهی یافتن اصل آنها، مدنظر ما است، باید از اشیاء StringField برای معرفی و نگاشت آنها استفاده کنیم (شبیه به کار با واژههای کلیدی).
- پرچم Field.Store.YES به این معنا است که اصل محتوای تحلیل شده نیز در ایندکس لوسین، درج شود. اگر این پرچم را به NO تنظیم کنیم، فقط تحلیل آن صورت گرفته و نتیجهی آن ذخیره میشود، که برای جستجوها مفید است؛ اما مقدار این فیلد دیگر قابل بازیابی نخواهد بود.
ب) نگاشتگر یک شیء Document لوسین، به یک شیء سفارشی
در زمان کوئری گرفتن از لوسین، خروجی نهایی یک شیء Document آن است که باید به شیء سفارشی مدنظر ما نگاشت شود:
public static class LuceneDocumentMapper { public static LuceneSearchResult MapToLuceneSearchResult(this Document document) { ArgumentNullException.ThrowIfNull(document); return new LuceneSearchResult { Id = document.Get(nameof(WhatsNewItemModel.Id), CultureInfo.InvariantCulture).ToInt(), OriginalTitle = document.Get(nameof(WhatsNewItemModel.OriginalTitle), CultureInfo.InvariantCulture) }; } }
نمونهای از این نگاشت را در متد الحاقی فوق مشاهده میکنید که توسط متد Get شیء Document قابل انجام است. بدیهی است خروجی این متد، یک رشتهاست و در صورت نیاز باید توسط ما کار تبدیلات ثانویه آنها انجام شود.
3) نیاز به یک تحلیلگر مناسب
لوسین برای تولید ایندکسهای جستجوی تمام متنی خود، از یک سری Analyzer استفاده میکنید که اگر سری پیشین مطالب مرتبط را مطالعه کنید، به نمونهی StandardAnalyzer آن خواهید رسید که هنوز هم معتبر و قابل استفادهاست و یا میتوان همانند سایت جاری، از یک LowerCaseHtmlStripAnalyzer استفاده کرد که این کارها را همزمان انجام میدهد:
الف) از یک لیست PersianStopwords.List برای حذف واژههای کم اهمیت زبان فارسی استفاده میکند. برای مثال ما نمیخواهیم که واژهی «ما» را با اهمیت شمرده و ایندکس کند و امثال آن.
ب) LowerCaseFilter را به متون دریافتی اعمال میکند. این کار در پشت صحنهی StandardAnalyzer توکار لوسین هم اعمال میشود. اگر با این موضوع آشنا نباشید، ممکن است در حین کوئری گرفتن، به نتیجهای نرسید! چون متن ارسالی به لوسین را ابتدا باید lower-case کنید و سپس آنرا کوئری بگیرید.
ج) HTMLStripCharFilter توکار لوسین هم به آن اعمال شدهاست. از این جهت که متن مقالات ما به همراه تگهای HTML ای هم هستند. این فیلتر کار حذف کردن آنها را در حین تحلیل، انجام میدهد و دیگر نیازی نیست تا ما خودمان متن ارسالی به لوسین را تمیز کنیم.
نکتهی مهم: این تحلیلگر ویژه، فقط باید به فیلدهایی از نوع TextField اعمال شود. اگر آنرا به StringField ها اعمال کنیم، دیگر قادر به کوئری گرفتن از آنها نخواهیم بود! چون تحلیلگر StringFieldها باید از نوع توکار KeywordAnalyzer ثبت و معرفی شود. این نوع فیلدها، حالت واژههای کلیدی را دارند (به همان صورتی که هست ثبت میشوند) و قرارنیست که توسط لوسین تحلیل ویژهای شوند. به همین جهت برای رسیدن به یک تحلیلگر ترکیبی که بتواند این دو نوع فیلد را با هم پوشش دهد و کار معرفی چندین نوع تحلیلگر را یکجا انجام دهد، نیاز به یک PerFieldAnalyzerWrapper جدید داریم:
_keywordAnalyzer = new KeywordAnalyzer(); _lowerCaseHtmlStripAnalyzer = new LowerCaseHtmlStripAnalyzer(LuceneVersion); _analyzer = new PerFieldAnalyzerWrapper(_lowerCaseHtmlStripAnalyzer, new Dictionary<string, Analyzer> { { nameof(WhatsNewItemModel.Id), _keywordAnalyzer } });
PerFieldAnalyzerWrapper در حقیقت برای تمام فیلدهایی که در قسمت دیکشنری فوق، ذکر نشدهاند، از LowerCaseHtmlStripAnalyzer استفاده میکند. برای مابقی موارد از KeywordAnalyzer کمک خواهد گرفت.
4) روش صحیح راه اندازی reader و writer های ایندکس لوسین جدید
کار با لوسین به حدی سریع است که از کیفیت آن شگفت زده خواهید شد! اما ... بهشرطی که بدانید دقیقا به چه صورتی باید نویسنده و خوانندهی ایندکسهای آنرا مدیریت کنید. اکثر مثالهایی را که بر روی اینترنت پیدا میکنید، به همراه متدهایی هستند که مدام در حال گشودن و dispose این نویسندهها و خوانندههای ایندکس هستند که ... این مثالها، روش کار صحیح با لوسین نیستند! و به شدت آنرا کند میکنند.
نکتهی مهمی که این مثالها به آن توجهی نکردهاند، «thread-safe» بودن نویسنده و خوانندهی ایندکس لوسین است. یعنی میتوان یک نمونه از اینها را در ابتدای کار برنامه ایجاد کرد و تا آخر کار برنامه، بدون نیاز به نمونه سازی مجدد و باز و بسته کردن آنها، بارها مورد استفادهی مجدد قرار داد و هیچ تداخلی هم ندارند و از قسمتهای مختلف برنامه هم قابل دسترسی هستند.
به همین جهت باید یک سرویس مرکزی را برای اینکار تدارک دید که طول عمر آن، حتما Singleton باشد تا بتواند نویسنده و خوانندهی ایندکس لوسین را فقط یکبار نمونه سازی و ایجاد کرده و تا پایان کار برنامه، زنده نگه دارد (کدهای کامل این کلاس را در اینجا میتوانید مطالعه کنید):
public class FullTextSearchService : IFullTextSearchService { private const LuceneVersion LuceneVersion = Lucene.Net.Util.LuceneVersion.LUCENE_48; private readonly Analyzer _analyzer; private readonly IAppFoldersService _appFoldersService; private readonly FSDirectory _fsDirectory; // IndexWriter instances are completely thread safe, meaning multiple threads can call any of its methods, concurrently. private readonly IndexWriter _indexWriter; private readonly KeywordAnalyzer _keywordAnalyzer; private readonly ILogger<FullTextSearchService> _logger; private readonly LowerCaseHtmlStripAnalyzer _lowerCaseHtmlStripAnalyzer; // Safely shares IndexSearcher instances across multiple threads, while periodically reopening. private readonly SearcherManager _searcherManager; private bool _isDisposed; public FullTextSearchService(IAppFoldersService appFoldersService, ILogger<FullTextSearchService> logger) { _appFoldersService = appFoldersService ?? throw new ArgumentNullException(nameof(appFoldersService)); _logger = logger; _keywordAnalyzer = new KeywordAnalyzer(); _lowerCaseHtmlStripAnalyzer = new LowerCaseHtmlStripAnalyzer(LuceneVersion); _analyzer = new PerFieldAnalyzerWrapper(_lowerCaseHtmlStripAnalyzer, new Dictionary<string, Analyzer> { // Document StringField instances are sort of keywords, they are not analyzed, they indexed as is (in its original case). // But StandardAnalyzer applies lower case filter to a query. // We can fix this by using KeywordAnalyzer with our query parser. { nameof(WhatsNewItemModel.Id), _keywordAnalyzer }, { nameof(WhatsNewItemModel.DocumentTypeIdHash), _keywordAnalyzer }, { nameof(WhatsNewItemModel.DocumentContentHash), _keywordAnalyzer } }); _fsDirectory = FSDirectory.Open(_appFoldersService.LuceneIndexFolderPath); _indexWriter = new IndexWriter(_fsDirectory, new IndexWriterConfig(LuceneVersion, _analyzer)); _searcherManager = new SearcherManager(_indexWriter, applyAllDeletes: true, searcherFactory: null); }
این سرویس، یک سرویس Singleton است که نحوهی آغاز و شروع به کار با اشیاء لوسین را در سازندهی آن مشاهده میکنید.
توضیحات:
الف) در اینجا، روش نمونه سازی PerFieldAnalyzerWrapper را که پیشتر در مورد آن بحث شد، مشاهده میکنید.
ب) سپس یک IndexWriter، نمونه سازی میشود که از تحلیلگر ترکیبی ما استفاده میکند.
ج) در ادامه یک SearcherManager جدید را مشاهده میکنید که با IndexWriter برنامه هماهنگ است و هر زمانیکه سندی به لوسین اضافه میشود، قادر به کوئری گرفتن از آن هم خواهیم بود.
نکتهی مهم: طول عمر تمام این موارد، با طول عمر کلاس سرویس جاری، یکی است. یعنی تنها یکبار در طول عمر برنامه نمونه سازی شده و تا پایان کار آن، زنده نگه داشته میشوند.
5) روش افزودن یک سند به ایندکس لوسین و سپس به روز رسانی آن
اکنون با استفاده از نگاشتگرهایی که در ابتدای بحث تهیه کردیم و همچنین شیء IndexWriter فوق، به صورت زیر میتوان یک شیء سفارشی خود را به ایندکس لوسین اضافه کنیم:
_indexWriter.AddDocument(post.MapToLuceneDocument()); _indexWriter.Flush(triggerMerge: true, applyAllDeletes: true); _indexWriter.Commit();
و یا اگر خواستیم سند موجودی را به روز کنیم، روش کار به شکل زیر است:
_indexWriter.UpdateDocument(new Term(nameof(WhatsNewItemModel.Id), post.Id.ToString()), post.MapToLuceneDocument());
new Term، در حقیقت یک کوئری جدید را سبب میشود که توسط آن سندی یافت شده، در پشت صحنه حذف میشود و سپس سند جدیدی بجای آن درج خواهد شد. در اینجا باید دقت داشت که چون Id ثبت شده از نوع StringField است، نباید حالت lower-case آنرا جستجو کرد و باید دقیقا به همان نحوی که ثبت شده، جستجو شود.
6) روش کار با searcherManager جدید لوسین
همانطور که عنوان شد، لوسین جدید به همراه یک searcherManager هم هست که کار آن، ارائهی thread-safe دسترسی به خوانندهی ایندکس لوسین است. نحوهی عمومی کار با آن را در ادامه مشاهده میکنید:
private TResult DoSearch<TResult>(Func<IndexSearcher, TResult> action, TResult defaultValue) { _searcherManager.MaybeRefreshBlocking(); var indexSearcher = _searcherManager.Acquire(); try { return action(indexSearcher); } catch (FileNotFoundException) { // It's not indexed yet. return defaultValue; } finally { _searcherManager.Release(indexSearcher); } }
با استفاده از searcherManager، در طول مدت زمان کوتاهی، بر روی ایندکس قفلگذاری شده و یک indexSearcher امن، در اختیار متدهای استفاده کنندهی از آن قرار میگیرند و در پایان کار، این قفل رها میشود.
برای مثال یک نمونه روش استفاده از این indexSearcher امن، به صورت زیر است:
public int GetNumberOfDocuments() => DoSearch(indexSearcher => indexSearcher.IndexReader.NumDocs, defaultValue: 0);
مابقی مثالهای آنرا میتوانید در کلاس FullTextSearchService مشاهده کنید که به همراه یافتن «مطالب مشابه»، جستجوهای صفحه بندی شده، جستجوهای مرتب شدهی بر اساس یک فیلد، امکان دسترسی به تمام اسناد ذخیره شدهی در ایندکس لوسین و امثال آن است که کلیات آن با قبل تفاوتی نکردهاست و مطالب و نکات آنرا پیشتر در مقالات سری لوسین بررسی کردهایم. تنها تفاوت مهمی که در اینجا وجود دارد، نحوهی برپایی و راه اندازی تحلیلگر، خواننده و نویسندهی ایندکس آن است که در این مطلب بررسی شدند؛ وگرنه کلیات جستجوی پیشرفتهی آن، مانند قبل است و تفاوت خاصی نکردهاست.
همانطور که مشاهده میکنید، درخواست یک فایل استاتیک، سبب اجرای یک کوئری بر روی بانک اطلاعاتی شدهاست و یک Context خاص خودش را نیز ایجاد کردهاست. اگر به قسمت سابقهی متدهایی که سبب بروز این امر شدهاند (در همان برگه، در پایین صفحه) دقت کنیم، به متد Application_AuthenticateRequest فایل global.asax.cs میرسیم. هر چند در فایل RouteConfig.cs مسیرهای اسکریپتها و فایلهای CSS جهت صرفنظر شدن معرفی شدهاند، اما این موارد بر روی متد خاص Application_AuthenticateRequest تاثیری ندارند و این متد به ازای هر درخواست رسیدهی به IIS یکبار اجرا میشود؛ زیرا یک چنین تنظیمی در فایل web.config وجود دارد:
<modules runAllManagedModulesForAllRequests="true">
کنترل ASP.NET MVC Bundles در حین Forms Authentication
اگر بخواهیم درخواستهای رسیدهی به Application_AuthenticateRequest را کنترل کنیم، میتوان چنین متدی را تدارک دید:
private bool shouldIgnoreRequest() { string[] reservedPath = { "/__browserLink", "/img", "/fonts", "/Scripts", "/Content" }; var rawUrl = Context.Request.RawUrl; if (reservedPath.Any(path => rawUrl.StartsWith(path, StringComparison.OrdinalIgnoreCase))) { return true; } return BundleTable.Bundles.Select(bundle => bundle.Path.TrimStart('~')) .Any(bundlePath => rawUrl.StartsWith(bundlePath, StringComparison.OrdinalIgnoreCase)); }
bundles.Add(new ScriptBundle("~/bundles/modernizr").Include( "~/Scripts/modernizr-*"));
protected void Application_AuthenticateRequest(Object sender, EventArgs e) { if (shouldIgnoreRequest()) return; if (Context.User == null) return;
14 قابلیت بهبود یافته برتر در VB 14
1. 50 درصد سریعتر شدن زمان کامپایل. نسخه فعلی کامپایلر VB در ++C نوشته شده است, ولی تیم VB کامپایلر جدید VB.NET 14 را کاملا در VB.NET بازنویسی کرده اند.نتایج دو مقایسه :
* زمان Build یک Solution بزرگ(Huge) با 1.3 میلیون خط کد, از 68 ثانیه رسید به 41 ثانیه.
* زمان Load یک Cold Solution (یک پروژه Win Store) از 6.7 ثانیه رسید به 4.6 ثانیه.
2. به اشتراک گذاری یک پروژه(یک سری ار سورس کد ها) بین چند تا Application
3. نمایش Expressionهای Lambda و LINQ در پنجره Watch و Immediate در زمان Debug
4. قرار دادن کامنت در لا به لای عبارات LINQ
5. استفاده از اپراتور جدید ?. جهت بررسی Null بودن برای تسریع در حین کد نویسی
و ...
let name: string; name = "Vahid"; // OK name = null; // OK name = undefined; // OK
let age: number; age = 24; // OK age = null; // OK age = undefined; // OK
نوع null در TypeScript
همانند JavaScript، نوع null تنها یک مقدار معتبر نال را میتواند داشته باشد و نمیتوان برای مثال یک رشته را به آن انتساب داد. اما انتساب این مقدار به هر نوع متغیر دیگری، سبب پاک شدن مقدار آن خواهد شد. با فعالسازی strictNullChecks، این نوع را تنها به نوعهای نالپذیر میتوان انتساب داد.
نوع undefined در TypeScript
هر متغیری که مقداری به آن انتساب داده نشده باشد، با undefined مقدار دهی میشود. این مورد حتی جهت خروجی متدها نیز صادق است و اگر return ایی در آنها فراموش شود، این خروجی نیز به undefined تفسیر میشود.
در اینجا نیز اگر نوع متغیری به undefined تنظیم شد، این متغیر تنها مقدار undefined را میتواند بپذیرد. تنها با خاموش کردن پرچم strictNullChecks میتوان آنرا به اعداد، رشتهها و غیره نیز انتساب داد.
فعالسازی نوعهای نال نپذیر در TypeScript
برای فعالسازی این قابلیت، نیاز است پرچم strictNullChecks را در فایل تنظیمات کامپایلر به true تنظیم کرد:
{ "compilerOptions": { "strictNullChecks": true } }
برای مثال اگر متدی، رشتهای را به عنوان پارامتر قبول کند، تا پیش از TypeScript 2.0 و فعالسازی strictNullChecks آن، مشخص نبود که رشتهی دریافتی از آن واقعا یک رشتهاست و یا شاید null. اما اکنون یک رشته، فقط یک رشتهاست و دیگر نال پذیر نیست.
let foo: string = null; // Error! Type 'null' is not assignable to type 'string'.
Uncaught ReferenceError: foo is not defined Uncaught TypeError: window.foo is not a function
این مورد برای آرایهها نیز صادق است:
// With strictNullChecks set to false let d: Array<number> = [null, undefined, 10, 15]; //OK let e: Array<string> = ["pie", null, ""]; //OK // With strictNullChecks set to true let d: Array<number> = [null, undefined, 10, 15]; // Error let e: Array<string> = ["pie", null, ""]; // Error
ساده سازی تعریف بررسیهای با پرچم strict، در TypeScript 2.3
تعداد گزینههای قابل تنظیم در فایل tsconfig روز به روز بیشتر میشوند. به همین جهت برای ساده سازی فعالسازی آنها، از TypeScript 2.3 به بعد، پرچم strict نیز به این تنظیمات اضافه شدهاست. کار آن فعالسازی یکجای تمام بررسیهای strict است؛ مانند noImplicitAny، strictNullChecks و غیره.
{ "compilerOptions": { "strict": true /* Enable all strict type-checking options. */ } }
{ "compilerOptions": { "strict": true, "noImplicitThis": false } }
یک نکته: اجرای دستور tsc --init ، سبب تولید یک فایل tsconfig.json از پیش تنظیم شده، بر اساس آخرین قابلیتهای کامپایلر TypeScript میشود.
اما ... اکنون چگونه یک نوع را نالپذیر کنیم؟
TypeScript به همراه دو نوع ویژهی null و undefined نیز شدهاست که تنها دارای مقادیر null و undefined میتوانند باشند. به این معنا که در حین تعریف نوع یک متغیر، میتوان این دو را نیز ذکر کرد و دیگر تنها به عنوان دو مقدار مطرح نیستند. به این ترتیب میتوان از آنها یک union type را ایجاد کرد:
let foo: string | null = null; // Okay!
let name: string | null; name = "Vahid"; // OK name = null; // OK name = undefined; // Error
یک نکته:
تا پیش از این اگر متغیری را به این صورت تعریف میکردیم:
let z = null;
بررسی انتساب، پیش از استفاده
با فعالسازی strictNullChecks، اکنون کامپایلر برای تمام نوعهایی که undefined نیستند، یک مقدار اولیه را پیش از استفادهی از آنها درخواست میکند:
testAssignedBeforeUseChecking() { let x: number; console.log(x); }
[ts] Variable 'x' is used before being assigned.
اما در حالت ذیل، عدد z میتواند عدد و یا undefined باشد؛ به همین جهت کامپایلر با استفادهی از آن مشکلی نخواهد داشت:
let z: number | undefined; console.log(z);
یک نکته: خواص و پارامترهای اختیاری، به صورت خودکار دارای نوع undefined نیز هستند. برای مثال امضای متد ذیل:
method1(x?: number) { }
method1(x?: number | undefined) { }
اجبار به بررسی نال نبودن مقادیر، پیش از استفادهی از آنها در متدهای نال نپذیر
اگر پارامتر متدی یا خاصیت شیءایی نال پذیر نباشند، با ارسال مقدار نوعی به آنها که میتواند null و یا undefined را بپذیرد، یک خطای زمان کامپایل صادر خواهد شد. در اینجا محافظهای نوعها توسعه یافتهاند تا اگر بررسی نال یا undefined بودن مقداری انجام شد، مشکلی در جهت استفادهی از آنها نباشد:
f(x: number): string { return x.toString(); } testTypeGuards() { let x: number | null | undefined; if (x) { this.f(x); // Ok, type of x is number here } else { this.f(x); // Error, type of x is number? here } }
Argument of type 'number | null | undefined' is not assignable to parameter of type 'number'. Type 'undefined' is not assignable to type 'number'.
امکان این بررسی در مورد عبارات شرطی نیز صادق است:
getLength(s: string | null) { return s ? s.length : 0; }
توسعهی محافظهای نوعها جهت کار با نوعهای نال نپذیر
در مثال ذیل، خروجی متد isNumber دارای امضایی به همراه is است:
isNumber(n: any): n is number { // type guard return typeof n === "number"; }
usedMb(usedBytes?: number): number | undefined { return this.isNumber(usedBytes) ? (usedBytes / (1024 * 1024)) : undefined; }
usedMb2(usedBytes?: number): number | undefined { return usedBytes ? (usedBytes / (1024 * 1024)) : undefined; }
همچنین امضای متد نیز به number | undefined تغییر یافتهاست. در غیر اینصورت، خطای زمان کامپایل Type undefined is not assignable to type number صادر خواهد شد.
در حین استفادهی از یک چنین متدی، دیگر نمیتوان به خروجی آن به صورت ذیل دسترسی یافت:
formatUsedMb(): string { //ERROR: TS2531: Object is possibly undefined return this.usedMb(123).toFixed(0).toString(); }
formatUsed(): string { const usedMb = this.usedMb(123); return usedMb ? usedMb.toFixed(0).toString() : ""; }
لغو بررسی strictNullChecks به صورت موقت
با استفاده از اپراتور ! میتوان به کامپایلر اطمینان داد که این متغیر یا خاصیت، دارای مقدار نال نیست و نخواهد بود:
export interface User { name: string; age?: number; }
printUserInfo(user: User) { if (user.age != null) { console.log(`${user.name}, ${user.age.toString()}`); } }
printUserInfo(user: User) { console.log(`${user.name}, ${user.age.toString()}`); }
و یا میتوان توسط اپراتور ! این بررسی را به صورت موقت خاموش کرد:
printUserInfo(user: User) { console.log(`${user.name}, ${user.age!.toString()}`); }
[tslint] Forbidden non null assertion (no-non-null-assertion)
یک نکتهی تکمیلی
پس از آزمایش موفقیت آمیز نوعهای نال نپذیر در TypeScript، مایکروسافت قصد دارد این ویژگی را به C# 8.0 نیز در مورد نوعهای ارجاعی که میتوانند نال پذیر باشند، اضافه کند (امکان داشتن نوعهای ارجاعی نالنپذیر).
در جهت تکمیل بحث "بررسی امنیتی، حین استفاده از jQuery Ajax"، یک مورد دیگر را هم میتوان اضافه کرد: چگونه صفحهی معروف Add service reference را در VS.NET جهت سرویس WCF خود از کار بیندازیم؟
راه حل آن هم بسیار ساده است اما چون عموما در منابع مرتبط با جملات و کلمات بیش از حد فنی بیان میشود، شاید از دید دور مانده باشد:
اگر WCF Service تولیدی شما تنها قرار است توسط برنامهی Silverlight یا جاوا اسکریپتی موجود در پروژهی جاری مورد استفاده قرار گیرد، باید Meta Data مرتبط با آن سرویس را جهت بالابردن امنیت سیستم، حذف نمود. توسط این Meta Data میتوان ServiceContract ، OperationContract و سایر اطلاعات یک WCF Service را استخراج نمود.
الف) روش غیر فعال کردن متادیتا در یک Ajax enabled WCF Service
به فایل وب کانفیگ برنامه مراجعه کرده و تغییر زیر را اعمال کنید:
...
<behavior name="">
<serviceMetadata httpGetEnabled="false" httpsGetUrl="false" />
...
</behavior>
...
ب) روش غیرفعال کردن متادیتا در یک Silverlight enabled WCF Service
ابتدا قسمت الف را اعمال نموده سپس تغییر زیر را نیز لحاظ نمائید (IMetadataExchange به صورت کامنت درآمده):
<!-- <endpoint address="mex" binding="mexHttpBinding"
contract="IMetadataExchange" /> -->
با این تغییرات ساده، گزینهی Add service reference دیگر قابلیت تشخیص خودکار اطلاعات سرویس شما را نداشته و با یک خطا متوقف خواهد شد:
The HTML document does not contain Web service discovery information.
Metadata contains a reference that cannot be resolved.
سؤال:
1- آیا با این تغییر در عملکرد WCF سرویس ما اخلال ایجاد خواهد شد؟
پاسخ: خیر. تنها Web service discovery information را از کار انداختهایم.
2- در صورت تغییر کدهای WCF Service چه باید کرد؟
پاسخ: اگر امضای متدها و اینترفیسهای تعریف شده تغییری نداشتهاند، لزومی به هیچ نوع تغییری نیست. در غیراینصورت، سریع موارد الف و ب فوق را به حالت اول برگردانده، کلاینت مورد استفاده را به روز کنید، مجددا متادیتا را حذف نمائید.
در این مطلب با توجه به سؤالات زیادی که در مورد صرفا نحوهی اجرای بدون خطای آن وجود داشت، ریز مراحل آنرا بررسی میکنیم.
پیشنیازهای توسعهی برنامه
- با توجه به استفاده از ویژگیهای C# 6 در این پروژه، حتما نیاز است برای کار و اجرای آن از VS 2015 استفاده کنید.
- همچنین این پروژه از قابلیت «فایل استریم» SQL Server استفاده میکند. بنابراین نیاز است نگارش متناسبی از SQL Server را پیشتر نصب کرده باشید (هر نگارشی بالاتر از SQL Server 2005).
- اگر از ReSharper استفاده میکنید، به صورت موقت آنرا به حالت تعلیق درآورید (منوی tools، گرینهی options و انتخاب resharper و سپس suspend کردن آن). این مورد سرعت بازیابی بستههای نیوگت را به شدت افزایش میدهد.
بازیابی وابستگیهای نیوگت پروژه
مرسوم نیست چند 10 مگابایت وابستگیهای پروژه را به صورت فایلهای باینری، به مخزن کدها ارسال کرد. از این جهت که نیوگت بر اساس مداخل فایلهای packages.config، قابلیت بازیابی و نصب خودکار آنها را دارد. بنابراین ابتدا package manger console را باز کنید؛ از طریق منوی Tools -> NuGet Package Manager -> Package Manager Console
همانطور که در تصویر مشاهده میکنید، نیوگت تشخیص دادهاست که بستههایی برای نصب وجود دارند. بنابراین بر روی دکمهی restore کلیک کنید تا کار دریافت و نصب خودکار این بستهها از اینترنت شروع شود. البته اگر پیشتر این بستهها را در پروژههای دیگری نصب کرده باشید، نیوگت از کش موجود در سیستم استفاده خواهد کرد و برای دریافت آنها به اینترنت مراجعه نمیکند. ولی در هر حال اتصال به اینترنت ضروری است.
پس از پایان کار بازیابی بستهها، یکبار کل Solution را Build کنید تا مطمئن شوید که تمام بستههای مورد نیاز به درستی بازیابی و نصب شدهاند (Ctrl+Shift+B و یا همان منوی Build و انتخاب گزینهی Build Solution).
تنظیمات رشته اتصالی بانک اطلاعاتی برنامه
پس از Build موفق کل Solution در مرحلهی قبل، اکنون نوبت به برپایی تنظیمات بانک اطلاعاتی برنامه است. برای این منظور فایل web.config ذیل را باز کنید:
Decision\src\Decision.Web\Web.config
یک چنین تنظیمی را مشاهده میکنید:
<connectionStrings> <clear /> <add name="DefaultConnection" connectionString="Data Source=.\sqlexpress;Initial Catalog=DecisionDb;Integrated Security = true;MultipleActiveResultSets=True;" providerName="System.Data.SqlClient" /> </connectionStrings>
<connectionStrings> <clear /> <add name="DefaultConnection" connectionString="Data Source=(local);Initial Catalog=DecisionDb;Integrated Security = true;MultipleActiveResultSets=True;" providerName="System.Data.SqlClient" /> </connectionStrings>
در این حالت نیاز است بانک اطلاعاتی خالی DecisionDb را خودتان ایجاد کنید. علت آن به AutomaticMigrationsEnabled = false بر میگردد؛ که در ادامه توضیح داده شدهاست و همچنین وجود تنظیم ذیل در فایل Decision\src\Decision.Web\App_Start\ApplicationStart.cs
Database.SetInitializer<ApplicationDbContext>(null);
ایجاد بانک اطلاعاتی برنامه و تنظیمات آن
پس از آن، نوبت به ایجاد بانک اطلاعاتی برنامه است. چون این برنامه از EF Code first استفاده میکند، قادر است بانک اطلاعاتی ذکر شدهی در Initial Catalog فوق را به صورت خودکار ایجاد کند (با تمام جداول، روابط و تنظیمات آنها). این اطلاعات هم از پروژهی Decision.DataLayer و پوشهی Migrations آن تامین میشوند.
اگر به فایل Decision\src\Decision.DataLayer\Migrations\201602072159421_Initial.cs مراجعه کنید، یکسری تنظیمات دستی را هم علاوه بر کدهای خودکار EF، مشاهده خواهید کرد:
//. . . Sql("EXEC sp_configure filestream_access_level, 2"); Sql("RECONFIGURE", true); Sql("alter database DecisionDb Add FileGroup FileGroupApplicant contains FileStream", true); Sql("alter database DecisionDb add file ( name = 'ApplicantDocuements' , filename = 'C:\\FileStream\\ApplicantDocuements') to filegroup FileGroupApplicant", true); //. . .
بنابراین نیاز است در درایور C، پوشهی خالی FileStream از پیش تهیه شده باشد (نیازی به ایجاد پوشهی ApplicantDocuements نیست و این پوشه به صورت خودکار ایجاد میشود).
و در فایل Decision\src\Decision.DataLayer\Migrations\Configuration.cs مشخص شدهاست که AutomaticMigrationsEnabled = false. به این معنا که تنظیمات فوق به صورت خودکار به بانک اطلاعاتی اعمال نشده و باید چند دستور ذیل را به صورت دستی صادر کنیم:
الف) ابتدا package manager console را مجددا باز کنید و در اینجا default project را بر روی Decision.DataLayer قرار دهید. از این جهت که قرار است اطلاعات migration را از این پروژه دریافت کنیم:
در غیراینصورت پیام خطای No migrations configuration type was found in the assembly را دریافت خواهید کرد.
ب) سپس دستور ذیل را صادر کنید (با این فرض که بانک اطلاعاتی خالی DecisionDb ذکر شدهی در قسمت قبل را پیشتر ایجاد کردهاید):
PM> Update-Database -Verbose -ConnectionStringName "DefaultConnection" -StartUpProjectName "Decision.Web"
من در این حالت پیام خطای Update-Database : The term 'Update-Database' is not recognized as the name of a cmdlet را دریافت کردم.
راه حل: یکبار ویژوال استودیو را بسته و مجددا باز کنید تا کار نصب بستهها و بارگذاری تمام وابستگیهای آنها به درستی صورت گیرد. این خطا به این معنا است که هرچند NuGet کار نصب EF را انجام دادهاست، اما هنوز اسکریپتهای پاورشل آن که دستوراتی مانند Update-Database را اجرا میکنند، بارگذاری نشدهاند. راه حل آن بستن و اجرای مجدد ویژوال استودیو است.
پس از اجرای مجدد ویژوال استودیو و انتخاب default project صحیح (مطابق تصویر فوق)، مجددا دستور Update-Database فوق را صادر کنید (با پارامترهای ویژهی آن).
با صدور این دستور، پیام خطای ذیل را دریافت کردم:
The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded.
PM> Update-Package -Reinstall "EntityFramework" -ProjectName "Decision.DataLayer"
اینبار دستور update-database فوق (با پارامترهای ویژهی آن) بدون مشکل اجرا شد و بانک اطلاعاتی مربوطه تشکیل گردید.
اکنون برنامه قابل اجرا است و در این حالت است که میتوان دکمهی F5 را جهت اجرای برنامه فشرد. البته در این حالت بر روی پروژهی Decision.Web کلیک راست کرده و گزینهی set as startup project را نیز انتخاب کنید و سپس F5:
لطفا سؤالاتی را که مرتبط با «راه اندازی» این پروژه نیستند، در قسمت بازخوردهای اختصاصی آن مطرح کنید.