معرفی Response Cache
جایگزین ویژگی حذف شدهی OutputCache در ASP.NET Core، ویژگی جدیدی است به نام ResponseCache و هدف آن تنظیم هدرهای مرتبط با caching مخصوص HTTP Response ارائه شدهاست. به همین جهت با مکانیزم OutputCache قدیمی ASP.NET MVC که اطلاعات را در حافظهی سرور کش میکرد، کاملا متفاوت است.
البته قرار است میان افزار OutputCache را در نگارشهای آتی ASP.NET Core نیز ارائه کنند.
[ResponseCache(Duration = 60)] public IActionResult Contact() { ViewData["Message"] = "Your contact page."; return View(); }
Cache-Control: public,max-age=60
یک نکته: این ویژگی را هم میتوان به کل کنترلر اعمال کرد و هم به یک اکشن متد خاص. اگر این ویژگی هم به کنترلر و هم به اکشن متدی در آن کنترلر اعمال شده باشد، تنظیمات در سطح متدها، تنظیمات در سطح کلاس را بازنویسی میکنند.
تعیین مکان کش شدن خروجی یک اکشن متد
در هدر فوق، عبارت public را مشاهده میکنید. این public بودن به این معنا است که امکان کش شدن این خروجی، توسط کش سرورهای اشتراکی بین راه هم وجود دارد.
اگر میخواهید این امکان را غیرفعال کنید، نیاز است این public به private تنظیم شود:
[ResponseCache(Duration = 60, Location = ResponseCacheLocation.Client)]
غیرفعال کردن کش شدن خروجی یک اکشن متد
اگر خواستید از کش شدن خروجی یک اکشن متد تحت هر حالتی جلوگیری کنید، مکان آنرا به None و NoStore آنرا به true تنظیم کنید:
[ResponseCache(Location = ResponseCacheLocation.None, NoStore = true)] public IActionResult Error() { return View(); }
Cache-Control: no-store,no-cache Pragma: no-cache
امکان تعریف پروفایلهای کش
بجای اینکه تنظیمات کش کردن تکراری را به انواع و اقسام اکشن متدها اعمال کنیم، میتوان برای آنها پروفایل ایجاد کرده و از نام این پروفایل، جهت به اشتراک گذاری تنظیمات استفاده کنیم. برای این منظور به کلاس آغازین برنامه مراجعه کرده و جایی که سرویس ASP.NET MVC را فعال سازی کردهاید، پروفایل کش جدیدی را تعریف کنید:
public void ConfigureServices(IServiceCollection services) { services.AddMvc(options => { options.CacheProfiles.Add("PrivateCache", new CacheProfile { Duration = 60, Location = ResponseCacheLocation.Client }); });
[ResponseCache(CacheProfileName = "PrivateCache")]
معرفی سرویس کش درون حافظهای
در نگارشهای پیشین ASP.NET، متدهایی برای کش کردن موقتی اطلاعات در حافظه و سپس بازیابی آنها وجود داشتند. در ASP.NET Core، این متدها توسط سرویس ارائه کنندهی IMemoryCache در اختیار برنامه قرار میگیرند. برای فعال سازی این سرویس جدید باید مراحل ذیل طی شوند:
الف) ابتدا بستهی Microsoft.Extensions.Caching.Memory را به لیست وابستگیهای پروژه در فایل project.json اضافه کنید:
{ "dependencies": { //same as before "Microsoft.Extensions.Caching.Memory": "1.0.0" },
public void ConfigureServices(IServiceCollection services) { services.AddMemoryCache();
[Route("DNT/[controller]")] public class AboutController : Controller { private readonly IMemoryCache _memoryCache; public AboutController(IMemoryCache memoryCache) { _memoryCache = memoryCache; } [Route("")] public ActionResult Hello() { string cacheKey = "my-cache-key"; string greeting; if (!_memoryCache.TryGetValue(cacheKey, out greeting)) { greeting = "Hello"; // store in the cache _memoryCache.Set(cacheKey, greeting, new MemoryCacheEntryOptions() .SetAbsoluteExpiration(TimeSpan.FromMinutes(1))); } return Content($"{greeting} from DNT!"); }
تنظیمات منقضی شدن کش نیز به حالت absolute تنظیم شدهاست. یعنی پس از یک دقیقه حتما منقضی میشود. اگر فراخوانیهای این متد زیاد است، میتوان حالت منقضی شدن sliding را تنظیم کرد:
new MemoryCacheEntryOptions() .SetSlidingExpiration(TimeSpan.FromMinutes(5))
اگر خواستیم تا این کش سر ساعت منقضی شود، اما در طی این یک ساعت به صورت sliding عمل کند، میتوان از ترکیب دو حالت مطلق و لغزشی استفاده کرد:
new MemoryCacheEntryOptions() .SetSlidingExpiration(TimeSpan.FromMinutes(5)) .SetAbsoluteExpiration(TimeSpan.FromHours(1))
یک نکته: اگر فشار حافظهی سرور زیاد شود، مدیر حافظهی این کش، شروع به منقضی کردن آیتمهایی با حق تقدم پایین میکند. بالاترین حق تقدم را حالت NeverRemove ذیل دارد:
new MemoryCacheEntryOptions() .SetPriority(CacheItemPriority.NeverRemove))
معرفی Tag Helpers مخصوص کش کردن قسمتی از صفحه
در ادامهی مبحث معرفی Tag Helpers، تعدادی از آنها جهت کش کردن محتوای قسمتی از صفحه، طراحی شدهاند:
<cache expires-after="@TimeSpan.FromMinutes(10)"> @Html.Partial("_WhatsNew") *last updated @DateTime.Now.ToLongTimeString() </cache>
برای نمونه در مثال فوق، محتوای پارشال ویوو رندر شده و همچنین تاریخی که پس از آن نمایش داده شدهاست، به مدت 10 دقیقه در حافظهی سرور کش میشوند. اگر این زمان تنظیم نشود، تا زمانیکه برنامه در سرور مشغول به کار است، این قسمت منقضی نخواهد شد.
در اینجا اگر expires-after ذکر شده بود، یعنی پس از این مدت زمان، کش منقضی میشود.
<cache expires-after="@TimeSpan.FromSeconds(5)"> <!--View Component or something that gets data from the database--> *last updated @DateTime.Now.ToLongTimeString() </cache>
<cache expires-on="@DateTime.Today.AddDays(1).AddTicks(-1)"> <!--View Component or something that gets data from the database--> *last updated @DateTime.Now.ToLongTimeString() </cache>
<cache expires-sliding="@TimeSpan.FromMinutes(5)"> <!--View Component or something that gets data from the database--> *last updated @DateTime.Now.ToLongTimeString() </cache>
<cache vary-by-user="true"> <!--View Component or something that gets data from the database--> *last updated @DateTime.Now.ToLongTimeString() </cache>
<cache vary-by-route="id"> <!--View Component or something that gets data from the database--> *last updated @DateTime.Now.ToLongTimeString() </cache>
<cache vary-by-query="search"> <!--View Component or something that gets data from the database--> *last updated @DateTime.Now.ToLongTimeString() </cache>
<cache vary-by-cookie="MyAppCookie"> <!--View Component or something that gets data from the database--> *last updated @DateTime.Now.ToLongTimeString() </cache>
<cache vary-by-header="User-Agent"> <!--View Component or something that gets data from the database--> *last updated @DateTime.Now.ToLongTimeString() </cache>
<cache vary-by="@ViewBag.ProductId"> <!--View Component or something that gets data from the database--> *last updated @DateTime.Now.ToLongTimeString() </cache>
<cache vary-by-user="true" vary-by-route="id"> <!--View Component or something that gets data from the database--> *last updated @DateTime.Now.ToLongTimeString() </cache>
به علاوه چون زیر ساخت این Tag Helper همان Microsoft.Extensions.Caching.Memory است، امکان تنظیم حق تقدم حذف شدن آیتمهای کش شده نیز وجود دارد:
<cache expires-sliding="@TimeSpan.FromMinutes(10)" priority="@Microsoft.Extensions.Caching.Memory.CacheItemPriority.NeverRemove"> <!--View Component or something that gets data from the database--> *last updated @DateTime.Now.ToLongTimeString() </cache>
مبحث تکمیلی
امکان ذخیره سازی آیتمهای کش شده در بانک اطلاعاتی (بجای حافظهی فرار) نیز پیش بینی شدهاست که تحت عنوان «کش توزیع شده» در دسترس است.
Working with a Distributed Cache
اگر با وب فرمها کار کرده باشید، حتما با تنظیم زیر در فایل web.config برنامههای وب آشنا هستید:
<pages validaterequest="false"></pages>
Request Validation قابلیتی است که از زمان ASP.NET 1.1 وجود داشتهاست و توسط آن اگر اطلاعات دریافتی از کاربر به همراه تگهای HTML و یا کدهای JavaScript ای باشد، خطرناک تشخیص داده شده و با ارائهی پیام خطایی (مانند تصویر فوق)، پردازش درخواست متوقف میشود. این اعتبارسنجی بر روی هدرها، کوئری استرینگها، بدنهی درخواست و کوکیها صورت میگیرد. هدف آن نیز به حداقل رساندن امکان حملات Cross-Site Scripting و یا XSS است.
محدودیتهای اعتبارسنجی درخواستها
هر چند Request validation یک ویژگی و امکان جالب است، اما ... در عمل راهحل جامعی نیست و تنها اگر کاربر تگهای HTML ای را ارسال کند، متوجه وجود یک خطر احتمالی میشود. برای مثال اگر این اطلاعات خطرناک به نحو دیگری در قسمتهای مختلفی مانند attributeها، CSSها و غیره نیز تزریق شوند، عکس العملی را نشان نخواهد داد. به علاوه اگر این نوع حملات به همراه ترکیب آنها با روشهای Unicode نیز باشد، میتوان این اعتبارسنجی را دور زد.
اعتبارسنجی خودکار درخواستها و حس کاذب امنیت
متاسفانه وجود اعتبارسنجی خودکار درخواستها سبب این توهم میشود که برنامه در مقابل حملات XSS امن است و بالاخره این قابلیت توسط مایکروسافت در برنامه قرار داده شدهاست و ما هم به آن اطمینان داریم. اما با توجه به نحوهی پیاده سازی و محدودیتهای یاد شدهی آن، این قابلیت صرفا یک لایهی بسیار ابتدایی اعتبارسنجی اطلاعات ارسالی به سمت سرور را شامل میشود و بررسی تمام حالات حملات XSS را پوشش نمیدهد (اگر علاقمند هستید که بدانید چه بازهای از این حملات ممکن هستند، آزمونهای واحد کتابخانهی HtmlSanitizer را بررسی کنید).
پایان اعتبارسنجی درخواستها در ASP.NET Core
طراحان ASP.NET Core تصمیم گرفتهاند که یک چنین قابلیتی را به طور کامل از ASP.NET Core حذف کنند؛ چون به این نتیجه رسیدهاند که ... ایدهی خوبی نبوده و در اکثر مواقع برنامه نویسها کاملا آنرا خاموش میکنند (مانند مثالهای وب فرم و MVC فوق). اعتبارسنجی درخواستها مشکل یک برنامه است و مراحل و سطوح آن از هر برنامه، به برنامهی دیگری بر اساس نیازمندیهای آن متفاوت است. به همین جهت تعیین اجباری اعتبارسنجی درخواستها در نگارشهای قبلی ASP.NET سبب شدهاست که عملا برنامه نویسها با آن کار نکنند. بنابراین در اینجا دیگر خبری از ویژگیهای ValidateInput و یا AllowHtml و یا مانند وب فرمها و HTTP Module مخصوص آن، به همراه یک میانافزار تعیین اعتبار درخواستها نیست.
اکنون برای مقابله با حملات XSS در کدهای سمت سرور برنامههای ASP.NET Core چه باید کرد؟
در ASP.NET Core، کار مقابلهی با حملات XSS، از فریمورک، به خود برنامه واگذار شدهاست و در اینجا شما بر اساس نیازمندیهای خود تصمیم خواهید گرفت که تا چه حدی و چه مسایلی را کنترل کنید. برای این منظور در سمت سرور، استفادهی ترکیبی از سه روش زیر توصیه میشود:
الف) تمیز کردن اطلاعات ورودی رسیدهی از کاربران توسط کتابخانههایی مانند HtmlSanitizer
ب) محدود کردن بازهی اطلاعات قابل قبول ارسالی توسط کاربران
[Required] [StringLength(50)] [RegularExpression(@"^[a-zA-Z0-9 -']*$")] public string Name {get;set;}
پی نوشت: برای داشتن نیوگت شخصی سایتهای نظیر Nuget Server و Myget ( به همراه پشتیبانی از مخازن npm و Bower ) هم این سرویس را ارائه میکنند. ولی باید هزینهی آن را پرداخت کنید. البته سایت GemFury مخازن رایگان مختلفی چون Nuget را نیز پشتیبانی میکند.
نصب بر روی یک سیستم شخصی یا لوکال
در اولین قدم، شما باید یک دایرکتوری را در سیستم خود درست کنید تا پکیجهای خود را داخل آن قرار دهید. پنجرهی Package manager Settings را باز کنید و در آن گزینهی Package Sources را انتخاب کنید. سپس در کادر باز شده، بر روی دکمهی افزودن، در بالا کلیک کنید تا در پایین کادر، از شما نام محل توزیع بسته و آدرس آن را بپرسد:
بعد از ورود اطلاعات، بر روی دکمهی Update کلیک کنید. از این پس این دایرکتوری، منبع پکیجهای شماست و برای دریافت پکیجها از این آدرس میتوانید از طریق منوی کشویی موجود در کنسول، پکیج جدید خودتان را انتخاب کنید:
اگر میخواهید میتوانید این دایرکتوری را به اشتراک بگذارید تا دیگر افراد حاضر در شبکهی محلی هم بتوانند آن را به عنوان منبع توزیع خود به سیستم اضافه کنند.
مرحلهی بعدی این است که از طریق ابزار خط فرمان نیوگت نسخه 3.3 پکیجهایتان را به دایرکتوری مربوطه انتقال دهید. نحوهی صدا زدن این دستور به شکل زیر است:
nuget init e:\nuget\ e:\nuget\test
nuget add GMap.Net.1.0.1.nupkg -source e:\nuget\test
ساخت منبع راه دور (اینترنت)
شما با استفاده از ویژوال استودیو و انجام چند عمل ساده میتوانید پکیجهای خودتان را مدیریت کنید. برای شروع، یک پروژهی تحت وب خام (Empty) را ایجاد کنید و در کنسول Nuget دستور زیر را وارد کنید:
Install-Package NuGet.Server
<appSettings> <!-- Set the value here to specify your custom packages folder. --> <add key="packagesPath" value="×\Packages" /> </appSettings>
(هر محلی که نصب کنید طبق الگوی مسیریابی، آدرس nuget را در انتها وارد کنید)
Dotnettips.info/nuget
در صورتی که قصد دارید مستقیما بستهای را به سمت سرور push کنید، از یک رمز عبور قدرتمند که آن را میتوانید در web.config، بخش apiKey وارد نمایید، استفاده کنید. اگر هم نمیخواهید، میتوانید در تگ RequiredApiKey در خصوصیت Value، مقدار false را وارد نمایید.
برای اینکار میتوانید از دستور زیر استفاده کنید:
nuget push GMap.Net.1.0.1.nupkg -source http://Dotenettips.info/nuget (ApiKey)
nuget setapikey -source https://www.dntips.ir/Nuget (ApiKey)
دسته بندی کردن لاگها در Serilog
app.Use(async (httpContext, next) => { //Get username var username = httpContext.User.Identity.IsAuthenticated ? httpContext.User.Identity.Name : "anonymous"; using (LogContext.PushProperty("User", username)) { //Get remote IP address var ip = httpContext.Connection.RemoteIpAddress.ToString(); using (LogContext.PushProperty("IP", !String.IsNullOrWhiteSpace(ip) ? ip : "unknown")) { await next.Invoke(); } } });
پیش فرضهای تعیین کلید اصلی در EF Core
به صورت پیش فرض هر خاصیتی که به نام Id و یا type name>Id> باشد، به عنوان primary key تفسیر خواهد شد؛ مانند:
public class Car { public string Id { get; set; }
public class Car { public string CarId { get; set; }
نحوهی تعیین کلید اصلی به صورت صریح
اگر یکی از دو حالت فوق برقرار نباشند، باید کلید اصلی را به نحو صریحی مشخص کرد.
الف) از طریق ویژگیها
public class Car { [Key] public string LicensePlate { get; set; }
ب) با استفاده از روش Fluent API
public class MyContext : DbContext { public DbSet<Car> Cars { get; set; } protected override void OnModelCreating(ModelBuilder modelBuilder) { modelBuilder.Entity<Car>() .HasKey(c => c.LicensePlate); } }
پیشنیاز کار با ویژگیها در EF Core
در اسمبلی که مدلهای موجودیتها شما قرار دارند، نیاز است وابستگی System.ComponentModel.Annotations به فایل project.json پروژه اضافه شود، تا ویژگیهایی مانند Key، شناسایی و قابل استفاده شوند:
{ "dependencies": { "System.ComponentModel.Annotations": "4.1.0" } }
تعیین کلید ترکیبی و یا Composite key
اگر نیاز است چندین خاصیت را به صورت کلید اصلی معرفی کرد که به آن composite key هم میگویند، تنها روش ممکن، استفاده از Fluent API و به صورت زیر است:
protected override void OnModelCreating(ModelBuilder modelBuilder) { modelBuilder.Entity<Car>() .HasKey(c => new { c.State, c.LicensePlate }); }
روشهای مختلف تولید خودکار مقادیر خواص
حالت پیش فرض تولید مقدار فیلدهای Id عددی، همان حالت خود افزایندهای است که توسط بانک اطلاعاتی کنترل میشود و یا کلید اصلی که از نوع Guid تعیین شود نیز به صورت خودکار توسط بانک اطلاعاتی در حین عملیات Add، مقدار دهی میشود (با استفاده از الگوریتم Guid سری در SQL Server).
اگر این حالات مطلوب شما نیست، حالتهای سه گانهی ذیل را میتوان استفاده کرد:
الف) هیچ دادهی خودکاری تولید نشود
برای اینکار میتوان با استفاده از ویژگی DatabaseGenerated و تنظیم مقدار آن به None، جلوی تولید خودکار کلید اصلی را گرفت. در این حالت باید هم در حین عملیات Add و هم در حین عملیات Update، مقادیر را خودتان مقدار دهی کنید:
public class Blog { [DatabaseGenerated(DatabaseGeneratedOption.None)] public int BlogId { get; set; } public string Url { get; set; } }
protected override void OnModelCreating(ModelBuilder modelBuilder) { modelBuilder.Entity<Blog>() .Property(b => b.BlogId) .ValueGeneratedNever(); }
ب) تولید دادههای خودکار فقط در حالت Add
حالت Add به این معنا است که دادههای خواص مشخصی، برای موجودیتهای «جدید»، به صورت خودکار تولید خواهند شد. اینکه آیا واقعا این مقادیر به صورت خودکار تولید میشوند یا خیر، صرفا وابستهاست به بانک اطلاعاتی در حال استفاده. برای مثال SQL Server برای نوعهای Guid، به صورت خودکار با کمک الگوریتم SQL Server sequential GUID، کار مقدار دهی یک چنین فیلدهایی را انجام میدهد.
این فیلدها باید توسط ویژگی DatabaseGenerated و با مقدار Identity مشخص شوند. در اینجا Identity به معنای فیلدهایی است که به صورت خودکار توسط بانک اطلاعاتی مقدار دهی میشوند و الزاما به کلید اصلی اشاره نمیکنند. برای مثال در موجودیت ذیل، خاصیت تاریخ ثبت رکورد، از نوع Identity مشخص شدهاست. به این معنا که در حین ثبت اولیهی رکورد آن، نیازی نیست تا خاصیت Inserted را مقدار دهی کرد. اما اینکه آیا SQL Server یک چنین کاری را به صورت خودکار انجام میدهد، پاسخ آن خیر است. SQL server فقط برای فیلدهای عددی و Guid ایی که با DatabaseGeneratedOption.Identity مزین شده باشند، مقادیر متناظری را به صورت خودکار تولید میکند. برای حالت DateTime نیاز است، مقدار پیش فرض فیلد را صریحا مشخص کرد که توسط ویژگیها میسر نیست و فقط fluent API از آن پشتیبانی میکند.
public class Blog { public int BlogId { get; set; } public string Url { get; set; } [DatabaseGenerated(DatabaseGeneratedOption.Identity)] public DateTime Inserted { get; set; } }
protected override void OnModelCreating(ModelBuilder modelBuilder) { modelBuilder.Entity<Blog>() .Property(b => b.Inserted) .ValueGeneratedOnAdd(); }
protected override void OnModelCreating(ModelBuilder modelBuilder) { modelBuilder.Entity<Blog>() .Property(b => b.Inserted) .HasDefaultValueSql("getdate()"); }
یک نکته: در حالت DatabaseGeneratedOption.Identity و یا ValueGeneratedOnAdd فوق، اگر مقداری به این نوع فیلدها انتساب داده شده باشد که با مقدار پیش فرض آنها (property.ClrType.GetDefaultValue) متفاوت باشد، از این مقدار جدید، بجای تولید مقداری خودکار، استفاده خواهد شد. برای مثال مقدار پیش فرض رشتهها، نال، مقادیر عددی، صفر و برای Guid مقدار Guid.Empty است. اگر هر مقدار دیگری بجای اینها به فیلدهای فوق انتساب داده شوند، از آنها استفاده میشود.
ج) تولید دادههای خودکار در هر دو حالت Add و Update
تولید دادهها در حالتهای Add و Update به این معنا است که یک چنین خواصی، همواره با فراخوانی متد SaveChanges، دارای مقدار خودکار جدیدی خواهند شد و نیازی نیست در کدها مقدار دهی شوند. برای مشخص سازی این نوع خواص، از ویژگی DatabaseGenerated با مقدار Computed و یا متد ValueGeneratedOnAddOrUpdate در حالت Fluent API میتوان استفاده کرد:
public class Blog { public int BlogId { get; set; } public string Url { get; set; } [DatabaseGenerated(DatabaseGeneratedOption.Computed)] public DateTime LastUpdated { get; set; } }
protected override void OnModelCreating(ModelBuilder modelBuilder) { modelBuilder.Entity<Blog>() .Property(b => b.LastUpdated) .ValueGeneratedOnAddOrUpdate(); }
تذکر: در اینجا نیز همانند حالت ValueGeneratedOnAdd، اگر این خواص مشخص شده، دارای مقدار متفاوتی با مقدار پیش فرض آنها باشند، از این مقادیر جدید بجای تولید خودکار مقادیر استفاده خواهد شد.
خواص محاسباتی (Computed Columns) و تفاوت آنها با DatabaseGeneratedOption.Computed
خواص محاسباتی (Computed Columns)، خواصی هستند که مقادیر آنها در بانک اطلاعاتی محاسبه میشوند و کاملا متفاوت هستند با DatabaseGeneratedOption.Computed که مفهوم دیگری دارد. DatabaseGeneratedOption.Computed به این معنا است که این فیلد خاص، با هر بار فراخوانی SaveChanges باید مقدار محاسبه شدهی جدیدی را داشته باشد و روش تولید این مقدار خودکار، یا بر اساس Guidهای سری است، یا توسط فیلدهای خود افزایندهی عددی و یا از طریق مقادیر پیش فرضی مانند getdate در حین ثبت یا به روز رسانی، مقدار دهی میشوند. اما خواص محاسباتی، یکی از امکانات «گزارشگیری سریع» SQL Server هستند و به نحو ذیل، تنها توسط Fluent API قابل تنظیم میباشند:
public class Person { public int PersonId { get; set; } public string FirstName { get; set; } public string LastName { get; set; } public string DisplayName { get; set; } } public class MyContext : DbContext { public DbSet<Person> People { get; set; } protected override void OnModelCreating(ModelBuilder modelBuilder) { modelBuilder.Entity<Person>() .Property(p => p.DisplayName) .HasComputedColumnSql("[LastName] + ', ' + [FirstName]"); } }
امکان تعریف Sequence در EF Core 1.0
Sequence قابلیتی است که به SQL Server 2012 اضافه شدهاست و توضیحات بیشتر آنرا در مطلب «نحوه ایجاد Sequence و استفاده آن در Sql Server 2012» میتوانید مطالعه کنید.
در EF Core، امکان مدلسازی Sequence نیز پیش بینی شدهاست. آنها به صورت پیش فرض در مدلها ذکر نمیشوند و همچنین وابستگی به جدول خاصی ندارند. به همین جهت امکان تعریف آنها صرفا توسط Fluent API وجود دارد:
protected override void OnModelCreating(ModelBuilder modelBuilder) { modelBuilder.HasSequence<int>("OrderNumbers", schema: "shared") .StartsAt(1000).IncrementsBy(5); modelBuilder.Entity<Order>() .Property(o => o.OrderNo) .HasDefaultValueSql("NEXT VALUE FOR shared.OrderNumbers"); }
در مثال فوق، ابتدا یک Sequence نمونه به نام OrderNumbers تعریف شدهاست که از عدد 1000 شروع شده و واحد افزایش آن 5 است. سپس از این نام در قسمت مقدار پیش فرض ستون OrderNo استفاده شدهاست.
و یا از Sequence ها میتوان برای تعیین مقدار پیش فرض Primary key بجای حالت identity خود افزایش یابنده استفاده کرد:
protected override void OnModelCreating(ModelBuilder modelBuilder) { modelBuilder.HasSequence<int>("PrimaryKeyWithSequenceSequence"); modelBuilder.Entity<PrimaryKeyWithSequence>(entity => { entity.Property(e => e.PrimaryKeyWithSequenceId).HasDefaultValueSql("NEXT VALUE FOR [PrimaryKeyWithSequenceSequence]"); }); }
[PrimaryKeyWithSequenceSequence] دریافت و سپس بجای فیلد id درج میشود.
به این روش الگوریتم Hi-Low هم میگویند که یکی از مهمترین اهداف آن داشتن یک سری Id منحصربفرد، جهت بالابردن سرعت insertها در یک batch است. در حالت عادی insertها، ابتدا یک insert انجام میشود، سپس کوئری گرفته شده و آخرین Id درج شده به کلاینت بازگشت داده میشود. این روش، برای انجام تنها یک insert، سریع است. اما برای batch insert، به شدت کارآیی پایینی دارد. به همین جهت دسترسی به بازهای از اعداد منحصربفرد، پیش از شروع به insert تعداد زیادی رکورد، سرعت نهایی کار را بالا میبرد.
نحوهی تعریف ایندکسها در EF Core 1.0
برای افزودن ایندکسها به EF Core 1.0، تنها روش میسر، استفاده از Fluent API است (و برخلاف EF 6.x از روش data annotations فعلا پشتیبانی نمیکند؛ هرچند API جدید آن نسبت به EF 6.x بسیار واضحتر است و با ابهامات کمتر).
protected override void OnModelCreating(ModelBuilder modelBuilder) { modelBuilder.Entity<Blog>() .HasIndex(b => b.Url) .HasName("Index_Url");
modelBuilder.Entity<Blog>().HasIndex(b => b.Url).HasName("Index_Url").IsUnique();
modelBuilder.Entity<Person>() .HasIndex(idx => new { idx.FirstName, idx.LastName }) .IsUnique();
یک نکته: اگر از پروایدر SQL Server استفاده میکنید، میتوان متد الحاقی ویژهای را به نام ForSqlServerIsClustered نیز برای تعریف clustered indexes، در این زنجیره ذکر کرد.
امکان تعریف Alternate Keys در EF Core 1.0
به Unique Constraints در EF Core، نام Alternate Keys را دادهاند و این مورد نیز تنها از طریق Fluent API قابل تنظیم است:
protected override void OnModelCreating(ModelBuilder modelBuilder) { modelBuilder.Entity<Car>() .HasAlternateKey(c => c.LicensePlate) .HasName("AlteranteKey_LicensePlate"); }
اگر متد HasName در اینجا ذکر نشود، نام پیش فرض آن <type name>_<property name> خواهد بود و اگر همانند composite keys و یا ایندکسهای ترکیبی، چند خاصیت ذکر شوند، قسمت property name به جمع نام تمام خواص ذکر شده و جدا شدهی با _ تنظیم میشود.
برای نمونه اگر یک Alternate Key ترکیبی را به صورت ذیل تعریف کنیم:
modelBuilder.Entity<Person>() .HasAlternateKey(x => new { x.FirstName, x.LastName });
table.UniqueConstraint("AK_Persons_FirstName_LastName", x => new { x.FirstName, x.LastName });
سؤال: یک Unique Constraint با Unique Index چه تفاوتی دارد؟
در پشت صحنه، پیاده سازی یک Unique Constraint با Unique Index تفاوتی ندارند. فقط از دیدگاه روشنتر شدن مقصود، استفادهی از Unique Constraint ترجیح داده میشود.
البته از دیدگاه بانک اطلاعاتی پیاده سازی کننده نیز برای نمونه SQL Server، این تفاوتها وجود دارند:
الف) یک Unique Constraint را نمیتوان غیرفعال کرد؛ برخلاف Unique Indexها.
ب) Unique Constraintها موارد اضافهتری را مانند FILLFACTOR و IGNORE_DUP_KEY نیز میتوانند تنظیم کنند.
ج) امکان تعریف فیلترها برای Unique Indexها وجود دارد؛ برخلاف Unique Constraint ها.
که البته از دیدگاه EF، این سه مورد اهمیتی ندارند و بیشتر روشنتر شدن مقصود، هدف اصلی آنها است.
زبان تلگرام TL هست و تقریبا میشه گفت زبان پیچیده ای هست و همه چیز با عدد و رقم پیش میره، اما برای سی شارپ کتابخانه ای آماده شده به نام TLSharp وجود داره که توابع عمومی تقریبا پیاده سازی کرده. میتونین ازش ایده بگیرین و کارهای خودتون به پروزه تون اضافه کنید.
لیست APIهای تلگرام هم میتونین اینجاپیدا کنید.
تولید خودکار کدها بر اساس OpenAPI Specification
فرض کنید در حال توسعهی برنامهی سمت کلاینت Angular و یا سمت سرور ASP.NET Core ای هستید که هر دوی اینها از یک Web API استفاده میکنند. همچنین فرض کنید که این Web API را نیز خودتان توسعه میدهید. بنابراین حداقل کدی که باید در اینجا به اشتراک گذاشته شود، کدهای کلاسهای DTO یا Data transfer objects هستند تا این کلاینتها بتوانند اطلاعات Web API را به نحو صحیحی Deserialize کنند و یا برعکس، بتوانند اطلاعات را با فرمت صحیحی به سمت Web API ارسال کنند.
برای مدیریت این مساله میتوان از دو روش استفاده کرد:
الف) استفاده از یک پروژهی اشتراکی
اگر کدهای مدنظر، سمت سرور باشند، میتوان یک پروژهی اشتراکی را برای این منظور ایجاد کرد و کدهای DTO را درون آن قرار داد و سپس ارجاعی به آن را در پروژههای مختلف، استفاده نمود. به این ترتیب تکرار کدها، کاهش یافته و همچنین تغییرات آن نیز به تمام پروژههای استفاده کننده به نحو یکسانی اعمال میشوند. در این حالت یک اسمبلی اشتراکی تولید شده و به صورت مستقلی توزیع میشود.
ب) استفاده از روش لینک کردن فایلها
در این روش پروژههای استفاده کننده از کلاسهای DTO، فایلهای آنرا به پروژهی خود لینک میکنند. در این حالت باز هم شاهد کاهش تکرار کدها و همچنین اعمال یک دست تغییرات خواهیم بود. اما در این روش دیگر یک اسمبلی اشتراکی وجود نداشته و کلاسهای DTO هم اکنون با اسمبلی پروژههای استفاده کننده، یکی و کامپایل شدهاند.
بدیهی است در هر دو روش، نیاز است بر روی کلاینت و API، کنترل کاملی وجود داشته باشد و بتوان به کدهای آنها دسترسی داشت. به علاوه فایلهای اشتراکی نیز باید بر اساس Target platform یکسانی تولید شده باشند. در این حالت دیگر نیازی به OpenAPI Specification برای تولید کدهای کلاینت دات نتی خود، نیست.
اما اگر کدهای API مدنظر در دسترس نباشند و یا بر اساس پلتفرم دیگری مانند node.js تولید شده باشد، کار یکپارچه سازی با آن دیگر با به اشتراک گذاری فایلهای آن میسر نیست. در این حالت اگر این API به همراه یک OpenAPI Specification باشد، میتوان از آن برای تولید خودکار کدهای کلاینتهای آن استفاده کرد.
معرفی تعدادی از ابزارهایی که قادرند بر اساس OpenAPI Specification، کد تولید کنند
برای تولید کد از روی OpenAPI Specification، گزینههای متعددی در دسترس هستند:
الف) Swagger CodeGen
این ابزار را که جزئی از مجموعه ابزارهای تولید شدهی برفراز OpenAPI است، میتوانید از آدرس swagger-codegen دریافت کنید. البته برای اجرای آن نیاز به Java Runtime است و یا نگارش آنلاین آن نیز در دسترس است: swagger.io
در ابزار آنلاین آن، در منوی generate بالای صفحه، گزینهی تولید کد برای #C نیز موجود است.
ب) AutoRest
محل دریافت: https://github.com/Azure/autorest
بر اساس node.js کار میکند و از طریق خط فرمان، قابل دسترسی است. همچنین این مورد ابزار تامین کنندهی گزینهی Add REST client در ویژوال استودیو نیز میباشد. اما در کل، امکان تنظیمات آنچنانی را به همراه ندارد.
ج) NSwagStudio
محل دریافت: https://github.com/RSuter/NSwag/wiki/NSwagStudio
همانطور که در مطلب «مستند سازی ASP.NET Core 2x API توسط OpenAPI Swagger - قسمت اول - معرفی» نیز عنوان شد، NSwag یکی دیگر از تولید کنندههای OpenAPI Specification مخصوص پروژههای دات نت است. NSwagStudio نیز جزئی از این مجموعه است که به کمک آن میتوان کدهای کلاینتها و DTOها را بر اساس OpenAPI Spec تولید کرد. همچنین امکان تنظیمات قابل توجهی را در مورد نحوهی تولید کدهای نهایی به همراه دارد.
استفاده از NSwagStudio برای تولید کدهای DTOها
در اینجا از همان برنامهای که در سری «مستند سازی ASP.NET Core 2x API توسط OpenAPI Swagger» بررسی کردیم، استفاده خواهیم کرد. بنابراین این برنامه، از پیش تنظیم شدهاست و هم اکنون به همراه یک تولید کنندهی OpenAPI Specification نیز میباشد. آنرا اجرا کنید تا بتوان به OpenAPI Specification تولیدی آن در آدرس زیر دسترسی یافت:
https://localhost:5001/swagger/LibraryOpenAPISpecification/swagger.json
مطابق تصویر، ابتدا آدرس Swagger Specification URL یا همان آدرس فوق را وارد کنید. سپس فضای نام دلخواهی را وارد کرده و گزینهی تولید کلاسهای کلاینت را فعلا انتخاب نکنید. در لیست تنظیمات آن، گزینهی Class Style نیز مهم است. برای مثال برای پروژههای ASP.NET Core حالت POCO را انتخاب کنید (plain old clr objects) و برای پروژههای مبتنی بر XAML، گزینهی Inpc مناسبتر است چون RaisePropertyChangedها را هم تولید میکند. در آخر بر روی دکمهی Generate Outputs کلیک کنید تا خروجی ذیل حاصل شود:
یا میتوان این خروجی را copy/paste کرد و یا میتوان در برگهی Settings، در انتهای لیست آن، مقدار output file path را مشخص کرد و سپس بر روی دکمهی Generate files کلیک نمود تا فایل معادل آن تولید شود.
استفاده از NSwagStudio برای تولید کدهای کلاینت Angular استفاده کنندهی از API
NSwagStudio امکان تولید یک TypeScript Client را نیز دارد:
در اینجا ابتدا TypeScript Client را انتخاب میکنیم و سپس در تنظیمات آن، قالب Angular را انتخاب کرده و نگارش RxJS آنرا نیز، 6 انتخاب میکنیم. در آخر بر روی Generate outputs کلیک میکنیم:
نکتهی جالب این خروجی، دقت داشتن به status codes درج شدهی در OpenAPI Spec است که در قسمتهای چهارم و پنجم سری «مستند سازی ASP.NET Core 2x API توسط OpenAPI Swagger» آنها را بررسی کردیم.
در اینجا نه تنها سرویسی جهت تعامل با API ما تولید شدهاست، بلکه معادل تایپاسکریپتی DTOهای برنامه را نیز تولید کردهاست:
سرفصلها
00:00:00 reactjs چیست؟ ری اکت جی اس به زبان ساده
00:04:57 نصب و راه اندازی reactjs
00:19:36 React Componnet, props and JSX
00:39:40 conditional rendering
01:07:46 useState hook
01:31:10 پیاده سازی پروژه با ری اکت جی اس
02:07:25 useEffect hook
02:22:06 دریافت داده از API
02:52:06 Route and navigation در Reactjs
03:16:13 useContext hook
03:38:03 react-query
03:56:25 react-hook-form
04:21:21 React Custom hook
04:43:52 useReducer hook
05:16:03 Redux
05:37:14 TypeScript
06:03:42 ساخت فروشگاه آنلاین با react js بخش اول
06:46:08 ساخت فروشگاه آنلاین با react js بخش دوم useContext
07:22:44 ساخت فروشگاه آنلاین با react js بخش سوم custom hook
07:37:49 ساخت فروشگاه آنلاین با react js بخش چهارم LocalStorage
08:20:16 ساخت فروشگاه آنلاین با react js بخش پنجم Deploy کردن پروژه ری اکت
- Blazor Server، که در آن یک اتصال SignalR، بین مرورگر کاربر و سرور، برقرار شده و سرور حالات مختلف این جلسهی کاری را مدیریت میکند. آغاز این حالت، بسیار سریع است؛ اما وجود اتصال دائم SignalR در آن ضروری است. نیاز به وجود این اتصال دائم، با تعداد بالای کاربر میتواند کارآیی سرور را تحت تاثیر قرار دهد.
- Blazor WASM: در این حالت کل برنامهی Blazor، درون مرورگر کاربر اجرا میشود و برای اینکار الزاما نیازی به سرور ندارد؛ اما آغاز اولیهی آن به علت نیاز به بارگذاری کل برنامه درون مرورگر کاربر، اندکی کند است. اتصال این روش با سرور، از طریق روشهای متداول کار با Web API صورت میگیرد و نیازی به اتصال دائم SignalR را ندارد.
دات نت 8، دو تغییر اساسی را در اینجا ارائه میدهد:
- در اینجا حالت جدیدی به نام SSR یا Static Server Rendering ارائه شدهاست (به آن Server-side rendering هم میگویند). در این حالت نه WASM ای درون مرورگر کاربر اجرا میشود و نه اتصال دائم SignalR ای برای کار با آن نیاز است! در این حالت برنامه تقریبا همانند یک MVC Razor application سنتی کار میکند؛ یعنی سرور، کار رندر نهایی HTML قابل ارائهی به کاربر را انجام داده و آنرا به سمت مرورگر، برای نمایش ارسال میکند و همچنین سرور، هیچ حالتی را هم از برنامه ذخیره نمیکند و بهعلاوه، کلاینت نیز نیازی به دریافت کل برنامه را در ابتدای کار ندارد (هم آغاز و نمایش سریعی را دارد و هم نیاز به منابع کمتری را در سمت سرور برای اجرا دارد).
- تغییر مهم دیگری که در دات نت 8 صورت گرفته، امکان ترکیب کردن حالتهای مختلف رندر صفحات، در برنامههای Blazor است. یعنی میتوان یک صفحهی SSR را داشت که تنها قسمت کوچکی از آن بر اساس معماری Blazor Server کار کند (قسمتهای اصطلاحا interactive یا تعاملی آن). یا حتی در یک برنامه، امکان ترکیب Blazor Server و Blazor WASM نیز وجود دارد.
اینها عناوین موارد جدیدی هستند که در این سری به تفصیل بررسی خواهیم کرد.
تاریخچهی نمایش صفحات وب در مرورگرها
در ابتدای ارائهی وب، سرورها، ابتدا درخواستی را از طرف مرورگر کلاینت دریافت میکردند و در پاسخ به آن، HTML ای را تولید و بازگشت میدادند. حاصل آن، نمایش یک صفحهی استاتیک non-interactive بود (غیرتعاملی). علت تاکید بر روی واژهی interactive (تعاملی)، بکارگیری گستردهی آن در نگارش جدید Blazor است؛ تا حدی که ایجاد قالبهای جدید آغازین برنامههای آن، با تنظیم این گزینه همراه است. برای مشاهدهی آن، پس از نصب SDK جدید دات نت، دستور dotnet new blazor --help را صادر کنید.
سپس JavaScript از راه رسید و هدف آن، افزودن interactivity به صفحات سمت کاربر بود تا بتوان بر اساس تعاملات و ورودیهای کاربر، تغییراتی را بر روی محتوای صفحه اعمال کرد. در ادامه JavaScript این امکان را یافت تا بتواند درخواستهایی را به سمت سرور ارسال کند و بر اساس خروجی دریافتی، قسمتهایی از صفحهی جاری استاتیک را به صورت پویا تغییر دهد.
در ادامه با بالارفتن توانمندیهای سختافزاری و همچنین توسعهی کتابخانههای جاوااسکریپتی، به برنامههای تک صفحهای کاملا پویا و interactive رسیدیم که به آنها SPA گفته میشود (Single-page applications)؛ از این دست کتابخانهها میتوان به Backbone اشاره کرد و پس از آن به React و Angular. برنامههای Blazor نیز اخیرا به این جمع اضافه شدهاند.
اما ... اخیرا توسعه دهندهها به این نتیجه رسیدهاند که SPAها برای تمام امور، مناسب و یا حتی الزامی نیستند. گاهی از اوقات ما فقط نیاز داریم تا محتوایی را خیلی سریع و بهینه تولید و بازگشت دهیم؛ مانند نمایش لیست اخبار، به هزاران دنبال کننده، با حداقل مصرف منابع و در همین حال نیاز به interactivity در بعضی از قسمتهای خاص نیز احساس میشود. این رویهای است که در تعدادی از فریمورکهای جدید و مدرن جاوااسکریپتی مانند Astro در پیش گرفته شدهاست؛ در آنها ترکیبی از رندر سمت سرور، به همراه interactivity سمت کاربر، مشاهده میشود. برای مثال این امکان را فراهم میکنند تا محتوای قسمتی از صفحه را در سمت سرور تهیه و رندر کنید، یا قسمتی از صفحه (یک کامپوننت خاص)، به صورت interactive فعال شود. ترکیب این دو مورد، دقیقا هدف اصلی Blazor، در دات نت 8 است. برای مثال فرض کنید میخواهید برنامه و سایتی را طراحی کنید که چند صفحهی آغازین آن، بدون هیچگونه تعاملی با کاربر هستند و باید سریع و SEO friendly باشند. همچنین تعدادی از صفحات آن هم قرار است فقط یک سری محتوای ثابت را نمایش دهند، اما در قسمتهای خاصی از آن نیاز به تعامل با کاربر است.
معرفی Blazor یکپارچه در دات نت 8
مهمترین تغییر Blazor در دات نت 8، یکپارچه شدن حالتهای مختلف رندر آن در سمت سرور است. تغییرات زیاد رخ دادهاند تا امکان داشتن Server-side rendering یا SSR به همراه قابلیت فعال سازی interactivity به ازای هر کامپوننت دلخواه که به آن حالتهای رندر (Render modes) گفته میشود، میسر شوند. در اساس، این روش جدید، همان Blazor Server بهبود یافتهاست که حالت SSR، حالت پیشفرض آن است. در کنار آن قابلیتهای راهبری (navigation)، نیز بهبود یافتهاند تا برنامههای SSR همانند برنامههای SPA بهنظر برسند.
در دات نت 8، ASP.NET Core و Blazor نیز کاملا یکپارچه شدهاند. در این حالت برنامههای Blazor Server میتوانند همانند برنامههای MVC Razor Pages متداول، با کمک قابلیت SSR، صفحات غیر interactive ای را رندر کنند؛ البته به کمک کامپوننتهای Razor. مزیت آن نسبت به MVC Razor Pages این است که اکنون میتوانید هر کامپوننت مجزایی از صفحه را نیز کاملا interactive کنید.
در نگارشهای قبلی Blazor، برنامههای Blazor Server حتی برای شروع کار نیاز به یک صفحهی Razor Pages آغازین داشتند، اما دیگر نیازی به این مورد با دات نت 8 نیست؛ چون ASP.NET Core 8x میتواند کامپوننتهای Razor را نیز به صورت HTML خالص بازگشت دهد و یا Minimal API آن به همراه خروجی new RazorComponentResult نیز شدهاست. در حالت SSR، حتی سیستم مسیریابی ASP.NET Core نیز با Blazor یکی شدهاست.
البته این تغییرات، حالتهای خالص Blazor WebAssembly و یا MAUI Blazor Hybrid را تحت تاثیر قرار نمیدهند؛ اما بدیهی است تمام آنها از سایر قابلیتهای جدید اضافه شده نیز بهرهمند هستند.
معرفی حالتهای مختلف رندر Blazor در دات نت 8
یک برنامهی جدید 8x Blazor، در اساس بر روی سرور رندر میشود (همان SSR). اما همانطور که عنوان شد، این SSR ارائه شدهی توسط Blazor، یک قابلیت مهم را نسبت به MVC Razor pages دارد و آن هم امکان فعالسازی interactivity، به ازای کامپوننتها و قسمتهای کوچکی از صفحه است که واقعا نیاز است تعاملی باشند. فعالسازی آن هم بسیار ساده، یکدست و یکپارچه است:
@* For being rendered on the server *@ <Counter @rendermode="@InteractiveServer" /> @* For running in WebAssembly *@ <Counter @rendermode="@InteractiveWebAssembly" />
این تعاریف حالت رندر را توسط دایرکتیوها نیز میتوان به ازای هر کامپوننت مجزا، مشخص کرد (یکی از این دو حالت باید بکار گرفته شود):
@rendermode InteractiveServer @rendermode InteractiveWebAssembly
امکان اعمال این ویژگیها به مسیریاب برنامه نیز وجود دارد که در این حالت کل برنامه را interactive میکند. اما در حالت پیشفرض، برنامهای که ایجاد میشود فاقد تنظیمات تعاملی در ریشهی اصلی آن است.
معرفی حالت رندر خودکار در Blazor 8x
یکی دیگر از حالتهای رندر معرفی شدهی در Blazor 8x، حالت Auto است:
<Counter @rendermode="@InteractiveAuto" />
معرفی حالت رندر Streaming در Blazor 8x
در بار اول بارگذاری صفحات، ممکن است دریافت اطلاعات مرتبط با آن کمی کند و با وقفه باشند. در این حالت برای اینکه برنامههای SSR یک صفحهی خالی را نمایش ندهند، میتوان در ابتدا با استفاده از حالت رندر جدید StreamRendering، حداقل قالب صفحه را نمایش داد و سپس اصل اطلاعات را:
@attribute [StreamRendering(prerender: true)]
جزئیات بیشتر نحوهی کار با این حالات را در قسمتهای بعدی بررسی خواهیم کرد.
نتیجه گیری:
روشهای جدید رندر ارائه شدهی در Blazor 8x، برای موارد زیر مفید هستند:
- زمانیکه قسمت عمدهای از برنامهی شما بر روی سرور اجرا میشود.
- زمانیکه خروجی اصلی برنامهی شما بیشتر حاوی محتواهای ثابت است؛ مانند CMSها.
- زمانیکه میخواهید صفحات شما قابل ایندکس شدن توسط موتورهای جستجو باشند و مباحث SEO برای شما مهم است.
- زمانیکه نیاز به مقدار کمی امکانات تعاملی دارید و فقط قسمتهای کوچکی از صفحه قرار است تعاملی باشند. برای مثال فقط قرار است قسمت کوچکی از یک صفحهی نمایش مقالهای از یک بلاگ، به همراه امکان رای دادن به آن مطلب (تنها قسمت «تعاملی» صفحه) باشد.
- و یا زمانیکه میخواهید MVC Razor Pages را با یک فناوری جدید که امکانات بیشتری را در اختیار شما قرار میدهد، جایگزین کنید.