اشتراکها
نگاهی به Entity Framework 7 چندسکویی
اشتراکها
کتابخانه Motion Slider
اشتراکها
فریم ورک bootmetro
پیش از ادامهی نوشتار بهتر است توضیحاتی دربارهی قالبهای T4 داده شود. این قالبهای مصنوعی حاوی کدهایی که است که هدف آن صرفهجویی در نوشتن کد توسط برنامه نویس است. مثلاً در MVC شما یکبار قالبی برای صفحه Index خود تهیه میکنید که برای نمونه بجای ساخت جدول ساده، از گرید Kendo استفاده کند و همچنین دارای دکمه ویرایش و جزئیات باشد. از این پس هر بار که نیاز به ساخت یک نمای نوع لیست برای یک ActionResult داشته باشید فرم ساز MVC از قالب شما استفاده خواهد کرد. روشن است که خود Visual Studio نیز از T4 در ساخت بسیاری از فرمها و کلاسها بهره میبرد.
خبر خوب اینکه برای ساخت کلاسهای هر موجودیت در Entity Framework نیز از قالبهای T4 استفاده میشود و اینکه این قالبها در دسترس توسعهدهندگان برای ویرایش یا افزودن است.
افزونهی Tangible را دریافت کنید و سپس نصب کنید. این افزونه ظاهر نامفهوم قالبهای T4 را ساده و روشن میکند.
ما نیاز داریم که خود Visual Studio زحمت این سه کار را بکشد:
1- بالای هر کلاس موجودیت عبارت using System.Runtime.Serialization; را بنویسید.
2- صفت [DataContract] را پیش از تعریف کلاس بیفزاید.
3- صفت [DataMember] را پیش از تعریف هر ویژگی بیفزاید.
همانند شکل زیر روی فایل MyNewsModel.tt دوکلیک کنید تا محتوای آن در سمت چپ نشان داده شود. این محتوا باید ظاهری همانند شکل پیدا کرده باشد:
کد زیر را در محتوای فایل جستوجو کنید:
public string Property(EdmProperty edmProperty) { return string.Format( CultureInfo.InvariantCulture, "{0} {1} {2} {{ {3}get; {4}set; }}", Accessibility.ForProperty(edmProperty), _typeMapper.GetTypeName(edmProperty.TypeUsage), _code.Escape(edmProperty), _code.SpaceAfter(Accessibility.ForGetter(edmProperty)), _code.SpaceAfter(Accessibility.ForSetter(edmProperty))); }
public string Property(EdmProperty edmProperty) { return string.Format( CultureInfo.InvariantCulture, "[DataMember]" + Environment.NewLine + "{0} {1} {2} {{ {3}get; {4}set; }}", Accessibility.ForProperty(edmProperty), _typeMapper.GetTypeName(edmProperty.TypeUsage), _code.Escape(edmProperty), _code.SpaceAfter(Accessibility.ForGetter(edmProperty)), _code.SpaceAfter(Accessibility.ForSetter(edmProperty))); }
public string EntityClassOpening(EntityType entity) { return string.Format( CultureInfo.InvariantCulture, "{0} {1}partial class {2}{3}", Accessibility.ForType(entity), _code.SpaceAfter(_code.AbstractOption(entity)), _code.Escape(entity), _code.StringBefore(" : ", _typeMapper.GetTypeName(entity.BaseType))); }
این کد را نیز به این صورت تغییر دهید:
public string EntityClassOpening(EntityType entity) { return string.Format( CultureInfo.InvariantCulture, "[DataContract]" + Environment.NewLine + "{0} {1}partial class {2}{3}", Accessibility.ForType(entity), _code.SpaceAfter(_code.AbstractOption(entity)), _code.Escape(entity), _code.StringBefore(" : ", _typeMapper.GetTypeName(entity.BaseType))); }
public string UsingDirectives(bool inHeader, bool includeCollections = true) { return inHeader == string.IsNullOrEmpty(_code.VsNamespaceSuggestion()) ? string.Format( CultureInfo.InvariantCulture, "{0}using System;{1}" + "{2}", inHeader ? Environment.NewLine : "", includeCollections ? (Environment.NewLine + "using System.Collections.Generic;") : "", inHeader ? "" : Environment.NewLine) : ""; }
public string UsingDirectives(bool inHeader, bool includeCollections = true) { return inHeader == string.IsNullOrEmpty(_code.VsNamespaceSuggestion()) ? string.Format( CultureInfo.InvariantCulture, "using System.Runtime.Serialization;" + Environment.NewLine + "{0}using System;{1}" + "{2}", inHeader ? Environment.NewLine : "", includeCollections ? (Environment.NewLine + "using System.Collections.Generic;") : "", inHeader ? "" : Environment.NewLine) : ""; }
فایل MyNewsModel.tt را ذخیره کنید و از آن خارج شوید. بار دیگر هر کدام از کلاسهای tblNews و tblCategory را باز کنید. خواهید دید که به صورت خودکار تغییرات مد نظر ما به آن افزوده شده است. از این پس بدون هیچ دلواپسی بابت حذف صفتها، میتوانید هرچند بار که خواستید مدل خود را بههنگام کنید.
در بخش پسین دوباره به WCF بازخواهیم گشت و به تعریف روالهای مورد نیاز خواهیم پرداخت.
یک: ASP.NET Core مستقل از Platform است
آیندهی محتوم نرمافزار، توسعه به شیوههای مستقل از Platform است. شاید این دلیل به تنهایی برای مهاجرت به ASP.NET Core کافی باشد. امروزه نرمافزارهایی که مبتنی بر یک Platform خاص نیستند، نسبت به سایر نرمافزارها مزیت رقابتیتری دارند. نرمافزارهای Cross Platform یا مستقل از Platform، بر روی هر سیستم عاملی اجرا میشوند. برای اجرای آنها در کامپیوترهای شخصی یا Server کافیست معماری پردازندهی مرکزی x86 باشد و سیستم عامل نیز یکی از انواع ویندوز، لینوکس یا مک.
دلیل مستقل بودن ASP.NET Core از Platform، مبتنی بودن آن بر NET Core. است. این نسخه از داتنت را میتوان برای سیستمعاملهای مختلف از http://dot.net دانلود و نصب کرد.
برای اجرای نرمافزارهایی که مبتنی بر NET Core. هستند نیاز به بازنویسی کدها یا استفاده از زبانهای برنامهنویسی جداگانهای نیست. این خاصیت همچنین برای libraryهای استانداردی که از این نسخه از داتنت استفاده میکنند نیز صادق است.
دو: Open Source است
یکی از انتقادهایی که سالها به مایکروسافت میشد، ناشناخته بودن سورس نرمافزارهای این شرکت و انحصار طلبیهایش بود. اما در سالهای اخیر مایکروسافت نشان دادهاست که این جنبه از کاراکترش را به تدریج اصلاح کردهاست. به طوری که اسکات هانسلمن، یکی از کارمندان این شرکت و وبلاگنویس مشهور در این مورد گفته است:
دلیل آمدن من به مایکروسافت این بود که میخواستیم هر چقدر میتوانیم کارها را Open Source کنیم و یک جامعهی کاربری برای داتنت و اوپن سورس بسازیم و حالا به NET Core 1.0. رسیدهایم.
زمانی شایعهی لو رفتن بخشی از سورس کد ویندوز ۹۵، در صدر اخبار تکنولوژی بود و این یک شکست برای مایکروسافت محسوب میشد. اما امروزه ASP.NET Core با لایسنس MIT عرضه شده است که یکی از آزادترین مجوزهای اوپن سورس است. نرمافزارهایی که با این مجوز عرضه میشوند، آزادی تغییر کد، ادغام با مجوزهای دیگر، عرضه به عنوان محصول دیگر، استفاده تجاری و ... را به همهی توسعهدهندگان میدهد.
سه: جدا بودن از Web Server
این نسخهی از APS.NET، کاملاً از وبسرور که نرمافزارها را هاست میکند، جدا (decouple) شده است. اگرچه همچنان استفاده از IIS بر روی ویندوز منطقی به نظر میرسد اما مایکروسافت یک پروژهی اوپن سورس دیگری را به نام Kestrel نیز منتشر کرده است.
وبسرور Kestrel مبتنی بر پروژه libuv است و libuv در اصل برای هاست کردن Node.js تولید شده بود و تأکید آن بر روی انجام عملیات I/O به صورت asynchronous است.
نکته جالب این است که یک برنامهی مبتنی بر ASP.NET Core، در واقع یک Console Application است که در متد Main آن وبسرور فراخوانی میشود:
using System; using Microsoft.AspNetCore.Hosting; namespace aspnetcoreapp { public class Program { public static void Main(string[] args) { var host = new WebHostBuilder() .UseKestrel() .UseStartup<Startup>() .Build(); host.Run(); } } }
چهار: تزریق وابستگی (Dependency Injection) تو کار
تزریق وابستگیها برای ایجاد وابستگی سست (loosely coupling) بین اشیاء مرتبط و وابسته به یکدیگر است. به جای نمونهسازی مستقیم اشیاء مرتبط، یا استفاده از ارجاعهای ایستا به آن اشیاء، زمانی که یک کلاس به آنها احتیاج داشته باشد، با روشهای خاصی از طریق DI به اشیاء مورد نیاز دسترسی پیدا میکند. در این استراتژی، ماژولهای سطح بالا نباید به ماژولهای سطح پایین وابسته باشند، بلکه هر دو باید به abstraction (معمولا Interface ها) وابسته باشند.
وقتی یک سیستم برای استفادهی از DI طراحی شدهاست و کلاسهای زیادی دارد که وابستگیهایش را از طریق constructor یا propertyها درخواست میکند، بهتر است یک کلاس مخصوص ایجاد آن کلاسها و وابستگیهایشان داشته باشد. به این کلاسها container، یا Inversion of Control (IoC) container یا Dependency Injection (DI) container گفته میشود.
با این روش، بدون نیاز به hard code کردن instance سازی از کلاسها، میتوان گرافهای پیچیده وابستگی را در اختیار یک کلاس قرار داد.
طراحی ASP.NET Core از پایه طوری است که حداکثر استفاده را از Dependency Injection میکند. یک container ساده توکار با نام IServiceProvider وجود دارد که به صورت پیشفرض constructor injection را پشتیبانی میکند.
در ASP.NET Core با مفهومی به نام service سر و کار خواهید داشت که در واقع به type هایی گفته میشود که از طریق DI در اختیار شما قرار میگیرند. سرویسها در متد ConfigureServices کلاس Startup برنامه شما تعریف میشوند. این serviceها میتوانند Entity Framework Core یا ASP.NET Core MVC باشند یا سرویسهایی که توسط شما تعریف شدهاند. مثال:
// This method gets called by the runtime. Use this method to add services to the container. public void ConfigureServices (IServiceCollection services) { // Add framework services. services.AddDbContext<ApplicationDbContext>(options => options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection"))); services.AddIdentity<ApplicationUser, IdentityRole>() .AddEntityFrameworkStores<ApplicationDbContext>() .AddDefaultTokenProviders(); services.AddMvc(); // Add application services. services.AddTransient<IEmailSender, AuthMessageSender>(); services.AddTransient<ISmsSender, AuthMessageSender>(); }
پنج: یکپارچگی با frameworkهای مدرن سمت کلاینت
فرآیند build در برنامههای تحت وب مدرن معمولاً این وظایف را انجام میدهد:
- bundle و minify کردن فایلهای جاوا اسکریپت و همینطور CSS
- اجرای ابزارهایی برای bundle و minify کردن قبل از هر build
- کامپایل کردن فایلهای LESS و SASS در CSS
- کامپیال کردن فایلهای CoffeeScript و TypeScript در JavaScript
برای اجرای چنین فرآیندهایی از ابزاری به نام task runner استفاده میشود که Visual Studio از دو ابزار task runner مبتنی برا جاوا اسکریپت به نامهای Gulp و Grunt بهره میبرد. از این ابزارها با استفاده از ASP.NET Core Web Application template میتوان در ASP.NET Core استفاده کرد.
همچنین امکان استفاده از Bower که یک package manager (مانند NuGet) برای وب است، وجود دارد. معمولاً از Bower برای نصب فایلهای CSS ، فونتها، frameworkهای سمت کلاینت و کتابخانههای جاوا اسکریپت استفاده میشود. اگرچه بسیاری از packageها در NuGet هم وجود دارند، اما تمرکز بیشتر NuGet بر روی کتابخانههای داتنتی است.
نصب و استفادهی سایر libraryهای سمت کلاینت مانند Bootstrap ، Knockout.js ، Angular JS و زبان TypeScript نیز در Visual Studio و هماهنگی آن با ASP.NET Core نیز بسیار ساده است.
پس همین حالا دست به کار شوید و با نصب -حداقل - Microsoft Visual Studio 2015 Update 3 بر روی ویندوز یا Visual Studio Code بر روی هر سیستم عاملی از برنامهنویسی با ASP.NET Core لذت ببرید!
منابع :
NET Core. چیست؟
برای اغلب توسعه دهندههای دات نت (برنامههای وب و دسکتاپ) تنها یک دات نت فریم ورک شناخته شده وجود دارد: The `Full` .NET Framework
که تنها بر روی ویندوز قابل اجرا است و آخرین نگارش پایدار آن در زمان نگارش این مطلب، 4.6.1 است. این فریم ورک بزرگ، از اجزایی تشکیل شدهاست که در تصویر ذیل قابل مشاهدهاند:
مهمترین قسمتهای این فریم ورک «بزرگ» شامل مواردی مانند CLR که کار تبدیل کدهای IL را به کدهای ماشین انجام میدهد، BCL که کلاسهای پایهای را جهت کار با IO، Text و غیره، فراهم میکنند، هستند؛ به علاوه کتابخانههایی مانند Windows Forms، WPF و ASP.NET که برفراز BCL و CLR کار میکنند.
هرچند تعدادی از توسعه دهندههای دات نت تنها با Full framework کار میکنند، اما در طی سالهای اخیر انشعابات بسیار دیگری از آن به وجود آمدهاند؛ مانند دات نتهای ویژهی ویندوزهای 8 و Universal Windows Platform، دات نت مخصوص ویندوز فون 8 و ویندوز فون مبتنی بر پلتفرم سیلورلایت، به علاوه دات نت پلتفرم زامارین برای توسعهی برنامههای iOS و Android نیز هم اکنون وجود دارند (البته در اینجا Mono، دات نت میکرو و غیره را هم باید ذکر کرد). این فریم ورکها و انشعابات، به همراه پیاده سازی یک سری موارد مشترک و مواردی کاملا اختصاصی هستند که به سایر پلتفرمهای دیگر قابل انتقال نیستند.
با زیاد شدن تعداد انشعابات دات نت «بزرگ»، نوشتن کدی که قابل اجرای بر روی تمام پلتفرمهای یاد شده باشد، مشکل شد. اینجا بود که مفهومی را به نام PCL یا Portable class libraries معرفی کردند:
هدف از PCLها، ساده سازی کامپایل و به اشتراک گذاری کد بین پلتفرمهای مختلف بود و پشتیبانی قابل توجهی هم از آن در VS.NET وجود دارد. هرچند این روش نسبتا موفق بود اما مشکلاتی را هم به همراه داشت. برای مثال با ارائهی یک انشعاب و پلتفرم دیگری از دات نت «بزرگ»، کتابخانهی PCL موجود، باید برای این انشعاب جدید مجددا کامپایل شود. به علاوه در اینجا تنها محدود به انتخاب امکانات مشترک بین پلتفرمهای مختلف هستید.
برای رفع این مشکلات در پایان سال 2014، یک «دات نت فریم ورک جدید» به نام NET Core. معرفی شد که سورس باز است و همچنین چندسکویی (از ویندوز، لینوکس و OSX پشتیبانی میکند).
هرچند پیشتر Windows Store و ASP.NET Core app به صورت پلتفرمهایی مجزا ارائه شده بودند، اما اکنون از یک BCL مشترک به نام CoreFX استفاده میکنند و نحوهی توزیع آنها صرفا از طریق نیوگت است. به عبارتی اینبار بجای دریافت یک فریم ورک «بزرگ»، تنها اجزایی را دریافت میکنید که از طریق نیوگت سفارش دادهاید.
به این ترتیب نه تنها کار توزیع برنامههای مبتنی بر NET Core. با سهولت بیشتری انجام خواهد شد، بلکه به روز رسانی اجزای یک برنامه، تاثیری بر روی سایر برنامهها نخواهد داشت و مشکلات جانبی را به وجود نمیآورد. به علاوه دیگر نیازی نیست تا منتظر یک نگارش «بزرگ» دیگر باشید تا بتوانید آخرین به روز رسانیها را دریافت کنید. اینبار به روز رسانی بستههای نیوگت برنامه معادل هستند با به روز رسانی کل فریم ورک در نگارشهای قبلی «بزرگ» آن. در اینجا حتی CoreCLR و NET Native runtime. که مربوط به Windows runtime است هم از طریق نیوگت به روز رسانی میشود.
البته NET Core. انتهای مسیر نیست و هم اکنون NETStandard نیز جهت رفع مشکلات کامپایل مجدد PCLها در حال توسعه است و پس از ارائهی آن، PCLها منسوخ شده درنظر گرفته میشوند. در این حالت با انتخاب target platform ایی به نام NETStandard (بجای مثلا انتخاب دات نت 4.5 و ویندوز فون 8)، اینبار دات نت 4.5 و ویندوز فون 8 و تمام پلتفرمهای دیگر، به صورت یکجا انتخاب میشوند و اگر پلتفرم جدیدی برای مثال از NETStandard نگارش 1.1 پشتیبانی کند، به این معنا است که کتابخانهی شما هم اکنون با آن سازگار است و دیگر نیازی به کامپایل مجدد آن نخواهد بود.
به علاوه هر برنامهای که بر اساس NETStandard تهیه شود، قابلیت اجرای بر روی NET Core. را نیز خواهد داشت. به عبارتی برنامههای NETStandard همان برنامههای مبتنی بر NET Core. هستند.
ASP.NET Core چیست؟
در زمان نگارش این مطلب، دو گزینهی برنامههای وب ASP.NET Core 1.0 و همچنین Windows Store apps (مبتنی بر NET Native Runtime.) قابلیت استفادهی از این پلتفرم جدید NET Core. دارند.
ASP.NET Core 1.0، که پیشتر با نام ASP.NET 5 معرفی شده بود، بازنویسی کامل ASP.NET است که با ایدهی کاملا ماژولار بودن، تهیه شدهاست و از طریق آن، قابلیت به روز رسانی منظم و توزیع آسان از طریق نیوگت، میسر خواهد شد. به علاوه در آن، بسیاری از الگوهای برنامه نویسی شیءگرا مانند تزریق وابستگیها، به صورت توکار و از ابتدا پشتیبانی میشوند.
ASP.NET Core 1.0 از WebForms ، VB ، WebPages و SignalR پشتیبانی نمیکند. البته در این بین عدم پشتیبانی از «وب فرمها» قطعی است؛ اما افزودن سه مورد دیگر یاد شده، جزو لیست کارهای پس از ارائهی نگارش 1 این فریم ورک قرار دارند و به زودی ارائه خواهند شد.
اکنون وضعیت ASP.NET MVC 5 و ASP.NET Web API 2 چگونه است؟
ASP.NET Core 1.0 مدل برنامه نویسی ASP.NET MVC و Web API را به صورت یکپارچه ارائه میدهد و دیگر خبری از ارائهی مجزای اینها نخواهد بود و دقیقا بر مبنای مفاهیم برنامه نویسی این دو بنا شدهاست. به صورت خلاصه MVC + Web API + Web Pages = Core MVC 1.0
پیشتر فضای نام System.Web.MVC مخصوص ASP.NET MVC بود و فضای نام مجزای دیگری به نام System.Web.Http مخصوص ASP.NET Web API. اما اکنون تنها یک فضای نام مشترک و یکپارچه به نام Microsoft.AspNet.Mvc هر دوی اینها را پوشش میدهد.
در این نگارش جدید وابستگی از system.web مبتنی بر IIS حذف شدهاست و با استفاده از هاست جدید چندسکویی به نام Kesterl، به سرعتی 5 برابر سرعت NodeJS دست یافتهاند.
آخرین تاریخ به روز رسانی ASP.NET MVC 5.x دوشنبه، 20 بهمن 1393 است (با ارائه نگارش 5.2.3 که آخرین نگارش رسمی و پایدار آن است) و آخرین تاریخ به روز رسانی ASP.NET Web API 2.x نیز همان روز است.
هرچند مایکروسافت عادت به اعلام رسمی پایان پشتیبانی از بسیاری از محصولات خود را ندارد اما تمام فناوریهای «قدیمی» خودش را بر روی CodePlex نگهداری میکند و تمام فناوریهای «جدید» را به GitHub منتقل کردهاست. بنابراین اگر در مورد فناوری خاصی به Codeplex رسیدید، یعنی «دیگر ادامهی رسمی نخواهد یافت» و حداکثر در حد رفع یک سری باگها و مشکلات گزارش شده باقی میمانند.
مثال 1: هم اکنون نگارش دوم ASP.NET Identity را بر روی Codeplex میتوانید مشاهده کنید. نگارش سوم آن به GitHub منتقل شدهاست که این نگارش صرفا با ASP.NET Core 1.0 سازگار است. در مورد ASP.NET MVC و Web API نیز چنین حالتی رخ دادهاست. نگارشهای 5 و 2 آنها بر روی Codeplex موجود هستند و نگارش ششم که به ASP.NET Core 1.0 تغییر نام یافت و ترکیبی است از MVC و Web API، در GitHub توسعه مییابد.
مثال 2: WCF به علت پیچیدگی بیش از حد و مدرن نبودن طراحی آن، رقابت را به ASP.NET Web API 2.x واگذار کرد و مدل برنامه نویسی ASP.NET Web API 2.x نیز هم اکنون جزئی از ASP.NET Core 1.0 است. بنابراین اگر قصد ایجاد پروژهی جدیدی را بر این مبنا دارید، بهتر است با APS.NET Core 1.0 کار را شروع کنید.
اما هنوز تعداد زیادی از کتابخانههای Full framework به NET Core. انتقال پیدا نکردهاند
برای نمونه هنوز EF Core 1.0 که پیشتر نام EF 7.x به آن داده شده بود، به مرحلهی نهایی تکمیل قابلیتهای آن نرسیدهاست. اما باید دانست که ASP.NET Core 1.0 صرفا بر فراز NET Core. قابل اجرا نیست؛ بلکه قابلیت اجرای بر فراز NET 4.6. و یا همان دات نت «بزرگ و کامل» را نیز دارد. بنابراین به سادگی قابلیت اجرای EF 6.x و یا NHibernate را نیز دارا است. تنها مزیتی را که در اینجا از دست خواهید، قابلیت چندسکویی بودن ASP.NET Core 1.0 است؛ زیرا EF 6.x با چنین دیدی طراحی نشدهاست.
همانطور که ملاحظه میکنید، ASP.NET Core 1.0 قابلیت اجرای بر روی هر دوی NET Core 1.0. و NET 4.6. را دارا است. اما یکی، چندسکویی است و دیگری صرفا مختص به ویندوز.
فناورهای منسوخ شدهی در NET Core.
یکسری از فناوریها و کتابخانهها احتمالا هیچگاه قابلیت انتقال به NET Core. را نخواهند یافت و یا حداقل باید تا چندنگارش بعدی آن صبر کنند. فناوریهای خاتمه یافتهی با NET Core. به شرح زیر هستند:
- Reflection: همانطور که عنوان شد، NET Core. بر فراز CoreCLR و همچنین NET Native runtime. اجرا میشود و تولید برنامههای native و static linking آنها مانند برنامههای ++C، نیاز به دانستن اجزایی دارد که به صورت پویا فراخوانی نمیشوند و بلافاصله و در زمان کامپایل، توسط کامپایلر قابل تشخیص هستند. همین محدودیت سبب شدهاست که استفادهی از Reflection در NET Core. به حداقل ممکن آن برسد. برای مثال در System.Object متد GetType آن تنها نام نوع را باز میگرداند و نه اطلاعات بیشتری را مانند GetMembers سابق.
- App Domains: هرچند CoreCLR از App Domains پشتیبانی میکند اما NET Native runtime. خیر. به همین جهت برای ایزوله سازی برنامهها توصیه شدهاست که از containerهایی مانند docker استفاده شود.
- Remoting: پیش از WCF جهت برقراری ارتباط بین برنامهها مطرح شده بود و هم اکنون در دات نت کامل هم آنچنان استفادهای از آن نمیشود.
- binary serialization: البته کتابخانههایی مانند JSON.NET و امثال آن، نگارش NET Core. هم دارند؛ اما چون binary serialization نیاز به اطلاعات reflection قابل توجهی دارد دیگر پشتیبانی نخواهد شد.
فناورهایی که به زودی به NET Core. منتقل میشوند
یکسری از فناوریها مانند XAML هنوز معادل NET Core. ندارند و لیست زیر قرار است از طرف مایکروسافت سورس باز شده و همچنین به NET Core. منتقل شود:
System.Data
System.DirectoryServices
System.Drawing
System.Transactions
System.Xml.Xsl and System.Xml.Schema
System.Net.Mail
System.IO.Ports
System.Workflow
System.Xaml
مراحل نصب ASP.NET Core 1.0
پیش از نصب نگارش 1.0 RTM باید به این نکته دقت داشت که نصاب آن، نگارشهای آزمایشی قبلی را حذف و یا بازنویسی نمیکند و همین مساله ممکن است سبب بروز تداخلهایی و یا حتی از کار افتادن VS.NET شما شود. بنابراین اگر نگارشهای RC یا بتا را پیشتر نصب کردهاید، به Add remove programs ویندوز مراجعه کرده و سه مورد ذیل را حتما حذف کنید (خیلی مهم):
- Preview Tooling (all versions)
- NET Core Runtime SDK (all versions).
- NET Core Runtime (all Versions).
پس از حذف بستههای قدیمی، برای نصب نگارش 1.0 RTM، ابتدا نیاز است Visual Studio 2015 Update 3 را نصب کنید و پس از آن با استفاده از NET Core for Visual Studio Official MSI Installer. کار نصب اجزای مورد نیاز آن انجام خواهد شد.
بررسی شماره نگارش 1.0 RTM
پس از نصب اجزای عنوان شده، خط فرمان را گشوده و دستور ذیل را صادر کنید:
همانطور که مشاهده میکنید، نگارش ذکر شده هنوز در مرحلهی preview است و صرفا مرتبط است به tooling و یا ابزارهای مرتبط با آن.
اگر یک پروژهی خالی ASP.NET Core Web Application را نیز شروع کنید (با طی مراحل زیر جهت ایجاد یک پروژهی جدید):
در اینجا فایل جدیدی را به نام global.json مشاهده میکنید که محتوایات آن شامل دقیقا همین شماره نگارش است؛ به همراه معرفی پوشههای اصلی پروژه:
برای اغلب توسعه دهندههای دات نت (برنامههای وب و دسکتاپ) تنها یک دات نت فریم ورک شناخته شده وجود دارد: The `Full` .NET Framework
که تنها بر روی ویندوز قابل اجرا است و آخرین نگارش پایدار آن در زمان نگارش این مطلب، 4.6.1 است. این فریم ورک بزرگ، از اجزایی تشکیل شدهاست که در تصویر ذیل قابل مشاهدهاند:
مهمترین قسمتهای این فریم ورک «بزرگ» شامل مواردی مانند CLR که کار تبدیل کدهای IL را به کدهای ماشین انجام میدهد، BCL که کلاسهای پایهای را جهت کار با IO، Text و غیره، فراهم میکنند، هستند؛ به علاوه کتابخانههایی مانند Windows Forms، WPF و ASP.NET که برفراز BCL و CLR کار میکنند.
هرچند تعدادی از توسعه دهندههای دات نت تنها با Full framework کار میکنند، اما در طی سالهای اخیر انشعابات بسیار دیگری از آن به وجود آمدهاند؛ مانند دات نتهای ویژهی ویندوزهای 8 و Universal Windows Platform، دات نت مخصوص ویندوز فون 8 و ویندوز فون مبتنی بر پلتفرم سیلورلایت، به علاوه دات نت پلتفرم زامارین برای توسعهی برنامههای iOS و Android نیز هم اکنون وجود دارند (البته در اینجا Mono، دات نت میکرو و غیره را هم باید ذکر کرد). این فریم ورکها و انشعابات، به همراه پیاده سازی یک سری موارد مشترک و مواردی کاملا اختصاصی هستند که به سایر پلتفرمهای دیگر قابل انتقال نیستند.
با زیاد شدن تعداد انشعابات دات نت «بزرگ»، نوشتن کدی که قابل اجرای بر روی تمام پلتفرمهای یاد شده باشد، مشکل شد. اینجا بود که مفهومی را به نام PCL یا Portable class libraries معرفی کردند:
هدف از PCLها، ساده سازی کامپایل و به اشتراک گذاری کد بین پلتفرمهای مختلف بود و پشتیبانی قابل توجهی هم از آن در VS.NET وجود دارد. هرچند این روش نسبتا موفق بود اما مشکلاتی را هم به همراه داشت. برای مثال با ارائهی یک انشعاب و پلتفرم دیگری از دات نت «بزرگ»، کتابخانهی PCL موجود، باید برای این انشعاب جدید مجددا کامپایل شود. به علاوه در اینجا تنها محدود به انتخاب امکانات مشترک بین پلتفرمهای مختلف هستید.
برای رفع این مشکلات در پایان سال 2014، یک «دات نت فریم ورک جدید» به نام NET Core. معرفی شد که سورس باز است و همچنین چندسکویی (از ویندوز، لینوکس و OSX پشتیبانی میکند).
هرچند پیشتر Windows Store و ASP.NET Core app به صورت پلتفرمهایی مجزا ارائه شده بودند، اما اکنون از یک BCL مشترک به نام CoreFX استفاده میکنند و نحوهی توزیع آنها صرفا از طریق نیوگت است. به عبارتی اینبار بجای دریافت یک فریم ورک «بزرگ»، تنها اجزایی را دریافت میکنید که از طریق نیوگت سفارش دادهاید.
به این ترتیب نه تنها کار توزیع برنامههای مبتنی بر NET Core. با سهولت بیشتری انجام خواهد شد، بلکه به روز رسانی اجزای یک برنامه، تاثیری بر روی سایر برنامهها نخواهد داشت و مشکلات جانبی را به وجود نمیآورد. به علاوه دیگر نیازی نیست تا منتظر یک نگارش «بزرگ» دیگر باشید تا بتوانید آخرین به روز رسانیها را دریافت کنید. اینبار به روز رسانی بستههای نیوگت برنامه معادل هستند با به روز رسانی کل فریم ورک در نگارشهای قبلی «بزرگ» آن. در اینجا حتی CoreCLR و NET Native runtime. که مربوط به Windows runtime است هم از طریق نیوگت به روز رسانی میشود.
البته NET Core. انتهای مسیر نیست و هم اکنون NETStandard نیز جهت رفع مشکلات کامپایل مجدد PCLها در حال توسعه است و پس از ارائهی آن، PCLها منسوخ شده درنظر گرفته میشوند. در این حالت با انتخاب target platform ایی به نام NETStandard (بجای مثلا انتخاب دات نت 4.5 و ویندوز فون 8)، اینبار دات نت 4.5 و ویندوز فون 8 و تمام پلتفرمهای دیگر، به صورت یکجا انتخاب میشوند و اگر پلتفرم جدیدی برای مثال از NETStandard نگارش 1.1 پشتیبانی کند، به این معنا است که کتابخانهی شما هم اکنون با آن سازگار است و دیگر نیازی به کامپایل مجدد آن نخواهد بود.
به علاوه هر برنامهای که بر اساس NETStandard تهیه شود، قابلیت اجرای بر روی NET Core. را نیز خواهد داشت. به عبارتی برنامههای NETStandard همان برنامههای مبتنی بر NET Core. هستند.
ASP.NET Core چیست؟
در زمان نگارش این مطلب، دو گزینهی برنامههای وب ASP.NET Core 1.0 و همچنین Windows Store apps (مبتنی بر NET Native Runtime.) قابلیت استفادهی از این پلتفرم جدید NET Core. دارند.
ASP.NET Core 1.0، که پیشتر با نام ASP.NET 5 معرفی شده بود، بازنویسی کامل ASP.NET است که با ایدهی کاملا ماژولار بودن، تهیه شدهاست و از طریق آن، قابلیت به روز رسانی منظم و توزیع آسان از طریق نیوگت، میسر خواهد شد. به علاوه در آن، بسیاری از الگوهای برنامه نویسی شیءگرا مانند تزریق وابستگیها، به صورت توکار و از ابتدا پشتیبانی میشوند.
ASP.NET Core 1.0 از WebForms ، VB ، WebPages و SignalR پشتیبانی نمیکند. البته در این بین عدم پشتیبانی از «وب فرمها» قطعی است؛ اما افزودن سه مورد دیگر یاد شده، جزو لیست کارهای پس از ارائهی نگارش 1 این فریم ورک قرار دارند و به زودی ارائه خواهند شد.
اکنون وضعیت ASP.NET MVC 5 و ASP.NET Web API 2 چگونه است؟
ASP.NET Core 1.0 مدل برنامه نویسی ASP.NET MVC و Web API را به صورت یکپارچه ارائه میدهد و دیگر خبری از ارائهی مجزای اینها نخواهد بود و دقیقا بر مبنای مفاهیم برنامه نویسی این دو بنا شدهاست. به صورت خلاصه MVC + Web API + Web Pages = Core MVC 1.0
پیشتر فضای نام System.Web.MVC مخصوص ASP.NET MVC بود و فضای نام مجزای دیگری به نام System.Web.Http مخصوص ASP.NET Web API. اما اکنون تنها یک فضای نام مشترک و یکپارچه به نام Microsoft.AspNet.Mvc هر دوی اینها را پوشش میدهد.
در این نگارش جدید وابستگی از system.web مبتنی بر IIS حذف شدهاست و با استفاده از هاست جدید چندسکویی به نام Kesterl، به سرعتی 5 برابر سرعت NodeJS دست یافتهاند.
آخرین تاریخ به روز رسانی ASP.NET MVC 5.x دوشنبه، 20 بهمن 1393 است (با ارائه نگارش 5.2.3 که آخرین نگارش رسمی و پایدار آن است) و آخرین تاریخ به روز رسانی ASP.NET Web API 2.x نیز همان روز است.
هرچند مایکروسافت عادت به اعلام رسمی پایان پشتیبانی از بسیاری از محصولات خود را ندارد اما تمام فناوریهای «قدیمی» خودش را بر روی CodePlex نگهداری میکند و تمام فناوریهای «جدید» را به GitHub منتقل کردهاست. بنابراین اگر در مورد فناوری خاصی به Codeplex رسیدید، یعنی «دیگر ادامهی رسمی نخواهد یافت» و حداکثر در حد رفع یک سری باگها و مشکلات گزارش شده باقی میمانند.
مثال 1: هم اکنون نگارش دوم ASP.NET Identity را بر روی Codeplex میتوانید مشاهده کنید. نگارش سوم آن به GitHub منتقل شدهاست که این نگارش صرفا با ASP.NET Core 1.0 سازگار است. در مورد ASP.NET MVC و Web API نیز چنین حالتی رخ دادهاست. نگارشهای 5 و 2 آنها بر روی Codeplex موجود هستند و نگارش ششم که به ASP.NET Core 1.0 تغییر نام یافت و ترکیبی است از MVC و Web API، در GitHub توسعه مییابد.
مثال 2: WCF به علت پیچیدگی بیش از حد و مدرن نبودن طراحی آن، رقابت را به ASP.NET Web API 2.x واگذار کرد و مدل برنامه نویسی ASP.NET Web API 2.x نیز هم اکنون جزئی از ASP.NET Core 1.0 است. بنابراین اگر قصد ایجاد پروژهی جدیدی را بر این مبنا دارید، بهتر است با APS.NET Core 1.0 کار را شروع کنید.
اما هنوز تعداد زیادی از کتابخانههای Full framework به NET Core. انتقال پیدا نکردهاند
برای نمونه هنوز EF Core 1.0 که پیشتر نام EF 7.x به آن داده شده بود، به مرحلهی نهایی تکمیل قابلیتهای آن نرسیدهاست. اما باید دانست که ASP.NET Core 1.0 صرفا بر فراز NET Core. قابل اجرا نیست؛ بلکه قابلیت اجرای بر فراز NET 4.6. و یا همان دات نت «بزرگ و کامل» را نیز دارد. بنابراین به سادگی قابلیت اجرای EF 6.x و یا NHibernate را نیز دارا است. تنها مزیتی را که در اینجا از دست خواهید، قابلیت چندسکویی بودن ASP.NET Core 1.0 است؛ زیرا EF 6.x با چنین دیدی طراحی نشدهاست.
همانطور که ملاحظه میکنید، ASP.NET Core 1.0 قابلیت اجرای بر روی هر دوی NET Core 1.0. و NET 4.6. را دارا است. اما یکی، چندسکویی است و دیگری صرفا مختص به ویندوز.
فناورهای منسوخ شدهی در NET Core.
یکسری از فناوریها و کتابخانهها احتمالا هیچگاه قابلیت انتقال به NET Core. را نخواهند یافت و یا حداقل باید تا چندنگارش بعدی آن صبر کنند. فناوریهای خاتمه یافتهی با NET Core. به شرح زیر هستند:
- Reflection: همانطور که عنوان شد، NET Core. بر فراز CoreCLR و همچنین NET Native runtime. اجرا میشود و تولید برنامههای native و static linking آنها مانند برنامههای ++C، نیاز به دانستن اجزایی دارد که به صورت پویا فراخوانی نمیشوند و بلافاصله و در زمان کامپایل، توسط کامپایلر قابل تشخیص هستند. همین محدودیت سبب شدهاست که استفادهی از Reflection در NET Core. به حداقل ممکن آن برسد. برای مثال در System.Object متد GetType آن تنها نام نوع را باز میگرداند و نه اطلاعات بیشتری را مانند GetMembers سابق.
- App Domains: هرچند CoreCLR از App Domains پشتیبانی میکند اما NET Native runtime. خیر. به همین جهت برای ایزوله سازی برنامهها توصیه شدهاست که از containerهایی مانند docker استفاده شود.
- Remoting: پیش از WCF جهت برقراری ارتباط بین برنامهها مطرح شده بود و هم اکنون در دات نت کامل هم آنچنان استفادهای از آن نمیشود.
- binary serialization: البته کتابخانههایی مانند JSON.NET و امثال آن، نگارش NET Core. هم دارند؛ اما چون binary serialization نیاز به اطلاعات reflection قابل توجهی دارد دیگر پشتیبانی نخواهد شد.
فناورهایی که به زودی به NET Core. منتقل میشوند
یکسری از فناوریها مانند XAML هنوز معادل NET Core. ندارند و لیست زیر قرار است از طرف مایکروسافت سورس باز شده و همچنین به NET Core. منتقل شود:
System.Data
System.DirectoryServices
System.Drawing
System.Transactions
System.Xml.Xsl and System.Xml.Schema
System.Net.Mail
System.IO.Ports
System.Workflow
System.Xaml
مراحل نصب ASP.NET Core 1.0
پیش از نصب نگارش 1.0 RTM باید به این نکته دقت داشت که نصاب آن، نگارشهای آزمایشی قبلی را حذف و یا بازنویسی نمیکند و همین مساله ممکن است سبب بروز تداخلهایی و یا حتی از کار افتادن VS.NET شما شود. بنابراین اگر نگارشهای RC یا بتا را پیشتر نصب کردهاید، به Add remove programs ویندوز مراجعه کرده و سه مورد ذیل را حتما حذف کنید (خیلی مهم):
- Preview Tooling (all versions)
- NET Core Runtime SDK (all versions).
- NET Core Runtime (all Versions).
پس از حذف بستههای قدیمی، برای نصب نگارش 1.0 RTM، ابتدا نیاز است Visual Studio 2015 Update 3 را نصب کنید و پس از آن با استفاده از NET Core for Visual Studio Official MSI Installer. کار نصب اجزای مورد نیاز آن انجام خواهد شد.
بررسی شماره نگارش 1.0 RTM
پس از نصب اجزای عنوان شده، خط فرمان را گشوده و دستور ذیل را صادر کنید:
C:\Users\Vahid>dotnet --version 1.0.0-preview2-003121
اگر یک پروژهی خالی ASP.NET Core Web Application را نیز شروع کنید (با طی مراحل زیر جهت ایجاد یک پروژهی جدید):
.NET Core -> ASP.NET Core Web Application (.NET Core) -> Select `Empty` Template
در اینجا فایل جدیدی را به نام global.json مشاهده میکنید که محتوایات آن شامل دقیقا همین شماره نگارش است؛ به همراه معرفی پوشههای اصلی پروژه:
{ "projects": [ "src", "test" ], "sdk": { "version": "1.0.0-preview2-003121" } }
اشتراکها
بهبودهای زمان و تاریخ در NET 6.
In this blog post, I’m going to cover the following topics:
- The new DateOnly and TimeOnly types
- Time Zone Conversion APIs
- Time Zone Display Names on Linux and macOS
- TimeZoneInfo.AdjustmentRule Improvements
For even more details, you can also refer to dotnet/runtime#45318 on GitHub.
The long-term-support (LTS) version 3.1 of Microsoft .NET Core Framework is slated to go out of support on December 13th, 2022. Microsoft recommends upgrading .NET Core 3.1 applications to .NET 6.0 to stay supported for the future, while the developers have mixed feelings about the .NET support policy.
منظور من اجرای ASP.NET Core بر روی Full Dot Net Framework نیست. با توجه به پشتیبانی اضافه کردن Assemblyهای کامپایل شده برای Full Dot Net Framework بدون کامپایل مجدد در Dot Net Core 2 که شامل نزدیک به 70% از Nuget Packageهای موجود میشود ( حتی مواردی پیچیده چون Web API OData و NQuery )، میتوان پروژه را روی Dot Net Core 2 پیش برد و در صورت لزوم Dllهای Dot Net Full را ارجاع زد. نتیجه حتی از اجرای ASP.NET Core بر روی Full Dot Net Framework نیز بهتر است، بابت مزیتهای ذاتی طراحی Dot Net Core
فقط کسانی که نیاز به استفاده از WCF یا .NET Remoting یا Com Interop دارند، تحت تاثیر این تصمیم قرار میگیرند.
Can reference existing .NET Framework libraries. The best thing is no recompile required, so this includes existing NuGet packages. Of course, this will only work if the consumed libraries use APIs that exist in .NET Standard. However, our extensive API surface results in 70% of all NuGet packages to be API compatible with .NET Standard 2.0.