C# 8.0 - Async Streams
[HttpGet] public IAsyncEnumerable<Product> Get() => productsRepository.GetAllProducts();
مشاهدهی جزئیات اطلاعات سرور و بستههای نصب شدهی بر روی آن
در نگارشهای قبل از RTM، با فراخوانی app.UseRuntimeInfoPage در متد Configure کلاس Startup، ریز اطلاعاتی از وضعیت سرور و بستههای موجود در آن با مراجعهی به آدرس http://site/runtimeinfo نمایش داده میشدند. این مورد خاص از نگارش RTM حذف شدهاست (احتمالا به دلایل امنیتی). البته اگر علاقمند به بررسی کدهای آن باشید، هنوز تاریخچهی آن در GitHub موجود است .
مدیریت خطاها در برنامههای ASP.NET Core 1.0
به متد Configure کلاس Startup مراجعه کرد و یک سطر استثناء را به ابتدای کدهای Middleware انتهایی آن اضافه کنید:
public void Configure(IApplicationBuilder app) { app.Run(async context => { throw new Exception("Generic Error"); await context.Response.WriteAsync("Hello DNT!"); }); }
در این حالت اگر برنامه را اجرا کنیم، این خروجی را دریافت خواهیم کرد:
و اگر به وضعیت بازگشت داده شدهی از طرف سرور دقت کنیم، فقط internal server error است:
در اینجا برخلاف نگارشهای قبلی ASP.NET، دیگر حتی صفحهی زرد رنگ معروف نمایش خطاها (yellow screen of death) نیز فعال نیستند. برای فعال سازی آن نیاز است Middleware مرتبط با آنرا به نحو ذیل به برنامه معرفی کنیم:
public void Configure(IApplicationBuilder app) { app.UseDeveloperExceptionPage();
به دلایل امنیتی و عدم نشت اطلاعات سمت سرور و خصوصا عدم امکان دیباگ از راه دور برنامه توسط مهاجمین، این Middleware به صورت پیش فرض فعال نیست.
بنابراین این سؤال مطرح میشود که چگونه میتوان این صفحه را تنها در حین توسعهی برنامه نمایش داد؟
پاسخ آن به نحوهی طراحی متد Configure در کلاس Startup بر میگردد. این متد امضای ثابتی را ندارد. هر تعداد سرویسی را که نیاز داشتید، میتوانید به عنوان پارامتر این متد معرفی کنید و کار تزریق وابستگیها و نمونه سازی آنها، توسط امکانات توکار ASP.NET Core به صورت خودکار انجام میشود. برای مثال سرویس IApplicationBuilder، یکی از سرویسهای توکار ASP.NET Core است و برای تنظیم آن نیازی نیست تا کار خاصی را انجام دهیم. به همین جهت است که صرفا معرفی اینترفیس آن در این متد، وهلهای را از سازندهی برنامه در اختیار ما قرار میدهد. سرویسها را در مطلبی جداگانه مورد بررسی قرار خواهیم داد، اما فعلا جهت تکمیل بحث باید درنظر داشت که یکی دیگر از سرویسهای توکار ASP.NET Core، به نام IHostingEnvironment، اطلاعاتی را در مورد محیطی که برنامه را در آن اجرا میکنیم در اختیار ما قرار میدهد:
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
public void Configure(IApplicationBuilder app, IHostingEnvironment env) { if (env.IsDevelopment()) { app.UseDeveloperExceptionPage(); }
این متغیر محیطی میتواند سه مقدار Development, Staging و Production را داشته باشد و بر اساس این متغیر و مقدار آن است که یکی از سه متد ذیل مفهوم پیدا میکنند و true یا false را باز میگردانند:
if(env.IsDevelopment()){ } if(env.IsProduction()){ } if(env.IsStaging()){ }
نمایش و مدیریت خطاها در حالت Production
از app.UseDeveloperExceptionPage صرفا در حالت توسعه استفاده کنید؛ چون اطلاعات نمایش داده شدهی توسط آن، بیش از اندازه برای مهاجمین مفید است. اما در حالت توزیع نهایی بر روی سرور چه باید کرد؟
public void Configure(IApplicationBuilder app, IHostingEnvironment env) { if (env.IsDevelopment()) { app.UseDeveloperExceptionPage(); } else { app.UseExceptionHandler(errorHandlingPath: "/MyControllerName/SomeActionMethodName"); }
به علاوه در اینجا (در این قسمت خاص برنامه که توسط پارامتر errorHandlingPath مشخص شدهاست) با استفاده از قطعه کد ذیل، دسترسی کاملی را به اطلاعات خطای رخ داده، جهت ثبت و لاگ آن دارید:
var feature = HttpContext.Features.Get<IExceptionHandlerFeature>(); var error = feature?.Error;
بررسی میانافزار StatusCode
این میان افزار برای مدیریت responseهایی که status code آنها بین 400 تا 600 هستند، طراحی شدهاست. بر اساس این شمارهها، میتوان خطای خاصی را بازگشت داده و یا کاربر را به یک صفحه یا کنترلر خاصی در برنامه، هدایت کرد.
در حالت عادی ثبت آن
public void Configure(IApplicationBuilder app, IHostingEnvironment env) { if (env.IsDevelopment()) { app.UseStatusCodePages(); app.UseDeveloperExceptionPage(); } else { app.UseExceptionHandler(errorHandlingPath: "/MyControllerName/SomeActionMethodName"); } }
برای نمونه در اینجا مسیری درخواست داده شدهاست که توسط برنامه پردازش نمیشود و وجود ندارد.
اگر خواستید تا status code واقعی، به کاربر بازگشت داده شود، اما خروجی نمایش داده شده را سفارشی سازی کنید، میتوانید از متد UseStatusCodePagesWithReExecute استفاده نمائید:
app.UseStatusCodePagesWithReExecute("/MyControllerName/SomeActionMethodName/{0}");
- .NET Core is the future of .NET: If you’ve already started working with .NET Core, that’s great! If you’re starting a new project, you should consider .NET Core.
- .NET Framework will continue to be supported: If you have any existing applications on .NET Framework (Windows-only), you can keep those on .NET Framework.
- .NET Releases will become more predictable: Starting with .NET 5.0, there will be 1 major release every year, after which each even-numbered release (6.0, 8.0, etc) will come with LTS (Long-Term Support).
هرچند قرار است Visual Basic در NET 5x. حضور داشته باشد، اما این زبان دیگر به روز رسانی نخواهد شد
"Going forward, we do not plan to evolve Visual Basic as a language," the .NET team said. "This supports language stability and maintains compatibility between the .NET Core and .NET Framework versions of Visual Basic. Future features of .NET Core that require language changes may not be supported in Visual Basic. Due to differences in the platform, there will be some differences between Visual Basic on .NET Framework and .NET Core."
1.Visual Studio 2017 15.7 منتشر شد
These are the customer-reported issues addressed in 15.7.1:
- This release includes a fix that reduces memory usage and GC pressure during solution load.
Microsoft Security Advisory for .NET Core Denial Of Service Vulnerability
CVE-2018-0765
Microsoft is releasing this security advisory to provide information about a vulnerability in .NET Core and .NET native version 2.0. This advisory also provides guidance on what developers can do to update their applications to remove this vulnerability.
Microsoft is aware of a denial of service vulnerability that exists when .NET Framework and .NET Core improperly process XML documents. An attacker who successfully exploited this vulnerability could cause a denial of service against a .NET Framework, .NET Core, or .NET native application.
The update addresses the vulnerability by correcting how .NET Framework, .NET Core, and .NET native applications handle XML document processing.
If your application is an ASP.NET Core application, developers are also advised to update to ASP.NET Core 2.0.8.
در مطلب پیشنیاز فوق، تنظیمات روابط ارث بری را تا EF 6.x، میتوانید مطالعه کنید. در EF Core 1.0 RTM، فقط رابطهی TPH که در آن تمام کلاسهای سلسه مراتب ارث بری، به یک جدول در بانک اطلاعاتی نگاشت میشوند، پشتیبانی میشود. سایر روشهای ارث بری که در EF 6.x وجود دارند، مانند TPT و TPC، قرار است به نگارشهای پس از 1.0 RTM آن اضافه شوند:
- لیست مواردی که قرار است به نگارشهای بعدی اضافه شوند
- پیگیری وضعیت پیاده سازی TPT
- پیگیری وضعیت پیاده سازی TPC
طراحی یک کلاس پایه، بدون تنظیمات ارث بری روابط
مرسوم است که یک کلاس ویژه را به نام BaseEntity، به شکل زیر تعریف کنند؛ که اهدف آن حداقل سه مورد ذیل است:
الف) کاهش ذکر فیلدهای تکراری در سایر کلاسهای دومین برنامه، مانند فیلد Id
ب) نشانه گذاری موجودیتهای برنامه، جهت یافتن سریع آنها توسط Reflection (برای مثال افزودن خودکار موجودیتها به Context برنامه با یافتن تمام کلاسهایی که از نوع BaseEntity هستند)
ج) مقدار دهی خودکار یک سری از فیلدهای ویژه، مانند زمان افزوده شدن رکورد و آخرین زمان ویرایش شدن رکورد و امثال آن
public class BaseEntity { public int Id { set; get; } public DateTime? DateAdded { set; get; } public DateTime? DateUpdated { set; get; } }
public class Person : BaseEntity { public string FirstName { get; set; } public string LastName { get; set; } }
protected override void OnModelCreating(ModelBuilder modelBuilder) { modelBuilder.Ignore<BaseEntity>();
مشکل! اگر بر روی کلاس پایهی تعریف شده تنظیماتی را اعمال کنید (هر نوع تنظیمی را)، با توجه به فراخوانی متد Ignore، این تنظیمات نیز ندید گرفته خواهند شد.
اگر علاقمند بودید تا این تنظیمات را به تمام کلاسهای مشتق شدهی از BaseEntity به صورت خودکار اعمال کنید، روش کار به صورت ذیل است:
protected override void OnModelCreating(ModelBuilder modelBuilder) { modelBuilder.Ignore<BaseEntity>(); foreach (var entityType in modelBuilder.Model.GetEntityTypes()) { var dateAddedProperty = entityType.FindProperty("DateAdded"); dateAddedProperty.ValueGenerated = ValueGenerated.OnAdd; dateAddedProperty.SqlServer().DefaultValueSql = "getdate()"; var dateUpdatedProperty = entityType.FindProperty("DateUpdated"); dateUpdatedProperty.ValueGenerated = ValueGenerated.OnAddOrUpdate; dateUpdatedProperty.SqlServer().ComputedColumnSql = "getdate()"; }
خلاصهی آن نیز به این صورت است:
الف) نیازی نیست تا در حین ثبت اطلاعات موجودیتهای خود، فیلدهای DateAdded و یا DateUpdated را مقدار دهی کنید.
ب) فیلد DateAdded فقط در زمان اولین بار ثبت در بانک اطلاعاتی، به صورت خودکار توسط متد getdate مقدار دهی میشود.
ج) فیلد DateUpdated در هر بار فراخوانی متد SaveChanges (یعنی در هر دو حالت ثبت و یا به روز رسانی) به صورت خودکار توسط متد getdate مقدار دهی میشود.
تذکر! بدیهی است متد getdate، یک متد بومی سمت SQL Server است و این روش خاص تعیین مقدار پیش فرض فیلدها، فقط با SQL Server کار میکند. همچنین این getdate، به معنای دریافت تاریخ و ساعت سروری است که SQL Server بر روی آن نصب شدهاست و نه سروری که برنامهی وب شما در آن قرار دارد و برنامه کوچکترین دخالتی را در مقدار دهی این مقادیر نخواهد داشت.
در قسمتهای بعدی که مباحث Tracking را بررسی خواهیم کرد، روش دیگری را برای طراحی کلاسهای پایه و مقدار دهی خواص ویژهی آنها مطرح میکنیم که مستقل است از نوع بانک اطلاعاتی مورد استفاده.
بررسی تنظیمات رابطهی Table per Hierarchy یا TPH
رابطهی TPH یا تشکیل یک جدول بانک اطلاعاتی، به ازای تمام کلاسهای دخیل در سلسه مراتب ارث بری تعریف شده، بسیار شبیه است به حالت BaseEntity فوق که در آن نیز ارث بری تعریف شده، در نهایت منجر به تشکیل یک جدول، در سمت بانک اطلاعاتی میگردد. با این تفاوت که در حالت TPH، فیلد جدیدی نیز به نام Discriminator، به تعریف نهایی جدول ایجاد شده، اضافه میشود. از فیلد Discriminator جهت درج نام کلاسهای متناظر با هر رکورد، استفاده شده است. به این ترتیب EF در حین کار با اشیاء، دقیقا میداند که چگونه باید خواص متناظر با کلاسهای مختلف را مقدار دهی کند و نوع ردیف درج شدهی در بانک اطلاعاتی چیست؟
باید دقت داشت که تنظیمات TPH، شیوه برخورد پیش فرض EF Core با ارث بری کلاسها است و نیاز به هیچگونه تنظیم اضافهتری را ندارد. اما اگر علاقمند بودید تا نام فیلد خودکار Discriminator و مقادیری را که در آن درج میشوند، سفارشی سازی کنید، روش کار صرفا توسط Fluent API میسر است و به صورت زیر میباشد:
public class Blog { public int BlogId { get; set; } public string Url { get; set; } } public class RssBlog : Blog { public string RssUrl { get; set; } } class MyContext : DbContext { public DbSet<Blog> Blogs { get; set; } protected override void OnModelCreating(ModelBuilder modelBuilder) { modelBuilder.Entity<Blog>() .HasDiscriminator<string>("blog_type") .HasValue<Blog>("blog_base") .HasValue<RssBlog>("blog_rss"); } }
اگر این تنظیمات سفارشی صورت نگیرند، از نامهای پیش فرض نوعها برای مقدار دهی ستون Discriminator، مانند تصویر ذیل استفاده خواهد شد:
برای کوئری نوشتن در این حالت میتوان از متد الحاقی OfType جهت فیلتر کردن اطلاعات بر اساس کلاسی خاص، کمک گرفت:
var blog1 = db.Blogs.OfType<RssBlog>().FirstOrDefault(x => x.RssUrl == "………");
ایجاد یک ثبت کنندهی وقایع EF Core
مرحلهی اول مشاهدهی خروجیهای نهایی EF Core، پیاده سازی اینترفیس ILoggerProvider است که در آن قرار است وهلهی از نوع ILogger بازگشت داده شود. به همین جهت یک کلاس تو در توی خصوصی را در اینجا مشاهده میکنید که اینترفیس ILogger را نیز پیاده سازی کردهاست:
using System; using Microsoft.Extensions.Logging; namespace Tests { public class MyLoggerProvider : ILoggerProvider { public ILogger CreateLogger(string categoryName) { return new MyLogger(); } public void Dispose() { } private class MyLogger : ILogger { public bool IsEnabled(LogLevel logLevel) { return true; } public void Log<TState>( LogLevel logLevel, EventId eventId, TState state, Exception exception, Func<TState, Exception, string> formatter) { //File.AppendAllText(@"C:\temp\log.txt", formatter(state, exception)); Console.WriteLine(""); Console.WriteLine(formatter(state, exception)); } public IDisposable BeginScope<TState>(TState state) { return null; } } } }
در متد Log:
- پارامتر logLevel، سطح اهمیت اطلاعات رسیده را به همراه دارد. برای مثال اطلاعات است یا خطا؟
برای مثال شاید نیاز به ذخیره سازی اطلاعاتی با سطحهای بحرانی، خطا و یا اخطار در یک بانک اطلاعاتی وجود داشته باشد:
if (logLevel == LogLevel.Critical || logLevel == LogLevel.Error || logLevel == LogLevel.Warning)
- state: میتواند هر نوع شیءایی، حاوی اطلاعات وضعیت رخداد رسیده باشد.
- exception: بیانگر استثنای احتمالی رخ داده است.
- formatter: کار آن تولید یک رشتهی قابل خواندن، توسط اطلاعات حالت و استثناء است.
معرفی Logger تهیه شده به برنامه
پس از تهیهی Logger فوق، جهت معرفی آن به یک برنامهی کنسول، میتوان به صورت ذیل عمل کرد:
using (var db = new MyContext()) { var loggerFactory = (ILoggerFactory)db.GetInfrastructure().GetService(typeof(ILoggerFactory)); loggerFactory.AddProvider(new MyLoggerProvider()); }
در برنامههای ASP.NET Core، کار معرفی MyLoggerProvider در متد Configure کلاس آغازین برنامه انجام میشود:
public void Configure(ILoggerFactory loggerFactory) { loggerFactory.AddProvider(new MyLoggerProvider());
اختصاصی سازی ثبت وقایع رسیده
کلاس MyLoggerProvider، هر نوع اطلاعات داخلی EF Core را نیز لاگ میکند. اگر هدف صرفا بررسی خروجی SQL نهایی تولیدی است، میتوان در متد ذیل:
public ILogger CreateLogger(string categoryName)
برای این منظور، ابتدای Logger تهیه شده چنین شکلی را پیدا میکند:
using Microsoft.EntityFrameworkCore.Storage.Internal; using Microsoft.Extensions.Logging.Abstractions; using Microsoft.Extensions.Logging; using System.Linq; using System; namespace Tests { public class MyLoggerProvider : ILoggerProvider { private static readonly string[] _categories = { typeof(RelationalCommandBuilderFactory).FullName, typeof(SqlServerConnection).FullName }; public ILogger CreateLogger(string categoryName) { if (_categories.Contains(categoryName)) { return new MyLogger(); } return NullLogger.Instance; }