اشتراکها
اگر برنامه نویس NET. باشید، پس از مدتی کار با LINQ، در سایر زبانهای دیگر نیز به دنبال این قابلیت فوق العادهی functional یا تابعی خواهید گشت. در این مطلب، خلاصهای از متدهای توکار جاوا اسکریپت را که میتوانند معادلهایی برای متدهای LINQ to Objects دات نت باشند، بررسی خواهیم کرد.
تدارک ساختار ابتدایی این مطلب
در اینجا اینترفیسی را که بیانگر ساختار شیء شخص است، به صورت ذیل ایجاد میکنیم:
سپس آرایهای را بر اساس این شیء تدارک خواهیم دید:
در ادامه تمام اعمال مدنظر را بر روی این آرایه انجام میدهیم.
همچنین سه متد ذیل را نیز برای لاگ کردن عنوان آزمایش، نمایش محتوای آرایهی اصلی و نمایش نتیجهی آزمایش، به این کلاس اضافه میکنیم:
معادل متد Where در TypeScript
متد filter که جزو متدهای توکار ES5 است، میتواند معادلی برای متد Where، جهت فیلتر کردن عناصر بر اساس یک خاصیت، یا چندین خاصیت باشد:
با این خروجی
در اینجا نحوهی استفادهی از arrow functions ES6 را نیز جهت ساده سازی تعریف callback متد filter مشاهده میکنید که نمایش آن بسیار شبیه به عبارات LINQ در دات نت است.
معادل متد Any در TypeScript
متد some که جزو متدهای توکار ES5 است، میتواند معادلی برای متد Any باشد. اگر یکی از عناصر آرایه، بر اساس شرط تعیین شده یافت شود، این متد مقدار true را باز میگرداند:
با این خروجی:
در مثال اول، بررسی شدهاست که آیا شخصی با سن کمتر از 40 در این لیست وجود دارد؟
در مثال دوم، جستجویی بر روی تمام خواص شیء شخص انجام شدهاست. در اینجا توسط متد Object.keys، لیست خواص شیء یافت شدهاست. سپس بر روی این لیست توسط متد some، بررسی شدهاست که آیا خاصیت رشتهای وجود دارد که مساوی عبارت filterBy باشد؟ حاصل این بررسی به عنوان شرط متد filter جهت بازگشت آرایهی متناظری از اشخاص یافت شده، استفاده شدهاست.
معادل متد Contains در TypeScript
متد includes که جزو متدهای توکار ES7 است، میتواند معادلی برای متد Contains باشد و کار آن بررسی وجود عنصری در یک لیست است:
در اینجا باید دقت داشت که اگر آرایهی مدنظر رشتهای و یا عددی باشد، متد includes نتیجهی مطلوبی را بازگشت میدهد. اما چون در اینجا وجود یک شیء را در لیست اشخاص بررسی میکنیم، این مقایسه بر اساس ارجاع عناصر خواهد بود و نتیجهی نهایی یافت شدن آن، منفی است (شیء searchElement هیچ ارجاعی را در آرایهی اشخاص ندارد، هرچند ظاهر آن شبیه به یکی از عناصر آن است). حتی متد indexOf نیز به همین صورت عمل میکند.
یکی از روشهای مقایسهی بر اساس تمام مقادیر خواص یک شیء، استفاده از متد JSON.stringify است که اگر آنرا با متد some ترکیب کنیم، میتوان به نتیجهی مطلوبی رسید:
معادل متد All در TypeScript
متد every که جزو متدهای توکار ES5 است، میتواند معادلی برای متد All باشد و کار آن بررسی صحت شرط اعمالی، بر روی تک تک عناصر لیست است. اگر این بررسی با موفقیت صورت گرفت، مقدار true را بازگشت میدهد:
با این خروجی:
معادل متدهای First و FirstOrDefault در TypeScript
میتوان از متدهای filter و یا find بومی ES5 و ES 6 برای شبیه سازی متدهای First (یافتن اولین عنصر درخواستی در یک لیست) و FirstOrDefault استفاده کرد:
متد filter، در صورت برآورده نشدن شرط آن، یک آرایهی خالی را بازگشت میدهد که مقدار [0] آن، undefined است. بنابراین ترکیب آن با null ||، سبب بازگشت نال، در صورت خالی بودن آرایه میشود؛ یا همان حالت OrDefault (یا بازگشت مقدار پیش فرض، یا نال در اینجا). متد find نیز در صورت نیافتن عنصر درخواستی، مقدار undefined را بازگشت میدهد.
معادل متد FindIndex در TypeScript
متد findIndex که جزو متدهای توکار ES6 است، میتواند معادلی برای متد FindIndex در جهت یافتن ایندکس عنصری در یک لیست، بر اساس شرط درخواستی، باشد.
با این خروجی:
معادل متد Select در TypeScript
متد map که جزو متدهای توکار ES5 است، میتواند معادلی برای متد Select، برای تغییر شکل نهایی خروجی یک لیست باشد:
برای مثال در اینجا در لیست اشخاص، تنها خاصیت name آنها، انتخاب و بازگشت داده شدهاست:
معادل متد Aggregate در TypeScript
متد reduce که جزو متدهای توکار ES5 است، میتواند شبیه به متد Aggregate عمل کند و لیستی از عناصر را به یک مقدار کاهش دهد:
با این خروجی:
معادل متد ForEach در TypeScript
متد forEach که جزو متدهای توکار ES5 است، میتواند معادلی برای متد ForEach باشد که روشی functional برای پیمودن عناصر یک لیست است:
با این خروجی:
معادل متد OrderBy در TypeScript
متد sort که جزو متدهای توکار ES5 است، میتواند معادلی برای متد OrderBy باشد که جهت مرتب سازی عناصر یک لیست از آن استفاده میشود:
متد sort یک callback را میپذیرد و هر بار دو آیتم در حال مرتب سازی را به آن ارسال میکند. در این حالت اگر خروجی این callback:
- مساوی صفر باشد، تغییری را به وجود نمیآورد.
- کمتر از صفر باشد، اولین عنصر را قبل از دومین عنصر قرار میدهد.
- بیشتر از صفر باشد، دومین عنصر را پس از اولین عنصر قرار میدهد.
منطق مقایسهی فوق را به صورت ذیل نیز میتوان خلاصه کرد:
با این خروجی:
و یا اگر بخواهیم این لیست را بر اساس نام اشخاص مرتب سازی کنیم، به منطق ذیل خواهیم رسید:
با این خروجی:
نکتهی مهم: همانطور که ملاحظه میکنید، متد sort نه فقط یک خروجی مرتب شده را بازگشت دادهاست، بلکه اصل آرایه را نیز درجا مرتب سازی کردهاست و ترتیب عناصر این آرایه، دیگر با آرایهی قبلی و اصلی یکی نیست.
امکان ترکیب زنجیروار متدهای کار بر روی لیستها در TypeScript
همانند LINQ، در اینجا نیز میتوان متدهای فوق را به صورت زنجیروار بر روی یک لیست فراخوانی و اجرا کرد:
با این خروجی:
در اینجا ابتدا اشخاص بالای 30 سال فیلتر شدهاند. سپس فقط خاصیت رشتهای نام آنها انتخاب شدهاست و در آخر این نامها به صورت نزولی مرتب شدهاند.
معادل متد Skip در TypeScript
متد splice که جزو متدهای توکار ES5 است، میتواند شبیه به متد Skip عمل کند. این متد آرایهای را بازگشت میدهد که حاوی عناصری است که پس از تعداد ذکر شده، در آرایهی اصلی وجود دارند:
با این خروجی:
کار واقعی متد splice، حذف عناصر باقیماندهی در آرایهاست و خروجی آن دقیقا لیست موارد حذف شدهاست. به همین جهت است که در نتیجهی فوق، اکنون آرایهی اصلی تنها دارای دو عضو باقیمانده است (و دیگر با آرایهی اصلی و ابتدایی یکی نیست).
تدارک ساختار ابتدایی این مطلب
در اینجا اینترفیسی را که بیانگر ساختار شیء شخص است، به صورت ذیل ایجاد میکنیم:
export interface Person { name: string; age: number; }
export class LinqTestsComponent { people: Person[] = [ { name: "User 4", age: 27 }, { name: "User 5", age: 42 }, { name: "User 6", age: 8 }, { name: "User 1", age: 20 }, { name: "User 2", age: 35 }, { name: "User 3", age: 78 } ]; }
همچنین سه متد ذیل را نیز برای لاگ کردن عنوان آزمایش، نمایش محتوای آرایهی اصلی و نمایش نتیجهی آزمایش، به این کلاس اضافه میکنیم:
logTitle(title: string) { console.log(`%c${title}`, "background: #222; color: #bada55"); } logOriginalArray() { console.log(`original this.people:${JSON.stringify(this.people)}`); } logResult(message: string, result: any) { console.log(`${message}:${JSON.stringify(result)}`); }
معادل متد Where در TypeScript
متد filter که جزو متدهای توکار ES5 است، میتواند معادلی برای متد Where، جهت فیلتر کردن عناصر بر اساس یک خاصیت، یا چندین خاصیت باشد:
equivalentToWhere() { const youngerThan40 = this.people.filter(person => person.age < 40); // ECMAScript 5 this.logResult("People younger than 40", youngerThan40); // Filtering on Multiple Criteria const youngsters = this.people.filter( person => person.age < 40 && person.name.toLocaleLowerCase().indexOf("user") !== -1); this.logResult("Users younger than 40", youngsters); }
People younger than 40:[ {"name":"User 4","age":27}, {"name":"User 6","age":8}, {"name":"User 1","age":20}, {"name":"User 2","age":35} ] Users younger than 40:[ {"name":"User 4","age":27}, {"name":"User 6","age":8}, {"name":"User 1","age":20}, {"name":"User 2","age":35} ]
معادل متد Any در TypeScript
متد some که جزو متدهای توکار ES5 است، میتواند معادلی برای متد Any باشد. اگر یکی از عناصر آرایه، بر اساس شرط تعیین شده یافت شود، این متد مقدار true را باز میگرداند:
equivalentToAny() { const anyUnder40 = this.people.some(person => person.age < 40); // ECMAScript 5 this.logResult("Are any people under 40?", anyUnder40); // true // Filtering on Criteria Matching any Object Properties const filterBy = "user"; const anyUsers = this.people.filter(person => Object.keys(person).some(property => { let value = (<any>person)[property]; if (typeof value === "string") { value = value.toLocaleLowerCase(); } return value.toString().indexOf(filterBy) !== -1; }) ); this.logResult("anyUsers", anyUsers); }
Are any people under 40?:true anyUsers:[ {"name":"User 4","age":27}, {"name":"User 5","age":42}, {"name":"User 6","age":8}, {"name":"User 1","age":20}, {"name":"User 2","age":35}, {"name":"User 3","age":78} ]
در مثال دوم، جستجویی بر روی تمام خواص شیء شخص انجام شدهاست. در اینجا توسط متد Object.keys، لیست خواص شیء یافت شدهاست. سپس بر روی این لیست توسط متد some، بررسی شدهاست که آیا خاصیت رشتهای وجود دارد که مساوی عبارت filterBy باشد؟ حاصل این بررسی به عنوان شرط متد filter جهت بازگشت آرایهی متناظری از اشخاص یافت شده، استفاده شدهاست.
معادل متد Contains در TypeScript
متد includes که جزو متدهای توکار ES7 است، میتواند معادلی برای متد Contains باشد و کار آن بررسی وجود عنصری در یک لیست است:
equivalentToContains() { const searchElement: Person = { name: "User 4", age: 27 }; const containsUser4 = this.people.includes(searchElement); // ECMAScript 2016 = ECMAScript 7 this.logResult("Contains searchElement", containsUser4); // false -> only compares by reference and not by value. const indexOfUser4 = this.people.indexOf(searchElement); // ECMAScript 5 this.logResult("indexOfUser4", indexOfUser4); // -1 -> only compares by reference and not by value. const stringifiedObj = JSON.stringify(searchElement); const includesUser4 = this.people.some(person => JSON.stringify(person) === stringifiedObj); this.logResult("includesUser4", includesUser4); // true -> compares by by value. }
یکی از روشهای مقایسهی بر اساس تمام مقادیر خواص یک شیء، استفاده از متد JSON.stringify است که اگر آنرا با متد some ترکیب کنیم، میتوان به نتیجهی مطلوبی رسید:
Contains searchElement:false indexOfUser4:-1 includesUser4:true
معادل متد All در TypeScript
متد every که جزو متدهای توکار ES5 است، میتواند معادلی برای متد All باشد و کار آن بررسی صحت شرط اعمالی، بر روی تک تک عناصر لیست است. اگر این بررسی با موفقیت صورت گرفت، مقدار true را بازگشت میدهد:
equivalentToAll() { const allUnder30 = this.people.every(person => person.age < 30); // ECMAScript 5 this.logResult("Are all people under 30?", allUnder30); // false }
Are all people under 30?:false
معادل متدهای First و FirstOrDefault در TypeScript
میتوان از متدهای filter و یا find بومی ES5 و ES 6 برای شبیه سازی متدهای First (یافتن اولین عنصر درخواستی در یک لیست) و FirstOrDefault استفاده کرد:
equivalentToFirstOrDefault() { const vahidOrDefault = this.people.filter(item => item.name === "Vahid")[0] || null; // ECMAScript 5 this.logResult("vahidOrDefault", vahidOrDefault); const user1OrDefault = this.people.find(item => item.name === "User 1") || null; // ECMAScript 2015 = ECMAScript 6 this.logResult("user1OrDefault", user1OrDefault); }
معادل متد FindIndex در TypeScript
متد findIndex که جزو متدهای توکار ES6 است، میتواند معادلی برای متد FindIndex در جهت یافتن ایندکس عنصری در یک لیست، بر اساس شرط درخواستی، باشد.
equivalentToFindIndex() { const index = this.people.findIndex(person => person.age === 8); // ECMAScript 2015 = ECMAScript 6 this.logResult("index of the user with age 8", index) }
index of the user with age 8:2
معادل متد Select در TypeScript
متد map که جزو متدهای توکار ES5 است، میتواند معادلی برای متد Select، برای تغییر شکل نهایی خروجی یک لیست باشد:
equivalentToSelect() { const names = this.people.map(person => person.name); // ECMAScript 5 this.logResult("Selected the names of people", names); }
Selected the names of people:["User 4","User 5","User 6","User 1","User 2","User 3"]
معادل متد Aggregate در TypeScript
متد reduce که جزو متدهای توکار ES5 است، میتواند شبیه به متد Aggregate عمل کند و لیستی از عناصر را به یک مقدار کاهش دهد:
equivalentToAggregate() { // ECMAScript 5 const aggregate = this.people.reduce((person1, person2) => { return { name: "", age: person1.age + person2.age }; }); this.logResult("Aggregate age", aggregate.age); // { age: 210 } }
Aggregate age:210
معادل متد ForEach در TypeScript
متد forEach که جزو متدهای توکار ES5 است، میتواند معادلی برای متد ForEach باشد که روشی functional برای پیمودن عناصر یک لیست است:
equivalentToForEach() { // ECMAScript 5 this.people.forEach(person => { this.logResult("person", person); }); }
person:{"name":"User 4","age":27} person:{"name":"User 5","age":42} person:{"name":"User 6","age":8} person:{"name":"User 1","age":20} person:{"name":"User 2","age":35} person:{"name":"User 3","age":78}
معادل متد OrderBy در TypeScript
متد sort که جزو متدهای توکار ES5 است، میتواند معادلی برای متد OrderBy باشد که جهت مرتب سازی عناصر یک لیست از آن استفاده میشود:
// ECMAScript 5 let orderedByAgeAscending = this.people.sort((person1, person2) => { const a = person1.age; const b = person2.age; return a > b ? 1 : -1; }); this.logResult("Ordered by age ascending", orderedByAgeAscending);
- مساوی صفر باشد، تغییری را به وجود نمیآورد.
- کمتر از صفر باشد، اولین عنصر را قبل از دومین عنصر قرار میدهد.
- بیشتر از صفر باشد، دومین عنصر را پس از اولین عنصر قرار میدهد.
منطق مقایسهی فوق را به صورت ذیل نیز میتوان خلاصه کرد:
orderedByAgeAscending = this.people.sort((person1, person2) => person1.age - person2.age); this.logResult("Ordered by age ascending", orderedByAgeAscending);
Ordered by age ascending:[ {"name":"User 6","age":8}, {"name":"User 1","age":20}, {"name":"User 4","age":27}, {"name":"User 2","age":35}, {"name":"User 5","age":42}, {"name":"User 3","age":78} ]
const orderedByName = this.people.sort((person1, person2) => { // name1.localeCompare(name2) // is case insensitive // or use toUpperCase() to ignore character casing const name1 = person1.name.toUpperCase(); const name2 = person2.name.toUpperCase(); return name1 > name2 ? 1 : -1; }) this.logResult("Ordered by name", orderedByName); this.logOriginalArray();
Ordered by name:[ {"name":"User 1","age":20}, {"name":"User 2","age":35}, {"name":"User 3","age":78}, {"name":"User 4","age":27}, {"name":"User 5","age":42}, {"name":"User 6","age":8} ] original this.people:[ {"name":"User 1","age":20}, {"name":"User 2","age":35}, {"name":"User 3","age":78}, {"name":"User 4","age":27}, {"name":"User 5","age":42}, {"name":"User 6","age":8} ]
امکان ترکیب زنجیروار متدهای کار بر روی لیستها در TypeScript
همانند LINQ، در اینجا نیز میتوان متدهای فوق را به صورت زنجیروار بر روی یک لیست فراخوانی و اجرا کرد:
chainFunctionCalls() { const namesOfPeopleOver30OrderedDesc = this.people .filter(person => person.age > 30) .map(person => person.name) .sort((name1, name2) => { // name1.localeCompare(name2) // is case insensitive // or use toUpperCase() to ignore character casing name1 = name1.toUpperCase(); name2 = name2.toUpperCase(); return name2 > name1 ? 1 : -1; }); this.logResult("the names of all people over 30 ordered by name descending", namesOfPeopleOver30OrderedDesc); }
the names of all people over 30 ordered by name descending:["User 5","User 3","User 2"]
معادل متد Skip در TypeScript
متد splice که جزو متدهای توکار ES5 است، میتواند شبیه به متد Skip عمل کند. این متد آرایهای را بازگشت میدهد که حاوی عناصری است که پس از تعداد ذکر شده، در آرایهی اصلی وجود دارند:
equivalentToSkip() { const skip2 = this.people.splice(2); // ECMAScript 5 this.logResult("skip2 -> the deleted elements", skip2); this.logOriginalArray(); }
skip2 -> the deleted elements:[ {"name":"User 3","age":78}, {"name":"User 4","age":27}, {"name":"User 5","age":42}, {"name":"User 6","age":8} ] original this.people:[ {"name":"User 1","age":20}, {"name":"User 2","age":35} ]
اگر یک پروژهی خالی ASP.NET Core Web Application را شروع کنید (با طی مراحل زیر جهت ایجاد یک پروژهی جدید):
تغییرات ساختاری ASP.NET Core 1.0، با نگارشهای قبلی ASP.NET، بسیار قابل ملاحظه هستند:
در اینجا نقش Solution همانند نگارشهای قبلی ویژوال استودیو است: ظرفی است برای ساماندهی موارد مورد نیاز جهت تشکیل یک برنامهی وب و شامل مواردی است مانند پروژهها، تنظیمات آنها و غیره. بنابراین هنوز در اینجا فایل sln. تشکیل میشود.
نقش فایل global.json
زمانیکه یک پروژهی جدید ASP.NET Core 1.0 را آغاز میکنیم، ساختار پوشههای آن به صورت زیر هستند:
در اینجا هنوز فایل sln. قابل مشاهده است. همچنین در اینجا فایل جدیدی به نام global.json نیز وجود دارد، با این محتوا:
شماره نگارش ذکر شدهی در اینجا را در قسمت قبل بررسی کردیم.
خاصیت projects در اینجا به صورت یک آرایه تعریف شدهاست و بیانگر محل واقع شدن پوشههای اصلی پروژهی جاری هستند. پوشهی src یا source را در تصویر فوق مشاهده میکنید و محلی است که سورسهای برنامه در آن قرار میگیرند. یک پوشهی test نیز در اینجا ذکر شدهاست و اگر در حین ایجاد پروژه، گزینهی ایجاد unit tests را هم انتخاب کرده باشید، این پوشهی مخصوص نیز ایجاد خواهد شد.
نکتهی مهم اینجا است، هرکدی که درون پوشههای ذکر شدهی در اینجا قرار نگیرد، قابلیت build را نخواهد داشت. به عبارتی این نسخهی از ASP.NET پوشهها را قسمتی از پروژه به حساب میآورد. در نگارشهای قبلی ASP.NET، مداخل تعریف فایلهای منتسب به هر پروژه، درون فایلی با پسوند csproj. قرار میگرفتند. معادل این فایل در اینجا اینبار پسوند xproj را دارد و اگر آنرا با یک ادیتور متنی باز کنید، فاقد تعاریف مداخل فایلهای پروژه است.
در این نگارش جدید اگر فایلی را به پوشهی src اضافه کنید یا حذف کنید، بلافاصله در solution explorer ظاهر و یا حذف خواهد شد.
یک آزمایش: به صورت معمول از طریق windows explorer به پوشهی src برنامه وارد شده و فایل پیش فرض Project_Readme.html را حذف کنید. سپس به solution explorer ویژوال استودیو دقت کنید. مشاهده خواهید کرد که این فایل، بلافاصله از آن حذف میشود. در ادامه به recycle bin ویندوز مراجعه کرده و این فایل حذف شده را restore کنید تا مجددا به پوشهی src برنامه اضافه شود. اینبار نیز افزوده شدن خودکار و بلافاصلهی این فایل را میتوان در solution explorer مشاهده کرد.
بنابراین ساختار مدیریت فایلهای این نگارش از ASP.NET در ویژوال استودیو، بسیار شبیه به ساختار مدیریت فایلهای VSCode شدهاست که آن نیز بر اساس پوشهها کار میکند و یک پوشه و تمام محتوای آنرا به صورت پیش فرض به عنوان یک پروژه میشناسد. به همین جهت دیگر فایل csproj ایی در اینجا وجود ندارد و file system همان project system است.
یک نکته: در اینجا مسیرهای مطلق را نیز میتوان ذکر کرد:
اما در مورد هر مسیری که ذکر میشود، NET Core. باید بتواند یک سطح پایینتر از پوشهی ذکر شده، فایل مهم project.json را پیدا کند؛ در غیراینصورت از آن صرفنظر خواهد شد. برای مثال برای مسیر نسبی src، مسیر src\MyProjectName\project.json را جستجو میکند و برای مسیر مطلق ذکر شده، این مسیر را c:\\sources\\Configuration\\src\\SomeName\\project.json
کامپایل خودکار پروژه در ASP.NET Core 1.0
علاوه بر تشخیص خودکار کم و زیاد شدن فایلهای سیستمی پروژه، بدون نیاز به Add new item کردن آنها در ویژوال استودیو، اگر سورسهای برنامه را نیز تغییر دهید، فایل سورس جدیدی را اضافه کنید و یا فایل سورس موجودی را حذف کنید، کل پروژه به صورت خودکار کامپایل میشود و نیازی نیست اینکار را به صورت دستی انجام دهید.
یک آزمایش: برنامه را از طریق منوی debug و گزینهی start without debugging اجرا کنید. اگر برنامه را در حالت معمول debug->start debugging اجرا کنید، حالت کامپایل خودکار را مشاهده نخواهید کرد. در اینجا (پس از start without debugging) یک چنین خروجی را مشاهده خواهید کرد:
این خروجی حاصل اجرای کدهای درون فایل Startup.cs برنامه است:
اکنون در همین حال که برنامه در حال اجرا است و هنوز IIS Express خاتمه نیافته است، از طریق windows explorer، به پوشهی src برنامه وارد شده و فایل Startup.cs را با notepad باز کنید. هدف این است که این فایل را در خارج از ویژوال استودیو ویرایش کنیم. اینبار سطر await دار را در notepad به نحو ذیل ویرایش کنید:
پس از آن اگر مرورگر را refresh کنید، بلافاصله خروجی جدید فوق را مشاهده خواهید کرد که بیانگر کامپایل خودکار پروژه در صورت تغییر فایلهای آن است.
این مساله قابلیت استفادهی از ASP.NET Core را در سایر ادیتورهای موجود، مانند VSCode سهولت میبخشد.
نقش فایل project.json
فایل جدید project.json مهمترین فایل تنظیمات یک پروژهی ASP.NET Core است و مهمترین قسمت آن، قسمت وابستگیهای آن است:
همانطور که در قسمت قبل نیز عنوان شد، در این نگارش از دات نت، تمام وابستگیهای پروژه از طریق نیوگت تامین میشوند و دیگر خبری از یک دات نت «بزرگ» که شامل تمام اجزای این مجموعهاست نیست. این مساله توزیع برنامه را سادهتر کرده و همچنین امکان به روز رسانی سریعتر این اجزا را توسط تیمهای مرتبط فراهم میکند؛ بدون اینکه نیازی باشد تا منتظر یک توزیع «بزرگ» دیگر ماند.
در نگارشهای قبلی ASP.NET، فایلی XML ایی به نام packages.config حاوی تعاریف مداخل بستههای نیوگت برنامه بود. این فایل در اینجا جزئی از محتوای فایل project.json در قسمت dependencies آن است.
با قسمت وابستگیهای این فایل، به دو طریق میتوان کار کرد:
الف) ویرایش مستقیم این فایل که به همراه intellisense نیز هست. با افزودن مداخل جدید به این فایل و ذخیره کردن آن، بلافاصله کار restore و دریافت و نصب آنها آغاز میشود:
ب) از طریق NuGet package manager
روش دیگر کار با وابستگیها، کلیک راست بر روی گره references و انتخاب گزینهی manage nuget packages است:
برای نمونه جهت نصب ASP.NET MVC 6 این مراحل باید طی شوند:
ابتدا برگهی browse را انتخاب کنید و سپس تیک مربوط به include prerelease را نیز انتخاب نمائید.
البته بستهی اصلی MVC در اینجا Microsoft.AspNetCore.Mvc نام دارد و نه MVC6.
اینبار بستههایی که restore میشوند، در مسیر اشتراکی C:\Users\user_name\.nuget\packages ذخیره خواهند شد.
یک نکتهی مهم:
قرار هست در نگارشهای پس از RTM، فایلهای project.json و xproj را جهت سازگاری با MSBuild، اندکی تغییر دهند (که این تغییرات به صورت خودکار توسط VS.NET انجام میشود). اطلاعات بیشتر
انتخاب فریم ورکهای مختلف در فایل project.json
در قسمت قبل عنوان شد که ASP.NET Core را میتوان هم برفراز NET Core. چندسکویی اجرا کرد و هم NET 4.6. مختص به ویندوز. این انتخابها در قسمت frameworks فایل project.json انجام میشوند:
در اینجا، netcoreapp1.0 به معنای برنامهای است که برفراز NET Core. اجرا میشود. نام پیشین آن dnxcore50 بود (اگر مقالات قدیمیتر پیش از RTM را مطالعه کنید).
در اینجا اگر علاقمند بودید که از دات نت کامل مخصوص ویندوز نیز استفاده کنید، میتوانید آنرا در لیست فریم ورکها اضافه نمائید (در این مثال، دات نت کامل 4.5.2 نیز ذکر شدهاست):
لیست کامل این اسامی را در مستندات NET Starndard میتوانید مطالعه کنید و خلاصهی آن به این صورت است:
- “netcoreapp1.0” برای معرفی و استفادهی از NET Core 1.0. بکار میرود.
- جهت معرفی فریم ورکهای کامل و ویندوزی دات نت، اسامی “net45”, “net451”, “net452”, “net46”, “net461” مجاز هستند.
- “portable-net45+win8” برای معرفی پروفایلهای PCL یا portable class libraries بکار میرود.
- “dotnet5.6”, “dnxcore50” برای معرفی نگارشهای پیش نمایش NET Core.، پیش از ارائهی نگارش RTM استفاده میشوند.
- “netstandard1.2”, “netstandard1.5” کار معرفی برنامههای NET Standard Platform. را انجام میدهند.
بر این مبنا، dotnet5.6 ذکر شدهی در قسمت تنظیمات نگارش RTM، به این معنا است که قادر به استفادهی از بستههای نیوگت و کتابخانههای تولید شدهی با نگارشهای RC نیز خواهید بود (هرچند برنامه از netcoreapp1.0 استفاده میکند).
یک مثال: قسمت فریم ورکهای فایل project.json را به نحو ذیل جهت معرفی دات نت 4.6.1 تغییر دهید:
لیست وابستگیهای خاص این فریم ورک در خاصیت dependencies آن قابل ذکر است.
در این حالت پس از ذخیرهی فایل و شروع خودکار بازیابی وابستگیها، با پیام خطای Package Microsoft.NETCore.App 1.0.0 is not compatible with net461 متوقف خواهید شد.
برای رفع این مشکل باید وابستگی Microsoft.NETCore.App را حذف کنید، چون با net461 سازگاری ندارد
فایل project.lock.json چیست؟
ذیل فایل project.json، فایل دیگری به نام project.lock.json نیز وجود دارد. اگر به محتوای آن دقت کنید، این فایل حاوی لیست دقیق بستههای نیوگت مورد استفادهی توسط برنامه است و الزاما با آنچیزی که در فایل project.json قید شده، یکی نیست. از این جهت که در فایل project.json، قید میشود netcoreapp1.0؛ ولی این netcoreapp1.0 دقیقا شامل چه بستههایی است؟ لیست کامل آنها را در این فایل میتوانید مشاهده کنید.
در ابتدای این فایل یک خاصیت locked نیز وجود دارد که مقدار پیش فرض آن false است. اگر به true تنظیم شود، در حین restore وابستگیهای برنامه، تنها از نگارشهای ذکر شدهی در این فایل استفاده میشود. از این جهت که در فایل project.json میتوان شماره نگارشها را با * نیز مشخص کرد؛ مثلا *.1.0.0
پوشهی جدید wwwroot و گره dependencies
یکی از پوشههای جدیدی که در ساختار پروژهی ASP.NET Core معرفی شدهاست، wwwroot نام دارد:
از دیدگاه هاستینگ برنامه، این پوشه، پوشهای است که در معرض دید عموم قرار میگیرد (وب روت). برای مثال فایلهای ایستای اسکریپت، CSS، تصاویر و غیره باید در این پوشه قرار گیرند تا توسط دنیای خارج قابل دسترسی و استفاده شوند. بنابراین سورس کدهای برنامه خارج از این پوشه قرار میگیرند.
گره dependencies که ذیل پوشهی wwwroot قرار گرفتهاست، جهت مدیریت این وابستگیهای سمت کلاینت برنامه است. در اینجا میتوان از NPM و یا Bower برای دریافت و به روز رسانی وابستگیهای اسکریپتی و شیوهنامههای برنامه کمک گرفت (علاوه بر نیوگت که بهتر است صرفا جهت دریافت وابستگیهای دات نتی استفاده شود).
یک مثال: فایل جدیدی را به نام bower.json به پروژهی جاری با این محتوا اضافه کنید:
این نامها استاندارد هستند. برای مثال اگر قصد استفادهی از npm مربوط به node.js را داشته باشید، نام این فایل packag.json است (با ساختار خاص خودش) و هر دوی اینها را نیز میتوانید با هم اضافه کنید و از این لحاظ محدودیتی وجود ندارد.
پس از اضافه شدن فایل bower.json، بلافاصله کار restore بستهها از اینترنت شروع میشود:
و یا با کلیک راست بر روی گره dependencies، گزینهی restore packages نیز وجود دارد.
فایلهای نهایی دریافت شده را در پوشهی bower_components خارج از wwwroot میتوانید مشاهده کنید.
در مورد نحوهی توزیع و دسترسی به فایلهای استاتیک یک برنامهی ASP.NET Core 1.0، نکات خاصی وجود دارند که در قسمتهای بعد، بررسی خواهند شد.
یک نکته: اگر خواستید نام پوشهی wwwroot را تغییر دهید، فایل جدیدی را به نام hosting.json با این محتوا به پروژه اضافه کنید:
در اینجا AppWebRoot نام دلخواه پوشهی جدیدی است که نیاز است به ریشهی پروژه اضافه نمائید تا بجای wwwroot پیش فرض استفاده شود.
نقطهی آغازین برنامه کجاست؟
اگر به فایل project.json دقت کنید، چنین تنظیمی در آن موجود است:
true بودن مقدار تولید entry point به استفادهی از فایلی به نام Program.cs بر میگردد؛ با این محتوا:
به این ترتیب، یک برنامهی ASP.NET Core، دقیقا همانند سایر برنامههای NET Core. رفتار میکند و در اساس یک برنامهی کنسول است.
این چند سطر، قسمتی از سورس کد ASP.NET Core 1.0 هستند. به این معنا که اگر مقدار خاصیت emitEntryPoint مساوی true بود، با این برنامه به شکل یک برنامهی کنسول رفتار کن و در غیر اینصورت یک Dynamically Linked Library خواهد بود.
در فایل Program.cs تنظیماتی را مشاهده میکنید، در مورد راه اندازی Kestler که وب سرور بسیار سریع و چندسکویی کار با برنامههای ASP.NET Core 1.0 است و قسمت مهم دیگر آن به استفادهی از کلاس Startup بر میگردد (()<UseStartup<Startup). این کلاس را در فایل جدید Startup.cs میتوانید ملاحظه کنید که کار تنظیمات آغازین برنامه را انجام میدهد. اگر پیشتر با OWIN، در نگارشهای قبلی ASP.NET کار کرده باشید، قسمتی از این فایل برای شما آشنا است:
در اینجا امکان دسترسی به تنظیمات برنامه، معرفی سرویسها، middlewareها و غیره وجود دارند که هرکدام، در قسمتهای آتی به تفصیل بررسی خواهند شد.
نقش فایل launchsetting.json
محتویات پیش فرض این فایل برای قالب empty پروژههای ASP.NET Core 1.0 به صورت ذیل است:
همانطور که مشاهده میکنید، در اینجا تنظیمات IIS Express قابل تغییر هستند. برای مثال port پیش فرض برنامه 7742 تنظیم شدهاست.
پروفایلهایی که در اینجا ذکر شدهاند، در تنظیمات پروژه نیز قابل مشاهده هستند: (کلیک راست بر روی پروژه و مشاهدهی properties آن و یا دوبار کلیک بر روی گره properties)
به علاوه امکان انتخاب این پروفایلها در زمان آغاز برنامه نیز وجود دارند:
نکتهی مهم تمام این موارد به قسمت environment variable قابل مشاهدهی در تصاویر فوق بر میگردد. این متغیر محیطی میتواند سه مقدار Development ، Staging و Production را داشته باشد و بر اساس این متغیر و مقدار آن، میتوان پروفایل جدیدی را تشکیل داد. زمانیکه برنامه بر اساس پروفایل خاصی بارگذاری میشود، اینکه چه متغیر محیطی انتخاب شدهاست، در کلاس Startup قابل استخراج و بررسی بوده و بر این اساس میتوان اقدامات خاصی را انجام داد. برای مثال تنظیمات خاصی را بارگذاری کرد و یا صفحات ویژهای را فعال و غیرفعال کرد (این موارد را در قسمتهای بعدی مرور میکنیم).
همچنین در اینجا به ازای هر پروفایل مختلف میتوان Url آغازین یا launch url و پورت آنرا مجزا درنظر گرفت و یا از وب سرور دیگری استفاده کرد.
.NET Core -> ASP.NET Core Web Application (.NET Core) -> Select `Empty` Template
در اینجا نقش Solution همانند نگارشهای قبلی ویژوال استودیو است: ظرفی است برای ساماندهی موارد مورد نیاز جهت تشکیل یک برنامهی وب و شامل مواردی است مانند پروژهها، تنظیمات آنها و غیره. بنابراین هنوز در اینجا فایل sln. تشکیل میشود.
نقش فایل global.json
زمانیکه یک پروژهی جدید ASP.NET Core 1.0 را آغاز میکنیم، ساختار پوشههای آن به صورت زیر هستند:
در اینجا هنوز فایل sln. قابل مشاهده است. همچنین در اینجا فایل جدیدی به نام global.json نیز وجود دارد، با این محتوا:
{ "projects": [ "src", "test" ], "sdk": { "version": "1.0.0-preview2-003121" } }
خاصیت projects در اینجا به صورت یک آرایه تعریف شدهاست و بیانگر محل واقع شدن پوشههای اصلی پروژهی جاری هستند. پوشهی src یا source را در تصویر فوق مشاهده میکنید و محلی است که سورسهای برنامه در آن قرار میگیرند. یک پوشهی test نیز در اینجا ذکر شدهاست و اگر در حین ایجاد پروژه، گزینهی ایجاد unit tests را هم انتخاب کرده باشید، این پوشهی مخصوص نیز ایجاد خواهد شد.
نکتهی مهم اینجا است، هرکدی که درون پوشههای ذکر شدهی در اینجا قرار نگیرد، قابلیت build را نخواهد داشت. به عبارتی این نسخهی از ASP.NET پوشهها را قسمتی از پروژه به حساب میآورد. در نگارشهای قبلی ASP.NET، مداخل تعریف فایلهای منتسب به هر پروژه، درون فایلی با پسوند csproj. قرار میگرفتند. معادل این فایل در اینجا اینبار پسوند xproj را دارد و اگر آنرا با یک ادیتور متنی باز کنید، فاقد تعاریف مداخل فایلهای پروژه است.
در این نگارش جدید اگر فایلی را به پوشهی src اضافه کنید یا حذف کنید، بلافاصله در solution explorer ظاهر و یا حذف خواهد شد.
یک آزمایش: به صورت معمول از طریق windows explorer به پوشهی src برنامه وارد شده و فایل پیش فرض Project_Readme.html را حذف کنید. سپس به solution explorer ویژوال استودیو دقت کنید. مشاهده خواهید کرد که این فایل، بلافاصله از آن حذف میشود. در ادامه به recycle bin ویندوز مراجعه کرده و این فایل حذف شده را restore کنید تا مجددا به پوشهی src برنامه اضافه شود. اینبار نیز افزوده شدن خودکار و بلافاصلهی این فایل را میتوان در solution explorer مشاهده کرد.
بنابراین ساختار مدیریت فایلهای این نگارش از ASP.NET در ویژوال استودیو، بسیار شبیه به ساختار مدیریت فایلهای VSCode شدهاست که آن نیز بر اساس پوشهها کار میکند و یک پوشه و تمام محتوای آنرا به صورت پیش فرض به عنوان یک پروژه میشناسد. به همین جهت دیگر فایل csproj ایی در اینجا وجود ندارد و file system همان project system است.
یک نکته: در اینجا مسیرهای مطلق را نیز میتوان ذکر کرد:
"projects": [ "src", "test", "c:\\sources\\Configuration\\src" ],
کامپایل خودکار پروژه در ASP.NET Core 1.0
علاوه بر تشخیص خودکار کم و زیاد شدن فایلهای سیستمی پروژه، بدون نیاز به Add new item کردن آنها در ویژوال استودیو، اگر سورسهای برنامه را نیز تغییر دهید، فایل سورس جدیدی را اضافه کنید و یا فایل سورس موجودی را حذف کنید، کل پروژه به صورت خودکار کامپایل میشود و نیازی نیست اینکار را به صورت دستی انجام دهید.
یک آزمایش: برنامه را از طریق منوی debug و گزینهی start without debugging اجرا کنید. اگر برنامه را در حالت معمول debug->start debugging اجرا کنید، حالت کامپایل خودکار را مشاهده نخواهید کرد. در اینجا (پس از start without debugging) یک چنین خروجی را مشاهده خواهید کرد:
این خروجی حاصل اجرای کدهای درون فایل Startup.cs برنامه است:
app.Run(async (context) => { await context.Response.WriteAsync("Hello World!"); });
await context.Response.WriteAsync("Hello DNT!");
این مساله قابلیت استفادهی از ASP.NET Core را در سایر ادیتورهای موجود، مانند VSCode سهولت میبخشد.
نقش فایل project.json
فایل جدید project.json مهمترین فایل تنظیمات یک پروژهی ASP.NET Core است و مهمترین قسمت آن، قسمت وابستگیهای آن است:
"dependencies": { "Microsoft.NETCore.App": { "version": "1.0.0", "type": "platform" }, "Microsoft.AspNetCore.Diagnostics": "1.0.0", "Microsoft.AspNetCore.Server.IISIntegration": "1.0.0", "Microsoft.AspNetCore.Server.Kestrel": "1.0.0", "Microsoft.Extensions.Logging.Console": "1.0.0" },
در نگارشهای قبلی ASP.NET، فایلی XML ایی به نام packages.config حاوی تعاریف مداخل بستههای نیوگت برنامه بود. این فایل در اینجا جزئی از محتوای فایل project.json در قسمت dependencies آن است.
با قسمت وابستگیهای این فایل، به دو طریق میتوان کار کرد:
الف) ویرایش مستقیم این فایل که به همراه intellisense نیز هست. با افزودن مداخل جدید به این فایل و ذخیره کردن آن، بلافاصله کار restore و دریافت و نصب آنها آغاز میشود:
ب) از طریق NuGet package manager
روش دیگر کار با وابستگیها، کلیک راست بر روی گره references و انتخاب گزینهی manage nuget packages است:
برای نمونه جهت نصب ASP.NET MVC 6 این مراحل باید طی شوند:
ابتدا برگهی browse را انتخاب کنید و سپس تیک مربوط به include prerelease را نیز انتخاب نمائید.
البته بستهی اصلی MVC در اینجا Microsoft.AspNetCore.Mvc نام دارد و نه MVC6.
اینبار بستههایی که restore میشوند، در مسیر اشتراکی C:\Users\user_name\.nuget\packages ذخیره خواهند شد.
یک نکتهی مهم:
قرار هست در نگارشهای پس از RTM، فایلهای project.json و xproj را جهت سازگاری با MSBuild، اندکی تغییر دهند (که این تغییرات به صورت خودکار توسط VS.NET انجام میشود). اطلاعات بیشتر
انتخاب فریم ورکهای مختلف در فایل project.json
در قسمت قبل عنوان شد که ASP.NET Core را میتوان هم برفراز NET Core. چندسکویی اجرا کرد و هم NET 4.6. مختص به ویندوز. این انتخابها در قسمت frameworks فایل project.json انجام میشوند:
"frameworks": { "netcoreapp1.0": { "imports": [ "dotnet5.6", "portable-net45+win8" ] } },
در اینجا اگر علاقمند بودید که از دات نت کامل مخصوص ویندوز نیز استفاده کنید، میتوانید آنرا در لیست فریم ورکها اضافه نمائید (در این مثال، دات نت کامل 4.5.2 نیز ذکر شدهاست):
"frameworks": { "netcoreapp1.0": { }, "net452": { } }
- “netcoreapp1.0” برای معرفی و استفادهی از NET Core 1.0. بکار میرود.
- جهت معرفی فریم ورکهای کامل و ویندوزی دات نت، اسامی “net45”, “net451”, “net452”, “net46”, “net461” مجاز هستند.
- “portable-net45+win8” برای معرفی پروفایلهای PCL یا portable class libraries بکار میرود.
- “dotnet5.6”, “dnxcore50” برای معرفی نگارشهای پیش نمایش NET Core.، پیش از ارائهی نگارش RTM استفاده میشوند.
- “netstandard1.2”, “netstandard1.5” کار معرفی برنامههای NET Standard Platform. را انجام میدهند.
بر این مبنا، dotnet5.6 ذکر شدهی در قسمت تنظیمات نگارش RTM، به این معنا است که قادر به استفادهی از بستههای نیوگت و کتابخانههای تولید شدهی با نگارشهای RC نیز خواهید بود (هرچند برنامه از netcoreapp1.0 استفاده میکند).
یک مثال: قسمت فریم ورکهای فایل project.json را به نحو ذیل جهت معرفی دات نت 4.6.1 تغییر دهید:
"frameworks": { "netcoreapp1.0": { "imports": [ "dotnet5.6", "portable-net45+win8" ] }, "net461": { "imports": [ "portable-net45+win8" ], "dependencies": { } } },
در این حالت پس از ذخیرهی فایل و شروع خودکار بازیابی وابستگیها، با پیام خطای Package Microsoft.NETCore.App 1.0.0 is not compatible with net461 متوقف خواهید شد.
برای رفع این مشکل باید وابستگی Microsoft.NETCore.App را حذف کنید، چون با net461 سازگاری ندارد
"dependencies": { //"Microsoft.NETCore.App": { // "version": "1.0.0", // "type": "platform" //},
فریم ورک دوم استفاده شده نیز در اینجا قابل مشاهده است.
فایل project.lock.json چیست؟
ذیل فایل project.json، فایل دیگری به نام project.lock.json نیز وجود دارد. اگر به محتوای آن دقت کنید، این فایل حاوی لیست دقیق بستههای نیوگت مورد استفادهی توسط برنامه است و الزاما با آنچیزی که در فایل project.json قید شده، یکی نیست. از این جهت که در فایل project.json، قید میشود netcoreapp1.0؛ ولی این netcoreapp1.0 دقیقا شامل چه بستههایی است؟ لیست کامل آنها را در این فایل میتوانید مشاهده کنید.
در ابتدای این فایل یک خاصیت locked نیز وجود دارد که مقدار پیش فرض آن false است. اگر به true تنظیم شود، در حین restore وابستگیهای برنامه، تنها از نگارشهای ذکر شدهی در این فایل استفاده میشود. از این جهت که در فایل project.json میتوان شماره نگارشها را با * نیز مشخص کرد؛ مثلا *.1.0.0
پوشهی جدید wwwroot و گره dependencies
یکی از پوشههای جدیدی که در ساختار پروژهی ASP.NET Core معرفی شدهاست، wwwroot نام دارد:
از دیدگاه هاستینگ برنامه، این پوشه، پوشهای است که در معرض دید عموم قرار میگیرد (وب روت). برای مثال فایلهای ایستای اسکریپت، CSS، تصاویر و غیره باید در این پوشه قرار گیرند تا توسط دنیای خارج قابل دسترسی و استفاده شوند. بنابراین سورس کدهای برنامه خارج از این پوشه قرار میگیرند.
گره dependencies که ذیل پوشهی wwwroot قرار گرفتهاست، جهت مدیریت این وابستگیهای سمت کلاینت برنامه است. در اینجا میتوان از NPM و یا Bower برای دریافت و به روز رسانی وابستگیهای اسکریپتی و شیوهنامههای برنامه کمک گرفت (علاوه بر نیوگت که بهتر است صرفا جهت دریافت وابستگیهای دات نتی استفاده شود).
یک مثال: فایل جدیدی را به نام bower.json به پروژهی جاری با این محتوا اضافه کنید:
{ "name": "asp.net", "private": true, "dependencies": { "bootstrap": "3.3.6", "jquery": "2.2.0", "jquery-validation": "1.14.0", "jquery-validation-unobtrusive": "3.2.6" } }
پس از اضافه شدن فایل bower.json، بلافاصله کار restore بستهها از اینترنت شروع میشود:
و یا با کلیک راست بر روی گره dependencies، گزینهی restore packages نیز وجود دارد.
فایلهای نهایی دریافت شده را در پوشهی bower_components خارج از wwwroot میتوانید مشاهده کنید.
در مورد نحوهی توزیع و دسترسی به فایلهای استاتیک یک برنامهی ASP.NET Core 1.0، نکات خاصی وجود دارند که در قسمتهای بعد، بررسی خواهند شد.
یک نکته: اگر خواستید نام پوشهی wwwroot را تغییر دهید، فایل جدیدی را به نام hosting.json با این محتوا به پروژه اضافه کنید:
{ "webroot":"AppWebRoot" }
نقطهی آغازین برنامه کجاست؟
اگر به فایل project.json دقت کنید، چنین تنظیمی در آن موجود است:
"buildOptions": { "emitEntryPoint": true, "preserveCompilationContext": true },
public static void Main(string[] args) { var host = new WebHostBuilder() .UseKestrel() .UseContentRoot(Directory.GetCurrentDirectory()) .UseIISIntegration() .UseStartup<Startup>() .Build(); host.Run(); }
var outputKind = compilerOptions.EmitEntryPoint.GetValueOrDefault() ? OutputKind.ConsoleApplication : OutputKind.DynamicallyLinkedLibrary;
در فایل Program.cs تنظیماتی را مشاهده میکنید، در مورد راه اندازی Kestler که وب سرور بسیار سریع و چندسکویی کار با برنامههای ASP.NET Core 1.0 است و قسمت مهم دیگر آن به استفادهی از کلاس Startup بر میگردد (()<UseStartup<Startup). این کلاس را در فایل جدید Startup.cs میتوانید ملاحظه کنید که کار تنظیمات آغازین برنامه را انجام میدهد. اگر پیشتر با OWIN، در نگارشهای قبلی ASP.NET کار کرده باشید، قسمتی از این فایل برای شما آشنا است:
public class Startup { public void ConfigureServices(IServiceCollection services) { } public void Configure(IApplicationBuilder app) { app.Run(async (context) => { await context.Response.WriteAsync("Hello World!"); }); } }
نقش فایل launchsetting.json
محتویات پیش فرض این فایل برای قالب empty پروژههای ASP.NET Core 1.0 به صورت ذیل است:
{ "iisSettings": { "windowsAuthentication": false, "anonymousAuthentication": true, "iisExpress": { "applicationUrl": "http://localhost:7742/", "sslPort": 0 } }, "profiles": { "IIS Express": { "commandName": "IISExpress", "launchBrowser": true, "environmentVariables": { "ASPNETCORE_ENVIRONMENT": "Development" } }, "Core1RtmEmptyTest": { "commandName": "Project", "launchBrowser": true, "launchUrl": "http://localhost:5000", "environmentVariables": { "ASPNETCORE_ENVIRONMENT": "Development" } } } }
پروفایلهایی که در اینجا ذکر شدهاند، در تنظیمات پروژه نیز قابل مشاهده هستند: (کلیک راست بر روی پروژه و مشاهدهی properties آن و یا دوبار کلیک بر روی گره properties)
به علاوه امکان انتخاب این پروفایلها در زمان آغاز برنامه نیز وجود دارند:
نکتهی مهم تمام این موارد به قسمت environment variable قابل مشاهدهی در تصاویر فوق بر میگردد. این متغیر محیطی میتواند سه مقدار Development ، Staging و Production را داشته باشد و بر اساس این متغیر و مقدار آن، میتوان پروفایل جدیدی را تشکیل داد. زمانیکه برنامه بر اساس پروفایل خاصی بارگذاری میشود، اینکه چه متغیر محیطی انتخاب شدهاست، در کلاس Startup قابل استخراج و بررسی بوده و بر این اساس میتوان اقدامات خاصی را انجام داد. برای مثال تنظیمات خاصی را بارگذاری کرد و یا صفحات ویژهای را فعال و غیرفعال کرد (این موارد را در قسمتهای بعدی مرور میکنیم).
همچنین در اینجا به ازای هر پروفایل مختلف میتوان Url آغازین یا launch url و پورت آنرا مجزا درنظر گرفت و یا از وب سرور دیگری استفاده کرد.
اشتراکها
برنامههای تیم دات نت برای سال 2015
نظرات مطالب
ساخت بستههای نیوگت مخصوص NET Core.
به روز رسانی
با حذف فایل project.json در VS 2017، اکنون با کلیک راست بر روی گروه نام پروژه (فایل csproj)، گزینهی Edit آن ظاهر شده و مداخل ذکر شدهی در مطلب فوق، چنین تعاریفی را پیدا میکنند:
برای تولید مستندات و کنترل اخطارهای آن:
و اگر خواستید دات نت 4.6 یا فریم ورکهای دیگر را نیز پشتیبانی کنید، ItemGroupهای آنها به این صورت اضافه میشوند:
با حذف فایل project.json در VS 2017، اکنون با کلیک راست بر روی گروه نام پروژه (فایل csproj)، گزینهی Edit آن ظاهر شده و مداخل ذکر شدهی در مطلب فوق، چنین تعاریفی را پیدا میکنند:
<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <Description>desc.</Description> <VersionPrefix>1.0.0</VersionPrefix> <Authors>name</Authors> <TargetFramework>netstandard1.6</TargetFramework> <GenerateDocumentationFile>true</GenerateDocumentationFile> <AssemblyName>name</AssemblyName> <PackageId>name</PackageId> <PackageTags>MVC;aspnetcore</PackageTags> <PackageProjectUrl>https://github.com/proj</PackageProjectUrl> <PackageLicenseUrl>https://github.com/proj/blob/master/LICENSE.md</PackageLicenseUrl> <PackageTargetFallback>$(PackageTargetFallback);dnxcore50</PackageTargetFallback> <GenerateAssemblyConfigurationAttribute>false</GenerateAssemblyConfigurationAttribute> <GenerateAssemblyCompanyAttribute>false</GenerateAssemblyCompanyAttribute> <GenerateAssemblyProductAttribute>false</GenerateAssemblyProductAttribute> </PropertyGroup> <ItemGroup> <PackageReference Include="Microsoft.AspNetCore.Mvc.Core" Version="1.1.2" /> </ItemGroup> <PropertyGroup Condition=" '$(Configuration)' == 'Release' "> <PlatformTarget>anycpu</PlatformTarget> </PropertyGroup> <Target Name="PostcompileScript" AfterTargets="Build"> <Exec Command="dotnet pack --no-build --configuration $(Configuration)" /> </Target> </Project>
<PropertyGroup> <NoWarn>$(NoWarn);1591</NoWarn> <GenerateDocumentationFile>true</GenerateDocumentationFile> </PropertyGroup>
<PropertyGroup> <TargetFrameworks>net46;netstandard1.3</TargetFrameworks> </PropertyGroup> <ItemGroup Condition=" '$(TargetFramework)' == 'net46' "> <Reference Include="System" /> <Reference Include="System.Core" /> </ItemGroup> <ItemGroup Condition=" '$(TargetFramework)' == 'netstandard1.3' "> <PackageReference Include="System.Data.Common" Version="4.3.0" /> </ItemGroup>
پیشتر مطلب «Count یا Any » را در این سایت مطالعه کردهاید که در پایان آن این نتیجه گیری صورت گرفتهاست:
«از این پس حین استفاده از انواع و اقسام لیستها، آرایهها، IEnumerableها و امثال آنها، جهت بررسی خالی بودن یا نبودن آنها تنها از متد Any فراهم شده توسط LINQ استفاده نمائید.»
اکنون پس از سالها، قصد داریم صحت این مساله را با NET 5.0. بررسی کنیم که آیا هنوز هم متد Any، بهترین متد بررسی خالی بودن مجموعهها و آرایههای NET 5.0. است یا خیر؟
نحوهی بررسی کارآیی روشهای مختلف خالی بودن مجموعهها و آرایهها در C# 9.0
در ابتدا یک لیست، یک Enumerable و یک آرایه را به صورت زیر مقدار دهی میکنیم و هر سهی اینها میتوانند نال هم باشند:
اکنون که C# 9.0 در اختیار ما است به همراه pattern matching و همچنین Null Conditional Operator و غیره، میتوان روشهای زیر را برای بررسی خالی بودن این مجموعهها و آرایهها بکار گرفت:
1- استفاده از Null coalescing برای بررسی نال بودن مجموعه و سپس استفاده از متد Any برای بررسی خالی بودن آن:
2- استفاده از pattern matching برای بررسی نال بودن مجموعه و سپس استفاده از متد Any برای بررسی خالی بودن آن:
3- استفاده از روش سنتی مقایسهی مستقیم با null و سپس استفاده از متد Any برای بررسی خالی بودن آن:
4- استفاده از Null Conditional Operator برای بررسی نال بودن و سپس استفاده از متد Any برای بررسی خالی بودن آن:
5- استفاده از pattern matching برای بررسی مقدار خاصیت Count یک لیست یا آرایه. البته Enumerableها به همراه این خاصیت نیستند و یا باید آنها را به لیست و یا آرایه تبدیل کرد و یا میتوان متد ()Count آنها را فراخوانی نمود:
6- استفاده از Null Conditional Operator برای بررسی نال بودن و سپس استفاده از مقدار خاصیت Count لیست، برای بررسی خالی بودن آن:
7- استفاده از روش سنتی مقایسهی مستقیم با null و سپس استفاده از مقدار خاصیت Count لیست، برای بررسی خالی بودن آن:
کدهای کامل این بررسی به صورت زیر هستند: AnyCountBenchmark.zip
ابتدا ارجاعی به BenchmarkDotNet به برنامه اضافه شدهاست:
و سپس کدهای زیر، بررسی کارآیی روشهای مختلف تعیین خالی بودن مجموعهها را انجام میدهند:
به همراه سناریوهای مختلف زیر:
یکبار اجرای آن، نتیجهی زیر را به همراه داشت:
نتایج حاصل:
- بررسی خالی بودن آرایهها، بسیار سریعتر از بررسی خالی بودن لیستها و این مورد نیز سریعتر از Enumerableها است.
- اگر از آرایهها و یا لیستها استفاده میکنید، بررسی خاصیت Length و یا خاصیت Count آنها، بسیار سریعتر از بکارگیری متد Any بر روی آنها است.
- اگر از Enumerableها استفاده میکنید، استفاده از متد Any بر روی آنها، بسیار سریعتر از بکارگیری متد ()Count و یا تبدیل آنها به لیست و سپس بررسی خاصیت Count آنها است.
- بررسی نال بودن با pattern matching یا همان is null، نسبت به روشی سنتی استفادهی از null ==، سریعتر است. علت آنرا در مطلب «روش ترجیح داده شدهی مقایسه مقادیر اشیاء با null از زمان C# 7.0 به بعد» میتوانید مطالعه کنید.
بنابراین برای بررسی خالی بودن آرایهها و لیستها، بهتر است از خاصیت Length و یا Count آنها استفاده کرد و برای Enumerableها از متد ()Any.
«از این پس حین استفاده از انواع و اقسام لیستها، آرایهها، IEnumerableها و امثال آنها، جهت بررسی خالی بودن یا نبودن آنها تنها از متد Any فراهم شده توسط LINQ استفاده نمائید.»
اکنون پس از سالها، قصد داریم صحت این مساله را با NET 5.0. بررسی کنیم که آیا هنوز هم متد Any، بهترین متد بررسی خالی بودن مجموعهها و آرایههای NET 5.0. است یا خیر؟
نحوهی بررسی کارآیی روشهای مختلف خالی بودن مجموعهها و آرایهها در C# 9.0
در ابتدا یک لیست، یک Enumerable و یک آرایه را به صورت زیر مقدار دهی میکنیم و هر سهی اینها میتوانند نال هم باشند:
private IList<int>? _idsList; private IEnumerable<int>? _idsEnumerable; private int[]? _idsArray; [GlobalSetup] public void Setup() { _idsEnumerable = Enumerable.Range(0, 10000); _idsList = _idsEnumerable.ToList(); _idsArray = _idsEnumerable.ToArray(); }
اکنون که C# 9.0 در اختیار ما است به همراه pattern matching و همچنین Null Conditional Operator و غیره، میتوان روشهای زیر را برای بررسی خالی بودن این مجموعهها و آرایهها بکار گرفت:
1- استفاده از Null coalescing برای بررسی نال بودن مجموعه و سپس استفاده از متد Any برای بررسی خالی بودن آن:
var list = _idsList ?? new List<int>(); if (list.Any() is false) { }
2- استفاده از pattern matching برای بررسی نال بودن مجموعه و سپس استفاده از متد Any برای بررسی خالی بودن آن:
if (_idsList is null || _idsList.Any() is false) { }
3- استفاده از روش سنتی مقایسهی مستقیم با null و سپس استفاده از متد Any برای بررسی خالی بودن آن:
if (_idsList == null || _idsList.Any() is false) { }
4- استفاده از Null Conditional Operator برای بررسی نال بودن و سپس استفاده از متد Any برای بررسی خالی بودن آن:
if (_idsList?.Any() is false) { }
5- استفاده از pattern matching برای بررسی مقدار خاصیت Count یک لیست یا آرایه. البته Enumerableها به همراه این خاصیت نیستند و یا باید آنها را به لیست و یا آرایه تبدیل کرد و یا میتوان متد ()Count آنها را فراخوانی نمود:
if (_idsList is { Count: > 0 } is false) { }
6- استفاده از Null Conditional Operator برای بررسی نال بودن و سپس استفاده از مقدار خاصیت Count لیست، برای بررسی خالی بودن آن:
if (_idsList?.Count == 0) { }
7- استفاده از روش سنتی مقایسهی مستقیم با null و سپس استفاده از مقدار خاصیت Count لیست، برای بررسی خالی بودن آن:
if (_idsList == null || _idsList.Count == 0) { }
کدهای کامل این بررسی به صورت زیر هستند: AnyCountBenchmark.zip
ابتدا ارجاعی به BenchmarkDotNet به برنامه اضافه شدهاست:
<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>net5.0</TargetFramework> <Nullable>enable</Nullable> <TreatWarningsAsErrors>true</TreatWarningsAsErrors> </PropertyGroup> <ItemGroup> <PackageReference Include="BenchmarkDotNet" Version="0.12.1" /> </ItemGroup> </Project>
و سپس کدهای زیر، بررسی کارآیی روشهای مختلف تعیین خالی بودن مجموعهها را انجام میدهند:
using BenchmarkDotNet.Running; namespace AnyCountBenchmark { public static class Program { static void Main(string[] args) { #if DEBUG System.Console.WriteLine("Please set the project's configuration to Release mode first."); #else BenchmarkRunner.Run<Scenarios>(); #endif } } }
به همراه سناریوهای مختلف زیر:
using System; using System.Collections.Generic; using System.Linq; using BenchmarkDotNet.Attributes; using BenchmarkDotNet.Jobs; using BenchmarkDotNet.Order; namespace AnyCountBenchmark { [SimpleJob(RuntimeMoniker.NetCoreApp50)] [Orderer(SummaryOrderPolicy.FastestToSlowest, MethodOrderPolicy.Declared)] [RankColumn] public class Scenarios { private IList<int>? _idsList; private IEnumerable<int>? _idsEnumerable; private int[]? _idsArray; [GlobalSetup] public void Setup() { _idsEnumerable = Enumerable.Range(0, 10000); _idsList = _idsEnumerable.ToList(); _idsArray = _idsEnumerable.ToArray(); } #region Any_With_Null_coalescing [Benchmark] public void List_Any_With_Null_coalescing() { var list = _idsList ?? new List<int>(); if (list.Any() is false) { } } [Benchmark] public void Array_Any_With_Null_coalescing() { var array = _idsArray ?? Array.Empty<int>(); if (array.Any() is false) { } } [Benchmark] public void Enumerable_Any_With_Null_coalescing() { var enumerable = _idsEnumerable ?? Enumerable.Empty<int>(); if (enumerable.Any() is false) { } } #endregion #region Any_With_Is_Null_Check [Benchmark] public void List_Any_With_Is_Null_Check() { if (_idsList is null || _idsList.Any() is false) { } } [Benchmark] public void Array_Any_With_Is_Null_Check() { if (_idsArray is null || _idsArray.Any() is false) { } } [Benchmark] public void Enumerable_Any_With_Is_Null_Check() { if (_idsEnumerable is null || _idsEnumerable.Any() is false) { } } #endregion #region Any_Any_With_Null_Equality_Check [Benchmark] public void List_Any_With_Null_Equality_Check() { if (_idsList == null || _idsList.Any() is false) { } } [Benchmark] public void Array_Any_With_Null_Equality_Check() { if (_idsArray == null || _idsArray.Any() is false) { } } [Benchmark] public void Enumerable_Any_With_Null_Equality_Check() { if (_idsEnumerable == null || _idsEnumerable.Any() is false) { } } #endregion #region Any_With_Null_Conditional_Operator [Benchmark] public void List_Any_With_Null_Conditional_Operator() { if (_idsList?.Any() is false) { } } [Benchmark] public void Array_Any_With_Null_Conditional_Operator() { if (_idsArray?.Any() is false) { } } [Benchmark] public void Enumerable_Any_With_Null_Conditional_Operator() { if (_idsEnumerable?.Any() is false) { } } #endregion #region Count_With_Pattern_Matching [Benchmark] public void List_Count_With_Pattern_Matching() { if (_idsList is { Count: > 0 } is false) { } } [Benchmark] public void Array_Length_With_Pattern_Matching() { if (_idsArray is { Length: > 0 } is false) { } } [Benchmark] public void Enumerable_Count_With_Pattern_Matching() { var list = _idsEnumerable?.ToList(); if (list is { Count: > 0 } is false) { } } #endregion #region Count_With_Null_Conditional_Operator [Benchmark] public void List_Count_With_Null_Conditional_Operator() { if (_idsList?.Count == 0) { } } [Benchmark] public void Array_Length_With_Null_Conditional_Operator() { if (_idsArray?.Length == 0) { } } [Benchmark] public void Enumerable_Count_With_Null_Conditional_Operator() { if (_idsEnumerable?.Count() == 0) { } } #endregion #region Count_With_Null_Equality_Check [Benchmark] public void List_Count_With_Null_Equality_Check() { if (_idsList == null || _idsList.Count == 0) { } } [Benchmark] public void Array_Length_With_Null_Equality_Check() { if (_idsArray == null || _idsArray.Length == 0) { } } [Benchmark] public void Enumerable_Count_With_Null_Equality_Check() { if (_idsEnumerable == null || _idsEnumerable.Count() == 0) { } } #endregion } }
نتایج حاصل:
- بررسی خالی بودن آرایهها، بسیار سریعتر از بررسی خالی بودن لیستها و این مورد نیز سریعتر از Enumerableها است.
- اگر از آرایهها و یا لیستها استفاده میکنید، بررسی خاصیت Length و یا خاصیت Count آنها، بسیار سریعتر از بکارگیری متد Any بر روی آنها است.
- اگر از Enumerableها استفاده میکنید، استفاده از متد Any بر روی آنها، بسیار سریعتر از بکارگیری متد ()Count و یا تبدیل آنها به لیست و سپس بررسی خاصیت Count آنها است.
- بررسی نال بودن با pattern matching یا همان is null، نسبت به روشی سنتی استفادهی از null ==، سریعتر است. علت آنرا در مطلب «روش ترجیح داده شدهی مقایسه مقادیر اشیاء با null از زمان C# 7.0 به بعد» میتوانید مطالعه کنید.
بنابراین برای بررسی خالی بودن آرایهها و لیستها، بهتر است از خاصیت Length و یا Count آنها استفاده کرد و برای Enumerableها از متد ()Any.
اشتراکها
انتشار Windows 10 SDK
اشتراکها
پشتیبانی از HTTP 2 در ASP.NET 4.6
اشتراکها