اشتراکها
J (J language) is a high-level, general-purpose, high-performance programming language. J is portable and runs on 32/64-bit Windows/Linux/Mac as well as iOS, Android, and other platforms. J source (required only if Jsoftware binaries don't meet your requirements) is available under both commercial and GPL 3 license. J systems can be installed and distributed for free.
J systems have:
- an integrated development environment
- standard libraries, utilities, and packages
- console, browser, and Qt front ends
- interfaces with other programming languages and applications
- integrated graphics
- memory mapped files for high performance data applications
- Jd
نظرات مطالب
C# 7 - Tuple return types and deconstruction
بهبود نحوهی انتساب Tuples در حین deconstruction در C# 10.0
پیشتر از یکی از دو روش زیر برای تعریف و مقدار دهی متغیرهای حاصل از deconstruction میشد استفاده کرد؛ یا استفاده از var برای هر دو و یا تعریف و مقدار دهی هر دو خارج از deconstruction:
Car car = new("Test", "Blue"); var (model, color) = car; // Initialization string model = string.Empty; string color = string.Empty; (model, color) = car; // Assignment
string model = string.Empty; (model, var color) = car; // Initialization and assignment
در برنامههای Blazor Server، تنها از یک نخ رابط کاربری واحد ( single UI thread ) استفاده نمیشود؛ بلکه هر نخی که در دسترس باشد، میتواند در موقع رندر، استفاده شود. علاوه بر این اگر از عملیات نامتقارن استفاده شود، زمانیکه به کلمهی کلیدی await میرسیم، آنگاه نخ اختصاص داده شدهی برای ادامه پردازش متد، ممکن است لزوما همان چیزی نباشد که آن را شروع کرده است. برای نشان دادن این موضوع مثالی را در پیش میگیریم.
کامپوننتی را با نام SynchronousInitComponent با کد زیر درنظر میگیریم. همانطور که از اسم آن مشخص است این کامپوننت به صورت متقارن یا همزمان پیادهسازی شده است:
در حقیقت در متد OnInitialized آن، مقدار نخ جاری را توسط Thread.ManagedThreadId به دست میآوریم. بنابراین شماره نخ جاری پس از رندر شدن کامپوننت، در صفحه نمایش داده میشود.
حال در کامپوننت دیگری برای مثال کامپوننت index، کامپوننت همزمان فوق را به شکل زیر فراخوانی میکنیم:
با این نتیجه:
همانطور که ملاحظه مینمایید شناسه نخ یکسانی برای هر فراخوانی کامپوننت نشان داده میشود. بدیهی است در صورتیکه شما همین کد را اجرا کنید، ممکن است شماره نخ برنامه شما با کد من یکی نباشد؛ اما نتیجه یکی است. یعنی در تمامی موارد، یک عدد مشاهده میشود.
حال همین آزمایش را با متدهای نامتقارن یا ناهمزمان انجام میدهیم. کامپوننت AsynchronousInitComponent را با کد زیر درنظر بگیرید:
این کامپوننت هم دقیقا شبیه کامپوننت قبلی است؛ با این تفاوت که IdOfRenderingThread، مجددا بعد از یک تاخیر یک ثانیهای مقداردهی شدهاست. این مقداردهی سبب رندر مجدد کامپوننت با تاخیر یک ثانیه میشود. حال در کامپوننت دیگری، کامپوننت غیرمتقارن فوق را به شکل زیر فراخوانی میکنیم:
با اجرا کردن برنامه، دقیقا نتایج، شبیه نتایج نتایج کامپوننت متقارن میباشد:
اما تنها بعد از یک ثانیه (await Task.Delay(1000)) ، متدهای OnInitializedAsync کامپوننتها، به پایان میرسند و مقدار IdOfRenderingThread را پیش از به پایان رسیدن رندر صفحه، به روز رسانی مینمایند. اینبار، دیگر مقادیر نخها متفاوت خواهند بود:
با توجه به مطالب مطرح شده به این نتیجه میرسیم که این موضوع میتواند هنگام استفاده از یک وابستگی غیر ایمن ( non-thread-safe dependency ) مانند DBContext در چندین کامپوننت باعث بروز مشکل شود. نمونهای از نحوهی رویارویی با مشکلات احتمالی آن، در اینجا و اینجا بررسی شدهاست.
کامپوننتی را با نام SynchronousInitComponent با کد زیر درنظر میگیریم. همانطور که از اسم آن مشخص است این کامپوننت به صورت متقارن یا همزمان پیادهسازی شده است:
<p>Sync rendered by thread @IdOfRenderingThread</p> @code { int IdOfRenderingThread; protected override void OnInitialized() { base.OnInitialized(); IdOfRenderingThread = System.Threading.Thread.CurrentThread.ManagedThreadId; } }
حال در کامپوننت دیگری برای مثال کامپوننت index، کامپوننت همزمان فوق را به شکل زیر فراخوانی میکنیم:
@page "/" <h1>Components with synchronous OnInitialized()</h1> @for (int i = 0; i < 5; i++) { <SynchronousInitComponent /> }
Components with synchronous OnInitialized() Sync rendered by thread 4 Sync rendered by thread 4 Sync rendered by thread 4 Sync rendered by thread 4 Sync rendered by thread 4
حال همین آزمایش را با متدهای نامتقارن یا ناهمزمان انجام میدهیم. کامپوننت AsynchronousInitComponent را با کد زیر درنظر بگیرید:
<p>Async rendered by thread @IdOfRenderingThread</p> @code { int IdOfRenderingThread; protected override async Task OnInitializedAsync() { // Runs synchronously as there is no code in base.OnInitialized(), // so the same thread is used await base.OnInitializedAsync().ConfigureAwait(false); IdOfRenderingThread = System.Threading.Thread.CurrentThread.ManagedThreadId; // Awaiting will schedule a job for later, and we will be assigned // whichever worker thread is next available await Task.Delay(1000).ConfigureAwait(false); IdOfRenderingThread = System.Threading.Thread.CurrentThread.ManagedThreadId; } }
@page "/async-init" <h1>Components with asynchronous OnInitializedAsync()</h1> @for (int i = 0; i < 5; i++) { <AsynchronousInitComponent/> }
Components with asynchronous OnInitializedAsync() Async rendered by thread 4 Async rendered by thread 4 Async rendered by thread 4 Async rendered by thread 4 Async rendered by thread 4
Components with asynchronous OnInitializedAsync() Async rendered by thread 7 Async rendered by thread 18 Async rendered by thread 10 Async rendered by thread 13 Async rendered by thread 11
نظرات مطالب
پردازشهای Async در Entity framework 6
با سلام؛ من از کد زیر استفاده کردم اما همواره خطا میده.
توی serviceLayer :
و توی کنترلر Home برنامه
اما همواره خطای زیر رو میده
ممنون میشم راهنمایی فرمایید
توی serviceLayer :
public async Task<IList<NewsSliderModel>> GetNewsSliderTable(CancellationToken cancellationToken = default(CancellationToken)) { IQueryable<News> selectednews = _news.Take(_sliderTakeCount).AsQueryable(); ... ... return await selectednews.Select(x => new NewsSliderModel { NewsId = x.Id, Title = x.Title, ImagePath = x.ImagePath, ImageTitle = x.ImageTitle, ImageDescription = x.ImageDescription, }).ToListAsync(); }
public virtual async Task<ActionResult> MainSlider() { IList<NewsSliderModel> SliderList = await _newsService.GetNewsSliderTable(Order.Descending, NewsOrderBy.Id); return PartialView(MVC.Home.Views._MainSlider, SliderList.ToList()); }
HttpServerUtility.Execute blocked while waiting for an asynchronous operation to complete.
روش سنتی بررسی نال بودن اشیاء و متغیرها در زبان #C، استفاده از اپراتور == است:
اما از زمان C# 7.0 و معرفی pattern matching، از واژهی کلیدی is نیز میتوان برای اینکار استفاده کرد (که به آن constant pattern هم میگویند):
اکنون سؤال اینجا است که امروز بهتر است از کدامیک استفاده کنیم؟
سربارگذاری عملگرها و مقایسهی وهلههای اشیاء با null
در عمل، تفاوتی بین استفادهی از عملگر == و واژهی کلیدی is برای بررسی نال بودن وهلهای از یک شیء وجود ندارد؛ اما ... با یک شرط! فقط در حالتیکه عملگر == سربارگذاری نشده باشد.
برای نمونه کلاس Person زیر را در نظر بگیرید که عملگرهای == و =! آن بازنویسی شدهاند:
در این حالت اگر قطعه کد زیر را اجرا کنیم که در یک سطر آن، وهلهی person که مقدار نال را دارد، توسط عملگر == با null مقایسه شدهاست و در سطر بعدی با کمک واژهی کلیدی is با نال مقایسه شدهاست:
به نظر شما خروجی این قطعه کد چیست؟
اگر در کلاس Person سربارگذاری عملگر == صورت نمیگرفت، خروجی زیر را مشاهده میکردیم:
اما اینبار خروجی واقعی قطعه کد فوق، با چیزی که انتظار داریم متفاوت است:
مزیت کار با واژهی کلیدی is، صرفنظر کردن از operator overloads یا همان سربارگذاری عملگرها است. در حین حالت فقط مقدار person، با null مقایسه میشود و دیگر، کار به بررسی خروجی false زیر نمیرسد (کاری که با استفاده از عملگر == حتما انجام خواهد شد):
به عبارتی استفادهی از عملگر == جهت مقایسهی با null، حتما نیاز به بررسی کدهای کلاس Person را جهت مشاهدهی کدهای تغییر یافتهی عملگر == را نیز دارد؛ اما زمانیکه از وژهی کلیدی is استفاده میکنیم، مقصود اصلی ما را که بررسی مقدار جاری با null است، برآورده میکند (و در 99 درصد موارد، ما هدف دیگری را دنبال نمیکنیم و برای ما مهم نیست که عملگر == سربارگذاری شدهاست یا خیر). همچنین سرعت مقایسه در حالت استفاده از واژهی کلیدی is نیز بیشتر است؛ چون دیگر فراخوانی کدی که عملگر == را سربارگذاری میکند، صورت نخواهد گرفت و از زمان C# 9.0، برای حالت بررسی حالت عکس آن میتوان از if (obj is not null) نیز استفاده کرد (بجای if (!(obj is null))) که از حالت سربارگذاری عملگر =! صرفنظر میکند.
یک نکته: null coalescing operator یعنی ?? و null coalescing assignment operator یعنی =?? نیز همانند واژهی کلیدی is عمل میکنند. یعنی از == سربارگذاری شده صرفنظر خواهند کرد.
if(person == null) { }
if(person is null) { }
سربارگذاری عملگرها و مقایسهی وهلههای اشیاء با null
در عمل، تفاوتی بین استفادهی از عملگر == و واژهی کلیدی is برای بررسی نال بودن وهلهای از یک شیء وجود ندارد؛ اما ... با یک شرط! فقط در حالتیکه عملگر == سربارگذاری نشده باشد.
برای نمونه کلاس Person زیر را در نظر بگیرید که عملگرهای == و =! آن بازنویسی شدهاند:
public class Person { public static bool operator ==(Person x, Person y) { return false; } public static bool operator !=(Person x, Person y) { return !(x == y); } public override bool Equals(object obj) { return base.Equals(obj); } }
Person person = null; Console.WriteLine("Is Person null?"); Console.WriteLine($"== says: {person == null}"); Console.WriteLine($"is says: {person is null}");
اگر در کلاس Person سربارگذاری عملگر == صورت نمیگرفت، خروجی زیر را مشاهده میکردیم:
Is Person null? == says: True is says: True
Is Person null? == says: False is says: True
public static bool operator ==(Person x, Person y) { return false; }
یک نکته: null coalescing operator یعنی ?? و null coalescing assignment operator یعنی =?? نیز همانند واژهی کلیدی is عمل میکنند. یعنی از == سربارگذاری شده صرفنظر خواهند کرد.
اشتراکها
از window.event استفاده نکنید!
اشتراکها