using Microsoft.EntityFrameworkCore; using Microsoft.Extensions.Logging; await using var context = new MyDbContext(); await context.Database.EnsureDeletedAsync(); await context.Database.EnsureCreatedAsync(); context.Users.Add(new User { Name = "John Doe", Birthday = new(1980, 1, 20), ShiftStart = new (8, 0), ShiftLength = TimeSpan.FromHours(8) }); await context.SaveChangesAsync(); public class MyDbContext : DbContext { protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) { optionsBuilder.UseSqlServer(@"...") .LogTo(Console.WriteLine, LogLevel.Information) .EnableSensitiveDataLogging(); } public DbSet<User> Users { get; set; } } public class User { public int Id { get; set; } public required string Name { get; set; } public DateOnly Birthday { get; set; } public TimeOnly ShiftStart { get; set; } public TimeSpan ShiftLength { get; set; } }
CREATE TABLE [Users] ( [Id] int NOT NULL IDENTITY, [Name] nvarchar(max) NULL, [Birthday] date NOT NULL, [ShiftStart] time NOT NULL, [ShiftLength] time NOT NULL, CONSTRAINT [PK_Users] PRIMARY KEY ([Id]) );
برای استفاده از JSON.NET در یک اکشن متد، به صورت معمولی میتوان به نحو ذیل عمل کرد:
[HttpGet] public ActionResult GetSimpleJsonData() { return new ContentResult { Content = JsonConvert.SerializeObject(new { id = 1 }), ContentType = "application/json", ContentEncoding = Encoding.UTF8 }; }
اگر بخواهیم این عملیات را کمی بهینهتر کنیم، نیاز است بتوانیم از استریمها استفاده کرده و خروجی JSON را بدون تبدیل به رشته، مستقیما در استریم response.Output بنویسیم. با اینکار به سرعت بیشتر و همچنین مصرف منابع کمتری خواهیم رسید.
نمونهای از این پیاده سازی را در ذیل مشاهده میکنید:
using System; using System.Web.Mvc; using Newtonsoft.Json; namespace MvcJsonNetTests.Utils { public class JsonNetResult : JsonResult { public JsonNetResult() { Settings = new JsonSerializerSettings { ReferenceLoopHandling = ReferenceLoopHandling.Error }; } public JsonSerializerSettings Settings { get; set; } public override void ExecuteResult(ControllerContext context) { if (context == null) throw new ArgumentNullException("context"); if (this.JsonRequestBehavior == JsonRequestBehavior.DenyGet && string.Equals(context.HttpContext.Request.HttpMethod, "GET", StringComparison.OrdinalIgnoreCase)) { throw new InvalidOperationException("To allow GET requests, set JsonRequestBehavior to AllowGet."); } if (this.Data == null) return; var response = context.HttpContext.Response; response.ContentType = string.IsNullOrEmpty(this.ContentType) ? "application/json" : this.ContentType; if (this.ContentEncoding != null) response.ContentEncoding = this.ContentEncoding; var serializer = JsonSerializer.Create(this.Settings); using (var writer = new JsonTextWriter(response.Output)) { serializer.Serialize(writer, Data); writer.Flush(); } } } }
در این حالت برای استفاده از این Action Result جدید میتوان نوشت:
[HttpGet] public ActionResult GetJsonData() { return new JsonNetResult { Data = new { Id = 1, Name = "Test 1" }, JsonRequestBehavior = JsonRequestBehavior.AllowGet, Settings = { ReferenceLoopHandling = ReferenceLoopHandling.Ignore } }; }
تا اینجا قسمت ارسال اطلاعات از سمت سرور به سمت کاربر بازنویسی شد. امکان بازنویسی و تعویض موتور پردازش JSON دریافتی از سمت کاربر، در سمت سرور نیز وجود دارد. خود ASP.NET MVC به صورت استاندارد توسط کلاسی به نام JsonValueProviderFactory، اطلاعات اشیاء JSON دریافتی از سمت کاربر را پردازش میکند. در اینجا نیز اگر دقت کنید از کلاس JavaScriptSerializer استفاده شدهاست.
برای جایگزینی آن باید یک ValueProvider جدید را تهیه کنیم:
using System; using System.Dynamic; using System.Globalization; using System.IO; using System.Web.Mvc; using Newtonsoft.Json; using Newtonsoft.Json.Converters; namespace MvcJsonNetTests.Utils { public class JsonNetValueProviderFactory : ValueProviderFactory { public override IValueProvider GetValueProvider(ControllerContext controllerContext) { if (controllerContext == null) throw new ArgumentNullException("controllerContext"); if (controllerContext.HttpContext == null || controllerContext.HttpContext.Request == null || controllerContext.HttpContext.Request.ContentType == null) { return null; } if (!controllerContext.HttpContext.Request.ContentType.StartsWith( "application/json", StringComparison.OrdinalIgnoreCase)) { return null; } using (var reader = new StreamReader(controllerContext.HttpContext.Request.InputStream)) { var bodyText = reader.ReadToEnd(); return string.IsNullOrEmpty(bodyText) ? null : new DictionaryValueProvider<object>( JsonConvert.DeserializeObject<ExpandoObject>(bodyText, new JsonSerializerSettings { Converters = { new ExpandoObjectConverter() } }), CultureInfo.CurrentCulture); } } } }
در ادامه، اطلاعات JSON دریافتی به شکل یک رشتهی خام دریافت شده و سپس به متد JsonConvert.DeserializeObject ارسال میشود. با استفاده از تنظیم ExpandoObjectConverter، میتوان محدودیت کلاس JavaScriptSerializer را در مورد خواص و یا پارامترهای dynamic، برطرف کرد.
[HttpPost] public ActionResult TestValueProvider(string data1, dynamic data2)
و در آخر برای معرفی این ValueProvider جدید میتوان در فایل Global.asax.cs به نحو ذیل عمل نمود:
using System.Linq; using System.Web.Mvc; using System.Web.Routing; using MvcJsonNetTests.Utils; namespace MvcJsonNetTests { public class MvcApplication : System.Web.HttpApplication { protected void Application_Start() { AreaRegistration.RegisterAllAreas(); RouteConfig.RegisterRoutes(RouteTable.Routes); ValueProviderFactories.Factories.Remove( ValueProviderFactories.Factories.OfType<JsonValueProviderFactory>().FirstOrDefault()); ValueProviderFactories.Factories.Add(new JsonNetValueProviderFactory()); } } }
البته نگارش بعدی ASP.NET MVC موتور پردازشی JSON خود را از طریق تزریق وابستگیها دریافت میکند و از همان ابتدای کار قابل تنظیم و تعویض است. مقدار پیش فرض آن نیز به JSON.NET تنظیم شدهاست.
دریافت یک مثال کامل
MvcJsonNetTests.zip
تامین مقادیر پارامترها در حین نگاشتهای AutoMapper
- جلوگیری از Lazy loading اشتباه
- کاهش تعداد فیلدهای بازگشت داده شدهی از دیتابیس و محدود ساختن آنها به خواصی که قرار است نگاشت شوند. در حالت معمولی استفادهی از متد Mapper.Map، تمام فیلدهای مدل بارگذاری شده و سپس در سمت کلاینت توسط AutoMapper نگاشت خواهند شد. اما در حالت استفادهی از متد ویژهی Project To، کوئری SQL ارسالی به بانک اطلاعاتی نیز مطابق نگاشت تعریف شده، تغییر کرده و خلاصه خواهد شد.
در این حالت یک چنین سناریویی را درنظر بگیرید. مدل متناظر با جدول بانک اطلاعاتی ما چنین ساختاری را دارد:
public class UserModel { public int Id { get; set; } public string FirstName { get; set; } public string LastName { get; set; } }
public class UserViewModel { public string FirstName { get; set; } public string LastName { get; set; } public string UserIdentityName { get; set; } }
تعریف نگاشتهای پارامتری
برای حل این مساله، از روش زیر استفاده میشود:
string userIdentityName = null; this.CreateMap<UserModel, UserViewModel>() .ForMember(d => d.UserIdentityName, opt => opt.MapFrom(src => userIdentityName));
اکنون جهت استفادهی از این متغیر با قابلیت جایگزینی، میتوان به نحو ذیل عمل کرد:
var uiUsers = users.AsQueryable() .Project() .To<UserViewModel>(new { userIdentityName = "User.Identity.Name Value Here" }) .ToList();
کدهای کامل این مثال را از اینجا میتوانید دریافت کنید.
یکی از مواردی که در تمام برنامههای فارسی "باید" رعایت شود (مهم نیست به چه زبانی یا چه سکویی باشد یا چه بانک اطلاعاتی مورد استفاده است)، بحث اصلاح "ی" و "ک" دریافتی از کاربر و یکسان سازی آنها میباشد. به عبارتی برنامهی فارسی که اصلاح خودکار این دو مورد را لحاظ نکرده باشد دیر یا زود به مشکلات حادی برخورد خواهد کرد و "ناقص" است : اطلاعات بیشتر ؛ برای مثال شاید دوست نداشته باشید که دو کامران در سایت شما ثبت نام کرده باشند؛ یکی با ک فارسی و یکی با ک عربی! به علاوه همین کامران امروز میتواند لاگین کند و فردا با یک کامپیوتر دیگر و صفحه کلیدی دیگر پشت درب خواهد ماند. در حالیکه از دید این کامران، کلمه کامران همان کامران است!
بنابراین در دو قسمت "باید" این یکسان سازی صورت گیرد:
الف) پیش از ثبت اطلاعات در بانک اطلاعاتی (تا با دو کامران ثبت شده در بانک اطلاعاتی مواجه نشوید)
ب) پیش از جستجو (تا کامران روزی دیگر با صفحه کلیدی دیگر بتواند به برنامه وارد شود)
راه حل یکسان سازی هم شاید به نظر این باشد: رخداد فشرده شدن کلید را کنترل کنید و سپس جایگزینی را انجام دهید (مثلا ی عربی را با ی فارسی جایگزین کنید). این روش چند ایراد دارد:
الف) Silverlight به دلایل امنیتی اصلا چنین اجازهای را به شما نمیدهد! (تا نتوان کلیدی را جعل کرد)
ب) همیشه با یک TextBox ساده سر و کار نداریم. کنترلهای دیگری هم هستند که امکان ورود اطلاعات در آنها وجود دارد و آن وقت باید برای تمام آنها کد نوشت. ظاهر کدهای برنامه در این حالت در حجم بالا، اصلا جالب نخواهد بود و ضمنا ممکن است یک یا چند مورد فراموش شوند.
راه بهتر این است که دقیقا حین ثبت اطلاعات یا جستجوی اطلاعات در لایهای که تمام ثبتها یا اعمال کار با بانک اطلاعاتی برنامه به آنجا منتقل میشود، کار یکسان سازی صورت گیرد. به این صورت کار یکپارچه سازی یکبار باید انجام شود اما تاثیرش را بر روی کل برنامه خواهد گذاشت، بدون اینکه هرجایی که امکان ورود اطلاعات هست روالهای رخداد گردان هم حضور داشته باشند.
در مورد مقدمات WCF RIA Services که درSilverlight و ASP.NET کاربرد دارد میتوانید به این مطلب مراجعه کنید: +
جهت تکمیل این بحث متدی تهیه شده که کار یکسان سازی ی و ک دریافتی از کاربر را حین ثبت توسط امکانات WCF RIA Services انجام میدهد (دقیقا پیش از فراخوانی متد SubmitChanges باید بکارگرفته شود):
namespace SilverlightTests.RiaYeKe
{
public static class PersianHelper
{
public static string ApplyUnifiedYeKe(this string data)
{
if (string.IsNullOrEmpty(data)) return data;
return data.Replace("ی", "ی").Replace("ک", "ک");
}
}
}
using System.Linq;
using System.Windows.Controls;
using System.Reflection;
using System.ServiceModel.DomainServices.Client;
namespace SilverlightTests.RiaYeKe
{
public class RIAHelper
{
/// <summary>
/// یک دست سازی ی و ک در عبارات ثبت شده در بانک اطلاعاتی پیش از ورود به آن
/// این متد باید پیش از فراخوانی متد
/// SubmitChanges
/// استفاده شود
/// </summary>
/// <param name="dds"></param>
public static void ApplyCorrectYeKe(DomainDataSource dds)
{
if (dds == null)
return;
if (dds.DataView.TotalItemCount <= 0)
return;
//پیدا کردن موجودیتهای تغییر کرده
var changedEntities = dds.DomainContext.EntityContainer.GetChanges().Where(
c => c.EntityState == EntityState.Modified ||
c.EntityState == EntityState.New);
foreach (var entity in changedEntities)
{
//یافتن خواص این موجودیتها
var propertyInfos = entity.GetType().GetProperties(
BindingFlags.Public | BindingFlags.Instance
);
foreach (var propertyInfo in propertyInfos)
{
//اگر این خاصیت رشتهای است ی و ک آن را استاندارد کن
if (propertyInfo.PropertyType != typeof (string)) continue;
var propName = propertyInfo.Name;
var val = new PropertyReflector().GetValue(entity, propName);
if (val == null) continue;
new PropertyReflector().SetValue(
entity,
propName,
val.ToString().ApplyUnifiedYeKe());
}
}
}
}
}
توضیحات:
از آنجائیکه حین فراخوانی متد SubmitChanges فقط موجودیتهای تغییر کرده جهت ثبت ارسال میشوند، ابتدا این موارد یافت شده و سپس خواص عمومی تک تک این اشیاء توسط عملیات Reflection بررسی میگردند. اگر خاصیت مورد بررسی از نوع رشتهای بود، یکبار این یک دست سازی اطلاعات ی و ک دریافتی صورت خواهد گرفت (و از آنجائیکه این تعداد همیشه محدود است عملیات Reflection سربار خاصی نخواهد داشت).
اگر در کدهای خود از DomainDataSource استفاده نمیکنید باز هم تفاوتی نمیکند. متد ApplyCorrectYeKe را از قسمت DomainContext.EntityContainer به بعد دنبال کنید.
اکنون تنها مورد باقیمانده بحث جستجو است که با اعمال متد ApplyUnifiedYeKe به مقدار ورودی متد جستجوی خود، مشکل حل خواهد شد.
کلاس PropertyReflector بکارگرفته شده هم از اینجا به عاریت گرفته شد.
دریافت کدهای این بحث
طی سالهای مختلف برنامهنویسی و گاهی استفاده از زبانهای مختلف ممکن است باعث شده باشد ما به طور ناخواسته به «دستخطی» غیر استاندارد دست یافته باشیم و به سیستمی که بیشتر برای خود ما آشنا باشد کد بزنیم. البته که چنین سیستمی به خودی خود بد نیست اما چون دیگران با آن آشنا نیستند میتواند خواندن و مرور کدها را با مشکل جدی مواجه کند. با رعایت بیشتر اصول و قواعد معرفی شده در هر زبان میتوان تا جای ممکن کدهای خواناتر و قابل ارائهتری ارائه دهیم.
در این مطلب که نکاتی نه چندان ناآشنا ولی لازم جهت نامگذاری، استفاده از کلمه کلیدی var و همچنین اضافه شدن کلمات کلیدی جدیدی همچون record را در c# مرور کنیم. به طور مثال:
روش صحیح استفاده از var:
var var1 = "This is clearly a string";
روش غلط استفاده از var:
int var4 = ExampleClass.ResultSoFar();
کلاسها در ES 6
function PersonType(name) { this.name = name; } PersonType.prototype.sayName = function() { console.log(this.name); }; let person = new PersonType("Nicholas"); person.sayName(); // outputs "Nicholas" console.log(person instanceof PersonType); // true console.log(person instanceof Object); // true
class PersonClass { // equivalent of the PersonType constructor constructor(name) { this.name = name; } // equivalent of PersonType.prototype.sayName sayName() { console.log(this.name); } } let person = new PersonClass("Nicholas"); person.sayName(); // outputs "Nicholas" console.log(person instanceof PersonClass); // true console.log(person instanceof Object); // true console.log(typeof PersonClass); // "function" console.log(typeof PersonClass.prototype.sayName); // "function"
//unnamed class expressions do not require identifiers after "class" let PersonClass = class { // equivalent of the PersonType constructor constructor(name) { this.name = name; } // equivalent of PersonType.prototype.sayName sayName() { console.log(this.name); } }; let person = new PersonClass("Nicholas"); person.sayName(); // outputs "Nicholas" console.log(person instanceof PersonClass); // true console.log(person instanceof Object); // true console.log(typeof PersonClass); // "function" console.log(typeof PersonClass.prototype.sayName); // "function" //named let PersonClass = class PersonClass2 { // equivalent of the PersonType constructor constructor(name) { this.name = name; } // equivalent of PersonType.prototype.sayName sayName() { console.log(this.name); } }; console.log(PersonClass === PersonClass2); // true
function createObject(classDef) { return new classDef(); } let obj = createObject(class { sayHi() { console.log("Hi!"); } }); obj.sayHi(); // "Hi!"
let person = new class {
constructor(name) {
this.name = name;
}
sayName() {
console.log(this.name);
}
}("Nicholas");
person.sayName(); // "Nicholas
در کد بالا ، "Nicholas" به عنوان آرگومان سازنده کلاس بی نام در هنگام ساخت نمونه از طریق پرانتزهای باز و بسته انتهایی، پاس داده شده است. استفاده از class declarations یا class expressions برای کار با کلاسها به سبک کاری شما مربوط خواهد شد و بس. ولی نکته این است که هر دو شکل پیاده سازی کلاسها بر خلاف function declarations و function expressions ، قابلیت hoisting را نخواهند داشت و به صورت پیش فرض در حالت strict mode اجرا خواهند شد.
Accessor Properties
کلاسها این امکان را دارند تا بتوان برای پراپرتیهایی که در سازندهی کلاس تعریف شدهاند، accessor property تعریف کرد. سینتکس استفاده شدهی برای این منظور، شبیه به ساخت object literal accessorها در ES 5 میباشد.برای مثال:
class CustomHTMLElement { constructor(element) { this.element = element; } get html() { return this.element.innerHTML; } set html(value) { this.element.innerHTML = value; } } var descriptor = Object.getOwnPropertyDescriptor(CustomHTMLElement.prototype,\ "html"); console.log("get" in descriptor); // true console.log("set" in descriptor); // true
در کد بالا ، getter و setter برای محتوای html مربوط به پراپرتی element در نظر گرفته شده است که در واقعا نمایندگان (delegates) مربوط به متد innterHTML خود element میباشند. معادل همین پیاده سازی بدون استفاده از سینتکس کلاس، به شکل زیر خواهد بود:
// direct equivalent to previous example let CustomHTMLElement = (function() { "use strict"; const CustomHTMLElement = function(element) { // make sure the function was called with new if (typeof new.target === "undefined") { throw new Error("Constructor must be called with new."); } this.element = element; } Object.defineProperty(CustomHTMLElement.prototype, "html", { enumerable: false, configurable: true, get: function() { return this.element.innerHTML; }, set: function(value) { this.element.innerHTML = value; } }); return CustomHTMLElement; }());
حتما متوجه شدید که با استفاده از سینتکس کلاس برای تعریف accessor propertyها حجم کد نویسی شما خیلی کاهش خواهد یافت و این تنها تفاوت بین دو شکل پیاده سازی فوق میباشد.
Static Members
ساخت اعضای استاتیک در ورژن قبل برای مثال به شکل زیر بود:
function PersonType(name) { this.name = name; } // static method PersonType.create = function(name) { return new PersonType(name); }; // instance method PersonType.prototype.sayName = function() { console.log(this.name); }; var person = PersonType.create("Nicholas");
در کد بالا یک متد استاتیک برای نوع داده شخصی PersonType در نظر گرفته شده است. این مورد در ES 6 بهبود یافته و فقط با قرار دادن کلمهی کلیدی static قبل از نام متد و یا accessor property میتوان به نتیجهی مثال بالا دست یافت:
class PersonClass { // equivalent of the PersonType constructor constructor(name) { this.name = name; } // equivalent of PersonType.prototype.sayName sayName() { console.log(this.name); } // equivalent of PersonType.create static create(name) { return new PersonClass(name); } } let person = PersonClass.create("Nicholas");
نکته این که نمیتوان سازندهی استاتیک در کلاس خود تعریف کرد.
Inheritance
مشکل دیگری که در ES 5 برای پیاده سازی انواع داده شخصی وجود داشت، حجم بالای کد و مراحلی بود که برای پیاده سازی وراثت میبایستی متحمل میشدیم. برای مثال در ورژن قبلی باید به شکل زیر عمل میکردیم:
function Rectangle(length, width) { this.length = length; this.width = width; } Rectangle.prototype.getArea = function() { return this.length * this.width; }; function Square(length) { Rectangle.call(this, length, length); } Square.prototype = Object.create(Rectangle.prototype, { constructor: { value:Square, enumerable: true, writable: true, configurable: true } }); var square = new Square(3); console.log(square.getArea()); // 9 console.log(square instanceof Square); // true console.log(square instanceof Rectangle); // true
درکد بالا Square از Rectangle ارث بری کرده که برای این منظور Square.prototype را با ساخت نمونهای از Rectangle.prototype بازنویسی کردهایم. این سینتکس باعث سردرگمی اغلب تازه کاران خواهد شد. برای این منظور در ES 6 خیلی راحت با استفاده از کلمهی کلیدی extends بعد از نام کلاس و سپس نوشتن نام کلاس پایه خواهیم توانست به نتیجهی بالا دست یابیم. به عنوان مثال:
class Rectangle { constructor(length, width) { this.length = length; this.width = width; } getArea() { return this.length * this.width; } } class Square extends Rectangle { constructor(length) { // same as Rectangle.call(this, length, length) super(length, length); } } var square = new Square(3); console.log(square.getArea()); // 9 console.log(square instanceof Square); // true console.log(square instanceof Rectangle); // true
در کد بالا نیز کلاس Square از کلاس Rectangle ارث بری کرده و همانطور که مشخص است و انتظار داشتیم، متد getArea در یکی از اعضای به ارث برده شده از کلاس پایه، قابل دسترسی میباشد. در سازندهی کلاس Square با استفاده از ()super توانستهایم سازندهی کلاس Rectangle را با آرگومانهای مشخصی فراخوانی کنیم.
اگر برای subclass، سازنده در نظر گرفته شود، باید سازندهی کلاس پیاده سازی کننده حتما فراخوانی شود. در غیر این صورت با خطا روبرو خواهید شد. ولی در مقابل اگر هیچ سازندهای برای subclass در نظر نگرفته باشید، به صورت خودکار سازندهی کلاس پایه هنگام ساخت نمونه از این subclass فراخوانی خواهد شد:
class Square extends Rectangle { // no constructor } // Is equivalent to class Square extends Rectangle { constructor(...args) { super(...args); } }
همانطور که در کد بالا مشخص است اگر سازندهای برای subclass در نظر گرفته نشود، تمام آرگومانهای ارسالی، هنگام نمونه سازی از آن، به ترتیب به سازندهی کلاس پایه نیز پاس داده خواهند شد.
چند نکته
- فقط زمانی میتوان ()super را فراخوانی کرد که از بعد از نام کلاس از کلمهی کلیدی extends استفاده شده باشد.
- باید قبل از دسترسی به کلمهی کلیدی this در سازنده subclass، سازندهی کلاس پایه را با استفاده از ()super فراخوانی کرد.
Class Methods
اگر در subclass متدی همنام متد کلاس پایه داشته باشید، به صورت خودکار متد کلاس پایه override خواهد شد. البته همیشه میتوان متد کلاس پایه را مستقیم هم فراخوانی کرد؛ به عنوان مثال:
class Square extends Rectangle { constructor(length) { super(length, length); } // override, shadow, and call Rectangle.prototype.getArea() getArea() { return super.getArea(); } }
در کد بالا متد getArea کلاس پایه بازنویسی شده است. ولی با این حال با استفاده از کلمهی super به متد اصلی در کلاس پایه دسترسی داریم.
نام متدها حتی میتوانند قابلیت محاسباتی داشته باشند. به عنوان مثال خواهید توانست به شکل زیر عمل کنید:
let methodName = "getArea"; class Square extends Rectangle { constructor(length) { super(length, length); } // override, shadow, and call Rectangle.prototype.getArea() [methodName]() { return super.getArea(); } }
کد بالا دقیقا با مثال قبل یکسان است با این تفاوت که نام متد getArea را به صورت رشتهای با قابلیت محاسباتی در نظر گرفتیم.
ارث بردن اعضای استاتیک یک مفهوم جدید در جاوااسکریپت میباشد که نمونهی آن را میتوانید در کد زیر مشاهده کنید:
class Rectangle { constructor(length, width) { this.length = length; this.width = width; } getArea() { return this.length * this.width; } static create(length, width) { return new Rectangle(length, width); } } class Square extends Rectangle { constructor(length) { // same as Rectangle.call(this, length, length) super(length, length); } } var rect = Square.create(3, 4); console.log(rect instanceof Rectangle); // true console.log(rect.getArea()); // 12 console.log(rect instanceof Square); // false
در کد بالا متد استاتیک create یک متد استاتیک در کلاس پایه Rectangle میباشد که این بار در کلاس Square هم قابل دسترسی است.
قدرتمندترین جنبهی کلاسهای مشتق شده در ES 6 ، توانایی ارث بری از expressionها میباشد. شما میتوانید کلمهی کلیدی extends را با هر expression ای استفاده کنید. برای مثال:
function Rectangle(length, width) { this.length = length; this.width = width; } Rectangle.prototype.getArea = function() { return this.length * this.width; }; class Square extends Rectangle { constructor(length) { super(length, length); } } var x = new Square(3); console.log(x.getArea()); // 9 console.log(x instanceof Rectangle); // true
در کد بالا Rectangle یک تابع سازنده برای تعریف نوع داده شخصی در ES 5 و Square، نوع داده با سینتکس کلاس در ES 6 میباشند. ولی با این حال کلاس Square توانسته است از Rectangle ارث بری کند.
یکی دیگر از امکانات فوق العادهی آن، مشخص کردن داینامیک کلاس پایه است. برای مثال:
function Rectangle(length, width) { this.length = length; this.width = width; } Rectangle.prototype.getArea = function() { return this.length * this.width; }; function getBase() { return Rectangle; } class Square extends getBase() { constructor(length) { super(length, length); } } var x = new Square(3); console.log(x.getArea()); // 9 console.log(x instanceof Rectangle); // true
در کد بالا متد getBase میتواند شامل منطق بیشتری هم برای مشخص کردن داینامیک کلاس پایه باشد که این مورد در بعضی از سناریوها مفید خواهد بود.
new.target
با استفاده از مقدار موجود در این شیء، در سازندهی کلاس میتوان مشخص کرد که به چه شکلی به کلاس مورد نظر استناد شدهاست. برای مثال:
class Rectangle { constructor(length, width) { console.log(new.target === Rectangle); this.length = length; this.width = width; } } // new.target is Rectangle var obj = new Rectangle(3, 4); // outputs true
در کد بالا با استفاده از new.target توانستیم که مشخص کنیم شیء ایجاد شده از نوع Rectangle میباشد. با استفاده از این امکان خوب میتوان به ساخت کلاسهای abstract رسید. برای مثال:
// abstract base class class Shape { constructor() { if (new.target === Shape) { throw new Error("This class cannot be instantiated directly.") } } } class Rectangle extends Shape { constructor(length, width) { super(); this.length = length; this.width = width; } } var x = new Shape(); // throws error var y = new Rectangle(3, 4); // no error console.log(y instanceof Shape); // true
در کد بالا که کاملا هم مشخص است؛ در سازندهی کلاس Shape مشخص کردهایم که اگر مستقیما از کلاس Shape نمونه سازی شد، یک exception را پرتاب کند. با این اوصاف ما توانستهایم که کلاس Shape را به صورت Abstract معرفی کنیم.
// api.model.ts export interface Customer { id: number; name: string; } export interface User { id: number; isActive: boolean; }
// using the interfaces import { Customer, User } from './api.model'; export class MyComponent { cust: Customer; }
// api.model.ts namespace ApiModel { export interface Customer { id: number; name: string; } export interface User { id: number; isActive: boolean; } }
// using the interfaces export class MyComponent { cust: ApiModel.Customer; }
// api.v2.model.ts namespace ApiModel { export interface Order { id: number; total: number; } }
export class MyComponent { cust: ApiModel.Customer; order: ApiModel.Order; }
// api.model.d.ts interface Customer { id: number; name: string; }
// using the interfaces of d file export class MyComponent { cust: Customer; }
// lib.es5.d.ts type Partial<T> = { [P in keyof T]?: T[P]; };
import { Customer } from './api.model'; export class MyComponent { cust: Partial<Customer>; / ngOninit() { this.cust = { name: 'jane' }; } }
if (false) { console.log('x'); }
if (false) { // @ts-ignore console.log('x'); }
متد Scan
فرض کنید قصد دارید تعدادی عدد را با هم جمع بزنید. برای اینکار عموما عدد اول با عدد دوم جمع زده شده و سپس حاصل آن با عدد سوم جمع زده خواهد شد و به همین ترتیب تا آخر توالی. کار متد Scan نیز دقیقا به همین نحو است. هربار که قرار است توالی پردازش شود، حاصل عملیات مرحلهی قبل را در اختیار مصرف کننده قرار میدهد.
در مثال ذیل، قصد داریم حاصل جمع اعداد موجود در آرایهای را بدست بیاوریم:
var sequence = new[] { 12, 3, -4, 7 }.ToObservable(); var runningSum = sequence.Scan((accumulator, value) => { Console.WriteLine("accumulator {0}", accumulator); Console.WriteLine("value {0}", value); return accumulator + value; }); runningSum.Subscribe(result => Console.WriteLine("result {0}\n", result));
result 12 accumulator 12 value 3 result 15 accumulator 15 value -4 result 11 accumulator 11 value 7 result 18
در دفعات بعدی، مقدار این accumulator با عدد جاری جمع زده شده و حاصل این عملیات در تکرار آتی، مجددا توسط accumulator قابل دسترسی خواهد بود.
یک نکته: اگر علاقمند باشیم که مقدار اولیهی accumulator، اولین عنصر توالی نباشد، میتوان آنرا توسط پارامتر seed متد Scan مقدار دهی کرد:
var runningSum = sequence.Scan(seed: 10, accumulator: (accumulator, value) =>
متد Buffer
متد بافر، کار تقسیم یک توالی را به توالیهای کوچکتر، بر اساس زمان، یا تعداد عنصر مشخص شده، انجام میدهد. برای مثال در برنامههای دسکتاپ شاید نیازی نباشد تا به ازای هر عنصر توالی، یکبار رابط کاربری را به روز کرد. عموما بهتر است تا تعداد مشخصی از عناصر یکجا پردازش شده و نتیجهی این پردازش به تدریج نمایش داده شود.
var sequence = Enumerable.Range(1, 200) .ToObservable() .Buffer(count: 10); sequence.Subscribe(onNext: numbers => { Console.WriteLine(numbers.Sum()); });
به این ترتیب میتوان فشار حجم اطلاعات ورودی با فرکانس بالا را کنترل کرد و در نتیجه از منابع موجود بهتر استفاده نمود. برای مثال اگر میخواهید عملیات bulk insert را انجام دهید، میتوان بر اساس یک batch size مشخص، گروه گروه اطلاعات را به بانک اطلاعاتی اضافه کرد تا فشار کار کاهش یابد.
همینکار را بر اساس زمان نیز میتوان انجام داد:
var sequence = Enumerable.Range(1, 200) .ToObservable() .Buffer(timeSpan: TimeSpan.FromSeconds(2));
متد Window
متد Window نیز دقیقا همان پارامترهای متد بافر را قبول میکند. با این تفاوت که هربار، یک توالی obsevable را به متد onNext ارسال میکند.
نوع numbers پارامتر onNext، در حین بکارگیری متد بافر در مثالهای فوق، IList of int است. اما اگر متدهای Buffer را تبدیل به متد Window کنیم، اینبار نوع numbers، معادل IObservable of int خواهد شد.
var sequence = Enumerable.Range(1, 200) .ToObservable() .Window(timeSpan: TimeSpan.FromSeconds(2)); sequence.Subscribe(onNext: numbers => { numbers.Subscribe(onNext: number => Console.WriteLine(number)); });
چه زمانی باید از Buffer استفاده کرد و چه زمانی از Window؟
در متد بافر، به ازای هر توالی که به پارامتر onNext ارسال میشود، یکبار وهلهی جدیدی از توالی مدنظر در حافظه ایجاد و ارسال خواهد شد. در متد Window صرفا اشارهگرهایی به این توالی را در اختیار داریم؛ بنابراین مصرف حافظهی کمتری را شاهد خواهیم بود. متد Window بسیار مناسب است برای اعمال aggregation. مثلا اگر نیاز است جمع، میانگین، حداقل و حداکثر عناصر دریافتی محاسبه شوند، بهتر است از متد Window استفاده شود که نهایتا قابلیت استفاده از متدهای الحاقی Sum و Max و Min را به همراه دارد. با این تفاوت که حاصل اینها نیز یک IObservable است که باید Subscribe آنرا برای دریافت نتیجه فراخوانی کرد:
var sequence = Enumerable.Range(1, 200) .ToObservable() .Window(10); sequence.Subscribe(onNext: numbers => { numbers.Sum().Subscribe(onNext: number => Console.WriteLine(number)); });
کاربردهای دنیای واقعی
در اینجا دو مثال از بکارگیری متد Buffer را جهت پردازش مجموعههای عظیمی از اطلاعات و نمایش همزمان آنها در رابط کاربری ملاحظه میکنید.
مثال اول: فرض کنید قصد دارید تمام فایلهای درایو C خود را توسط یک TreeView نمایش دهید. در این حالت نباید رابط کاربری برنامه در حالت هنگ به نظر برسد. همچنین به علت زیاد بودن تعداد فایلها و نمایش همزمان آنها در UI، نباید CPU Usage برنامه تا حدی باشد که در کار سایر برنامهها اخلال ایجاد کند. در این مثالها با استفاده از Rx و متد بافر آن، هربار مثلا 1000 آیتم را بافر کرده و سپس یکجا در TreeView نمایش میدهند. به این ترتیب دو شرط یاد شده محقق میشوند.
The Rx Framework By Example
مثال دوم: خواندن تعداد زیادی رکورد از بانک اطلاعاتی به همراه نمایش همزمان آنها در UI بدون اخلالی در کار سیستم و همچنین هنگ کردن برنامه.
Using Reactive Extensions for Streaming Data from Database
در ادامه مطالب مربوط به برنامه نویسی تابعی، قصد دارم بیشتر وارد کد شویم و مباحث عنوان شده را در دنیای کد پیاده سازی کنیم. هدف این قسمت، refactor کردن کد موجود به یک معماری immutable هست. پیشتر درباره immutable ها صحبت کردیم. ابتدا برای یکسان سازی ادبیات مورد استفاده، چند کلمه را مجددا تعریف خواهیم کرد:
- Immutability: عدم توانایی تغییر داده
- State: دادههایی که در طول زمان تغییر میکنند
- Side Effect: تغییری که روی دادهها اتفاق میافتد
در قطعه کد زیر سعی شدهاست تفاوت یک کلاس Stateless و stateful را به سادگی نشان دهیم:
//Stateful public class UserProfile { private User _user; private string _address; public void UpdateUser(int userId, string name) { _user = new User(userId, name); } } //Stateless public class User { public User(int id, string name) { Id = id; Name = name; } public int Id { get; } public string Name { get; } }
چرا Immutable بودن مهم است؟
هر عمل mutable معادل کدی غیر شفاف است. در واقع وابستگی هر عملی که انجام میدهیم به state، باعث میشود که شرایط ناپایداری را در کد داشته باشیم. به طور مثال در یک عملیات چند نخی تصور کنید که چندین نخ به طور همزمان میتوانند state را تغییر دهند و مدیریت این قضیه باعث به وجود آمدن کدهایی ناخوانا و تحمیل پیچیدگی بیشتر به کد خواهد شد.
در واقع انتظار داریم که به ازای یک ورودی بر اساس بدنهی متد، یک خروجی داشته باشیم؛ ولی در واقعیت تاثیری که اجرای متد بر روی state کل کلاس خواهد گذاشت، از دید ما پنهان است و باعث به وجود آمدن مشکلات بعدی خواهد شد. برای مثال قطعه کد بالا را به صورت Honest بازنویسی میکنیم:
public class UserProfile { private readonly User _user; private readonly string _address; public UserProfile(User user,string address) { _user = user; _address = address; } public UserProfile UpdateUser(int userId, string name) { var newUser = new User(userId, name); return new UserProfile(newUser,_address); } } public class User { public User(int id, string name) { Id = id; Name = name; } public int Id { get; } public string Name { get; } }
در این مثال متد UpdateUser به جای void، یک شی از جنس کلاس UserProfile را بر میگرداند. کلاس UserProfile هم برای وهله سازی نیاز به یک شیء از جنس User و Address را دارد. بنابراین مطمئن هستیم که مقدار دهی شدهاند. نکته دیگر در قطعه کد بالا این است که به ازای هر بار فراخوانی متد، یک شیء جدید بدون وابستگی به وهله سازی اشیاء دیگر، برگردانده میشود.
Immutable
بودن باعث میشود:
- خوانایی کد افزایش پیدا کند
- جای واحدی برای Validate کردن داشته باشیم
- به صورت ذاتی Thread Safe باشیم
در مورد محدودیتهایی که در کار با اشیاء Immutable باید در نظر داشته باشیم، میتوان به مصرف بالای رم و سی پی یو، اشاره کرد. در واقع به نسبت حالت mutate، تعداد اشیاء بیشتری ساخته خواهند شد. در فریمورک دات نت برای کار با اشیا immutable امکاناتی در نظر گرفته شده که این هزینه را کاهش میدهند. به طور مثال میتوانیم از کلاس ImmutableList استفاده کنیم و از ایجاد اشیاء اضافهتر و تحمیل بار اضافی به GC جلوگیری کنیم. یک مثال:
//Create Immutable List ImmutableList<string> list = ImmutableList.Create<string>(); ImmutableList<string> list2 = list.Add("Salam"); //Builder ImmutableList<string>.Builder builder = ImmutableList.CreateBuilder<string>(); builder.Add("avali"); builder.Add("dovomi"); builder.Add("sevomi"); ImmutableList<string> immutableList = builder.ToImmutable();
چطور با side effect کنار بیایم؟
یکی از الگوهای رایج برای این کار، مفهوم جدا سازی Command/Query است. به طور ساده تمامی عملیاتی را که تاثیر گذار هستند، به صورت Command در نظر میگیریم. Command ها معمولا هیچ نوعی را بازگشت نمیدهند و همینطور بر عکس این قضیه برای Query ها صادق است. اشتباه رایج درباره این الگو، محدود کردن این الگو به معماریهای خاصی مانند Domain Driven میباشد؛ در صورتیکه الزامی برای رعایت این الگو در سایر معماریها وجود ندارد.
به مثال زیر دقت کنید. سعی کردم قسمتهای Command و Query را از هم جدا کنم:
در واقع هر برنامه میتواند شامل دو قسمت باشد:
قسمتی که در آن منطق تجاری برنامه پیاده سازی میشود و باید به صورت Immutable
باشد که یک خروجی را تولید میکند و قسمت دیگر برنامه که خروجی تولید شده را برای ذخیره
سازی وضعیت سیستم استفاده میکند.
در واقع یک هسته Immutable، ورودی را دریافت کرده و خروجیهای مورد نیاز را تولید میکند و همه اینها در دل یک پوستهMutable پیاده سازی میشوند که ما در اینجا به آن اصطلاحا Mutable Shell میگوییم.
برای مسائلی که در بالا صحبت شد، نمونهای را آماده کردهام. این نمونه به طور ساده یک سیستم مدیریت نوبت است که نوبتها را در فایلی ذخیره و بازیابی میکند ( mutate ) و منطق مربوط به نوبتها و زمان ویزیت آن میتواند به صورت immutable پیاده سازی شود. این کد در دو حالت functional و غیر functional پیاده سازی شده تا به خوبی تفاوت آن را در حالت قبل و بعد از برنامه نویسی تابعی بتوانیم درک کنیم. به جهت خوانایی بیشتر و دسترسی به کدها، آنها را روی گیتهاب قرار داده و شما میتوانید از اینجا سورس کد مورد نظر را بررسی کنید. سعی شده در این مثال تمامی مواردی که در این قسمت ذکر شد را پیاده سازی کنیم. امیدوارم که مطالب مربوط به برنامه نویسی تابعی یا functional programming توانسته باشد دیدگاه جدیدی را به کدهایی که مینویسیم بدهد. در قسمتهای بعدی به مواردی مانند مدیریت exception ها و کار با null ها و ... خواهیم پرداخت.