مطالب
سیستم‌های توزیع شده در NET. - بخش پنجم - اهداف
در بخشهای قبل، دلایل بوجود آمدن سیستمهای توزیع شده بررسی شد و تاکید کردیم که نیازمندی‌ها، باعث تغییر و تکامل سیستمهای ما می‌شوند و بر همین اساس بررسی کردیم که چه نیازمندی‌هایی باعث می‌شوند که دیگر سیستم‌های متمرکز به تنهایی پاسخگوی نیازهای ما نباشند و عاملی شوند برای رفتن به سمت سیستمهای توزیع شده. گفتیم که اتخاذ تصمیمات نادرست چه عواقبی را برای سیستمهای ما بوجود می‌آورد و بر همین اساس مهمترین فاکتورها را در انتخاب سیستم‌های توزیع شده، به شما معرفی کردیم. تعاریف مختلفی از این نوع سیستم‌ها را در اختیار شما قرار دادیم؛ خصوصیات، مزایا و معایب سیستمهای توزیع شده را به شما معرفی کردیم، تا با دید باز، یک انتخاب درست را با کمترین میزان ریسک انجام دهیم.
در این بخش ما 4 هدف اصلی را که باید در سیستم‌های توزیع شده برآورده شوند، بر اساس ارزش آنها مورد بررسی قرار می‌دهیم. یک سیستم توزیع شده باید اولا منابع را به آسانی در دسترس کاربران قرار دهد. دوما شفاف باشد و تمام پیچیدگی‌های یک سیستم توزیع شده را از دید کاربر، مخفی کند. سوما باز و قابل گسترش باشد؛ بصورتیکه به آسانی و با شفافیت کامل بتوانیم اجزای جدیدی را به آن اضافه کنیم. چهارما مقیاس پذیر باشد؛ بصورتیکه بدون اینکه مشکلی برای سیستم بوجود بیاید، بتوانیم منابع موجود سیستم را افزایش دهیم. در این بخش جزئیات هر یک از این اهداف را مورد بررسی قرار می‌دهیم.


اهداف سیستم‌های توزیع شده

1- Connecting resources and users: مشخص‌ترین و اصلی‌ترین هدف سیستم‌های توزیع شده، اتصال کاربران به منابع و اشتراک منابع بصورت کنترل شده با کارآیی بالا برای کاربران است. به‌صورتیکه کاربران  به آسانی به منابع دسترسی داشته باشند. منظور از منابع، هرچیزی در سیستمهای توزیع شده می‌تواند باشد. منابعی مانند داده‌ها، سخت‌افزارها، فایلها، Componentها، زیرسیستمها و هر چیز دیگری که کاربران می‌توانند بصورت مستقیم و غیر مستقیم به آنها دسترسی داشته باشند. یکی از مهمترین دلایل دسترسی به این هدف، مسائل اقتصادی است. بطور مثال ممکن است ما سیستم خودمان را طوری طراحی کنیم که پردازش‌های بسیار مهم و پیچیده در تعدادی از سخت افزار‌های بسیار پر هزینه انجام شوند. به این صورت ما این سخت افزارها را برای سایر قسمت‌های سیستم، به اشتراک میگزاریم و از طریق دیگر قسمتهای سیستم، دسترسی آن را به کاربران می‌دهیم. در این حالت دیگر نیازی نیست هر قسمت جداگانه در سیستم، سخت افزاری بسیار قوی را برای خودش نیاز داشته باشد. یا زمانیکه ما یک زیرسیستم را یکبار پیاده سازی می‌کنیم و دسترسی آن را به سایر قسمت‌ها میدهیم، سایر سیستمها، دیگر نیازی نیست آن زیرسیستم را برای خودشان پیاده سازی کنند و تنها از زیرسیستم موجود استفاده می‌کنند. دسترسی به این هدف باعث می‌شود تا کاربران به راحتی به تمام منابع موجود در سیستم‌های توزیع شده دسترسی داشته باشند.

2- Distribution transparency: بدلیل پیچیدگی‌های بسیار زیاد در سیستم‌های توزیع شده، شفافیت، کمک بسیار بزرگی به سادگی نحوه تعامل کاربر با سیستم‌های توزیع شده می‌کند. شفافیت در سیستم‌های توزیع شده بدین معنا است که سیستم باید تمام پیچیدگی‌های خود را از دید کاربر مخفی کند و پیاده سازی سیستم بصورت توزیع شده نباید هیچ پیچیدگی را در نحوه تعامل کاربر با سیستم بوجود بیاورد.
درواقع در سیستمهای توزیع شده، درخواست دریافت شده، در بین منابع سیستم توزیع می‌شود. تمام منابع با همکاری که با یکدیگر انجام می‌دهند، درخواست مورد نظر را پردازش کرده و پاسخ لازم را به کاربر ارائه می‌دهند. در این بین ممکن است منابع موجود در سیستم، رفتارهای متفاوتی را داشته باشند؛ مثلا هر زیرسیستم در سخت افزار و سیستم عامل جداگانه‌ای اجرا شود که باعث می‌شود حتی نحوه دستیابی به فایل‌ها یا داده‌های هر زیرسیستم نیز با سایر زیرسیستمها متفاوت باشد. شفافیت در سیستمهای توزیع شده بدین معنا است که یک سیستم توزیع شده باید خود را به‌صورت یک سیستم واحد که در یک سخت افزار ارائه می‌شود، ارائه دهد تا کاربران هیچ نگرانی در نحوه تعامل با سیستم نداشته باشند. شفافیت در سیستمهای توزیع شده جنبه‌های مختلفی دارد که در این قسمت آنها را بررسی می‌کنیم.


جنبه‌های مختلف شفافیت در سیستم‌های توزیع شده

1- Access Transparency: شفافیت در دسترسی به منابع یا مخفی کردن پیچیدگی‌ها و روشهای مختلف دسترسی به منابع. زیر سیستم‌های متفاوت ممکن است در سیستم عامل‌های متفاوتی نیز اجرا شوند و همانطور که می‌دانید هر سیستم عامل ممکن است نحوه دسترسی به منابعش با سایر سیستم عامل‌ها متفاوت باشد. در اینجا ما باید زیر سیستم‌های خود را طوری طراحی کنیم تا این تفاوت‌های در نحوه دسترسی به منابع را از دید کاربر مخفی کنند و این حس را به کاربر بدهد که سیستم، یک روش واحدی را برای دسترسی به منابع دارد.

2- Location Transparency: شفافیت در مکان منابع و مخفی کردن اینکه منابع در سطح شبکه توزیع شده‌اند. این جنبه بیان می‌کند که کاربران نمی‌توانند بگویند که منابع بصورت فیزیکی در سخت افزار‌های متفاوتی توزیع شده‌اند.کاربران هیچ درکی از اینکه ممکن است منابع حتی بصورت جغرافیایی در مکان‌های بسیار دوری از یکدیگر قرار گرفته‌اند، ندارند.

3- Migration Transparency: مخفی کردن اینکه ممکن است مکان منابع تغییر یابند. در یک سیستم توزیع شده ممکن است به هر دلیلی، مکان منابع تغییر کند. بطور مثال ممکن است با افزایش داده‌ها نیاز به افزودن Node جدیدی به سیستم باشد تا قسمتی از داده‌های سیستم از این پس از طریق این Node در دسترس باشند. این جابجایی منابع نباید هیچ تاثیری در نحوه‌ی تعامل کاربر داشته باشد.

4- Relocation Transparency: مخفی کردن اینکه منابع ممکن است در زمان استفاده، تغییر مکان دهند. در این حالت دقیقا در زمانیکه شخص در حال استفاده از منابع است ممکن است منابع جابجا شوند که این جابجایی در زمان استفاده از منابع نباید هیچ تاثیری در نحوه تعامل کاربر با سیستم داشته باشد. بطور مثال زمانیکه دو کاربر از طریق تلفن همراه در حال ارسال اطلاعات برای یکدیگر هستند، جابجایی هر یک از این دو کاربر، نباید تاثیری در جریان ارتباطی آنها داشته باشد.

5- Replication Transparency: مخفی کردن اینکه منابع در چند جا کپی شده‌اند. در یک سیستم توزیع شده برای بهبود کارآیی و دسترسی ممکن است منابع در چند جای مختلف کپی شوند و شفافیت در Replication می‌گوید ما باید این واقعیت را که ممکن است منابع ما در سخت افزارهای مختلفی کپی شده باشند، از دید کاربر مخفی کنیم.

6- Concurrency Transparency: مخفی کردن اینکه ممکن است منابع، بین چند کاربر مشترک باشند. بدلیل بالا بودن تعداد کاربران در سیستمهای توزیع شده، همزمانی در دسترسی به منابع مشترک، بسیار بیشتر اتفاق می‌افتد و این مهم است که هیچ یک از کاربران ندانند که کاربر دیگری بصورت همزمان در حال استفاده از آن داده است.

7- Failure Transparency: مخفی کردن خرابی و بازیابی منابع یک سیستم توزیع شده، از کاربر. در یک سیستم توزیع شده ممکن است منابع به هر دلیلی از دسترس خارج شوند. در این صورت نباید از دسترس خارج شدن منابع و بازیابی آنها هیچ تاثیری در جریان تعامل کاربر با سیستم داشته باشد.


البته این نکته را نیز بگویم اگرچه شفافیت یکی از اهداف بسیار مهم سیستم‌های توزیع شده‌است و ما نیز باید سیستمی را طراحی کنیم که تا حد امکان به این هدف دست پیدا کند، اما بدلیل این که گاهی ممکن است شفافیت تاثیر مخربی بر روی کاربر داشته باشد، باید درجه‌هایی  را برای آن در نظر بگیریم. بطور مثال زمانیکه دو کاربر از طریق تلفن همراه خود با یکدیگر در ارتباطند، نیازی به مخفی کردن موقعیت مکانی آنها نیست. یا در سیستم‌های موقعیت یاب، اصل بر این است که موقعیت منابع مختلف مشخص باشند. یا زمانیکه قرار است یک درخواست را برای یک چاپگر ارسال کنیم بهتر است درخواست ما به نزدیکترین چاپگر به ما ارسال شود تا اینکه به یک چاپگر در جایی دیگر ارسال شود. منظور از دستیابی به این هدف این است که پیچیدگی سیستم‌های توزیع شده باید از دید کاربر مخفی بماند تا تاثیر مخربی بر روی کاربر نداشته باشد؛ در صورتیکه نیاز کاربر به عدم شفافیت برخی از قسمتهای سیستم باشد بهتر است درجه‌هایی را برای سیستم‌های توزیع شده در نظر بگیریم.



3- Openness: باز بودن یا قابل گسترش بودن سیستم‌های توزیع شده یکی دیگر از اهداف بسیار مهم این سیستمها می‌باشد. به این صورت که یک سیستم در حال اجرا باید توانایی اضافه کردن منابع جدید را داشته باشد. بطور مثال با افزوده شدن نیازمندی‌های جدید، نیاز می‌شود که یک زیر سیستم جدید یا Component جدید را پیاده سازی کنیم. قسمت جدید به راحتی و بدون تاثیر در جریان تعامل کاربر باید بتواند به سیستم اضافه شود. در اکثر موارد این هدف با استفاده از یکسری قراردادهای مشخص که تمامی زیر سیستم‌ها آنها را می‌شناسند و رعایت می‌کنند، محقق می‌شود.

4- Scalability: مقیاس پذیری سیستم‌های توزیع شده بدین معنی است که با رشد مواردی مانند تعداد پردازش و درخواست یا موقعیت جغرافیایی کاربران، سیستم قادر باشد بدون تاثیر بر جریان تعامل کاربر با سیستم، آنها را پوشش دهد. یعنی بطور مثال زمانیکه تعداد درخواست‌های کاربران سیستم افزایش می‌یابد، با Replicate قسمتهای موجود سیستم در سخت افزار‌های جدید می‌توانیم بار پردازشی را بین تعداد بیشتری از Node‌ها تقسیم کنیم. به این صورت سیستم می‌تواند بدون از دسترس خارج شدن، تعداد بیشتری از درخواستهای کاربران را پوشش دهد. یا زمانیکه قرار است موقعیت‌های جدید جغرافیایی را سیستم پوشش دهد، با اضافه کردن منابع مورد نیاز، در آن موقعیت جغرافیایی، سیستم قادر است نیاز کاربران آن مکان جغرافیایی را برآورده کند.


 تا به این قسمت از سری مقالات سیستم‌های توزیع شده، هدف من این بوده که با چرایی وجود این نوع از سیستم‌ها و نحوه‌ی انتخاب آنها و اهداف سیستم‌های توزیع شده آشنا شوید. در بخش‌های بعد، روشهای مختلف طراحی و پیاده سازی سیستم‌های توزیع شده را مورد بررسی قرار می‌دهیم و می‌بینیم که چه ابزارهایی برای پیاده سازی سیستم‌های توزیع شده در NET. وجود دارند و با توجه به نوع کارآیی هر یک از این ابزارها، آنها را بصورت جداگانه مورد استفاده قرار می‌دهیم تا با مزایا و معایب هریک آشنا شویم. البته این را نیز ذکر کنم که با توجه به تعاریف سیستم‌های توزیع شده، انواع مختلفی از سیستم‌های توزیع شده وجود دارند که ما از قبل با برخی از آنها آشنا هستیم؛ معماری‌هایی مانند Client/Server یا N-Tier  نمونه‌هایی از سیستم‌های توزیع شده هستند که در آنها وظایف، در سخت افزارهای متفاوتی تقسیم شده و ارتباط هر قسمت از طریق سرویس‌هایی که ما پیاده سازی می‌کنیم، صورت می‌پذیرد و به دلیل اینکه مطمئنا همه شما با نحوه طراحی و پیاده سازی آنها و نحوه ارتباط قسمتهای مختلف آنها آشنا هستید، در سری مقالات سیستمهای توزیع شده در NET.، دیگر نیازی به توضیحی در مورد آنها نمی‌باشد. هدف من از قسمت‌های مرتبط با پیاده سازی سیستم‌های توزیع شده، چگونگی تکامل معماری‌هایی مانند N-Tier بوسیله ابزارهایی است که با هدف دستیابی به خصوصیات و اهداف سیستم‌های توزیع شده بوجود آمده‌اند.  
مطالب
خواندنی‌های 19 تیر


امنیت

توسعه وب

دات نت فریم ورک

دبلیو سی اف

دبلیو پی اف و سیلور لایت

متفرقه

محیط‌های مجتمع توسعه

مرورگرها

مسایل انسانی، اجتماعی و مدیریتی برنامه نویسی

ویندوز

پی اچ پی

اشتراک‌ها
معرفی کتابخانه InfiniteEnumFlags

Enum‌های دات نت با [Flags] attribute, ویژگی قدرتمندی است که امکان ذخیره و ترکیب چندین گزینه یا Feature را تنها به صورت یک مقدار ثابت فراهم میکند که از طریق Bitwise operator‌ها میتوانیم به ترکیب چندین Enum بپردازیم و یا از طریق این مقدار ثابت به تک تک اعضای تشکیل دهنده آن برسیم. ولی مشکل بزرگی این این ویژگی دارد محدودیت آن است که برای Enum هایی از نوع int تنها 32 آیتم و از نوع long تنها 64 مورد را پشتیبانی میکند. این مشکل سبب میشود در اکثر سناریو‌ها به سراغ این ویژگی نرویم, 

به طور مثال برای تعریف دسترسی‌های یک نرم افزار به صورت Strongly Type به احتمال زیاد با بزرگ‌تر شدن برنامه در آینده به مشکل برخورد میکنیم.

InfiniteEnumFlags کتابخانه کوچکی است که تمام امکانات [Flags] را در اختیار ما میگذارد و میتواند حدود 2.1 میلیارد آیتم را پشتیبانی کند. 

public class Permission : InfiniteEnum<Permission>
{
    public static readonly Flag<Permission> None = new(-1);
    public static readonly Flag<Permission> ViewRoles = new(0);
    public static readonly Flag<Permission> ManageRoles = new(1);
    public static readonly Flag<Permission> ViewUsers = new(2);
    public static readonly Flag<Permission> ManageUsers = new(3);
    public static readonly Flag<Permission> ConfigureAccessControl = new(4);
    public static readonly Flag<Permission> Counter = new(5);
    public static readonly Flag<Permission> Forecast = new(6);
    public static readonly Flag<Permission> ViewAccessControl = new(7);

    // We can support up to 2,147,483,647 items

}


مثال استفاده از آن برای تعریف سطح دسترسی‌ها در برنامه‌های Asp.net core  در فولدر Example این مخزن میتوانید پیدا کنید.

 git clone --recurse-submodules https://github.com/alirezanet/InfiniteEnumFlags.git


معرفی کتابخانه  InfiniteEnumFlags
مطالب
کاهش تعداد بار تعریف using ها در C# 10.0 و NET 6.0.
در مطلب «روش بازگشت به قالب‌های کلاسیک پروژه‌ها در دات نت 6» مشاهده کردیم که قالب پیش‌فرض یک برنامه‌ی کنسول دات نت 6، چنین فایل Program.cs ای را تولید می‌کند:
// See https://aka.ms/new-console-template for more information
Console.WriteLine("Hello, World!");
که در حقیقت همان اجبار به استفاده‌ی از سبک «Top Level Programs» ارائه شده‌ی در C# 9.0 است. اما اگر به همین دو سطر هم دقت کنید، یک تفاوت مهم را با نمونه‌ی C# 9.0 دارد و آن هم عدم ذکر عبارت using System در ابتدای آن است. علت اینجا است که فایل csproj پیش‌فرض پروژه‌های مبتنی بر NET 6.0.، دو تغییر مهم دیگر را هم دارند:
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net6.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>
</Project>
الف) فعال بودن nullable reference types که در C# 8.0 ارائه شد.
ب) فعال بودن ImplicitUsings که مختص به C# 10.0 است.


بررسی مفهوم  global using directives در C# 10.0

هدف اصلی از وجود Using directives در زبان #C که از نگارش 1 آن در دسترس هستند، خلاصه نویسی نام طولانی اشیاء و متدها است. برای مثال نام اصلی متد Console.WriteLine به صورت System.Console.WriteLine است که با درج فضای نام System در ابتدای فایل، می‌توان از ذکر مجدد آن جلوگیری کرد. از این دست می‌توان به نوع System.Collections.Generic.List نیز اشاره کرد که کمتر کسی علاقمند است تا این نام طولانی را تایپ کند. به همین جهت با استفاده از یک using directive متناظر با فضای نام System.Collections.Generic، ذکر نام این نوع، به List خلاصه می‌شود.
طراحی دات نت 6 مبتنی بر سبک minimalism است! برای نمونه خلاصه کردن نزدیک به 10 سطر فایل Program.cs کلاسیک، به تنها یک سطر که به همراه ذکر using System در ابتدای آن هم نیست. در C# 10.0 دیگر نیازی نیست تا برای مثال ذکر using System را در ده‌ها و یا صدها فایل، بارها و بارها تکرار کرد. برای اینکار تنها کافی است یکبار آن‌را به صورت global تعریف کنیم و پس از آن دیگر نیازی به ذکر آن در کل پروژه نیست:
global using System;
می‌توان این سطر را در ابتدای یک تک فایل cs. قرار داد و ذکر آن به معنای الحاق خودکار آن، در ابتدای تک تک فایل‌های cs. برنامه است.

چند نکته:
- امکان ترکیب global using‌ها و using‌ها معمولی در یک فایل هست.
- امکان تعریف global using‌های استاتیک نیز پیش‌بینی شده‌است:
global using static System.Console;
که برای نمونه در این حالت بجای ذکر Console.WriteLine، تنها ذکر نام متد WriteLine در سراسر برنامه کفایت می‌کند.


مفهوم جدید implicit global using directives در C# 10.0 و به کمک NET SDK 6.0.

تا اینجا دریافتیم که می‌توان دایرکتیوهای سراسری using را در برنامه به صورت دستی تعریف و استفاده کرد. اما ... پروژه‌ی کنسولی که به صورت پیش‌فرض توسط NET SDK 6.0. ایجاد می‌شود، به همراه هیچ global using ای نیست. این مورد توسط تنظیم زیر که جزئی از NET SDK 6.0. است، فعال می‌شود:
<ImplicitUsings>enable</ImplicitUsings>
زمانیکه ImplicitUsings را در فایل csproj برنامه فعال می‌کنیم، یعنی قرار است از یکسری global using‌های از پیش تعریف شده‌ی توسط SDK استفاده کنیم. بنابراین «global using directives» جزئی از ویژگی‌های جدید C# 10.0 است اما « implicit global using directives» تنها یک لطف ارائه شده‌ی توسط NET SDK. است. برای یافتن لیست آن‌ها، پروژه را build کرده و سپس به پوشه‌ی obj\Debug\net6.0 مراجعه کنید. در اینجا به دنبال فایلی مانند MyProjectName. GlobalUsings.g.cs بگردید. محتویات آن به صورت زیر است:
// <auto-generated/>
global using global::System;
global using global::System.Collections.Generic;
global using global::System.IO;
global using global::System.Linq;
global using global::System.Net.Http;
global using global::System.Threading;
global using global::System.Threading.Tasks;
این‌ها همان global using هایی هستند که با فعالسازی تنظیم ImplicitUsings در فایل csproj، به صورت خودکار توسط NET SDK. تولید و به برنامه الحاق می‌شوند.
البته این فایل ویژه به ازای نوع‌های پروژه‌های مختلف، محتوای متفاوتی را دارد. برای مثال در برنامه‌های ASP.NET Core، چنین محتوای پیش‌فرضی را پیدا می‌کند:
// <autogenerated />
global using global::System;
global using global::System.Collections.Generic;
global using global::System.IO;
global using global::System.Linq;
global using global::System.Net.Http;
global using global::System.Threading;
global using global::System.Threading.Tasks;
global using global::System.Net.Http.Json;
global using global::Microsoft.AspNetCore.Builder;
global using global::Microsoft.AspNetCore.Hosting;
global using global::Microsoft.AspNetCore.Http;
global using global::Microsoft.AspNetCore.Routing;
global using global::Microsoft.Extensions.Configuration;
global using global::Microsoft.Extensions.DependencyInjection;
global using global::Microsoft.Extensions.Hosting;
global using global::Microsoft.Extensions.Logging;
این تعاریف در اصل در پوشه‌ی C:\Program Files\dotnet\sdk\6.0.100-rc.2.21505.57\Sdks\Microsoft.NET.Sdk\targets و در فایل Microsoft.NET.GenerateGlobalUsings.targets آن قرار دارند.


روش حذف و یا اضافه‌ی global using‌های پیش‌فرض

اگر به هر دلیلی نمی‌خواهید تعدادی از global usingهای پیش‌فرض به همراه گزینه‌ی ImplicitUsings استفاده کنید، می‌توانید آن‌ها را در فایل csproj به صورت زیر، Remove و یا حتی موارد جدیدی را Include کنید:
<ItemGroup>
   <Import Remove="System.Threading" />
   <Import Include="Microsoft.Extensions.Logging" />
</ItemGroup>
یکی از کاربردهای این قابلیت، تولید کتابخانه‌های multi-target است که می‌توان توسط Conditionها، فضاهای نامی را که نباید برای target خاصی include کرد، مشخص نمود:
<ItemGroup Condition="'$(TargetFramework)' == 'net472'">
</ItemGroup>
بازخوردهای دوره
بررسی مقدماتی مراحل کامپایل یک قطعه کد سی‌شارپ و آشنایی با OpCodes
سلام جناب نصیری
ممنون. این تیپ مقالات خیلی جذابند و البته عمق خوبی به بینش برنامه نویس می‌دهد .
یک سوال
یادم هست در فروم برنامه نویس چشمم به مطلب خورده که نوشته بود امکان دارد که کدهای دات نت تبدیل به کدهای ماشین کرد که دیگر نیازی به نصب دات نت فریم ورک بر روی سیستم مقصد نباشد
یعنی میتوان تمام نیازمندیهای برنامه را از دل فریم ورک بیرون کشید و به برنامه اضافه کرد و در نهایت یک فایل اجرایی قبال اجرا بدون نیاز به فریم

ممکنه توضیح بدهید در این خصوص؟
ممنون  و متشکرم.
نظرات اشتراک‌ها
سری 11 قسمتی معماری تمیز با Angular 10 و Web API
این پروژه از آخرین نسخه LTS دات نت یعنی .net core 3.1 استفاده می‌کنه
ولی یک پروژه خوب راجع به همین موضوع هست که انگیولار ۱۰ به همراه دات نت نسخه ۵ و معماری تمیز (Clean Architecture) استفاده می‌کنه و به صورت بسته نیوگت هم عرضه می‌شه که آدرس گیت هاب:
هست.
نظرات اشتراک‌ها
نگارش بعدی ASP.NET Core از Full .NET Framework پشتیبانی نمی‌کند
بحث اصلی مطلب جاری این است که NET Core. (پیاده سازی) با NET Standard. (قرارداد) یکی نیست. NET Core. یکی از پیاده سازی‌های NET Standard. است؛ مانند دات نت 4.6.1 که آن هم پیاده سازی کننده‌ی دات نت استاندارد 2 است. هر دوی این‌ها دارای یک سری API خاص خودشان هم هستند که در NET Standard. وجود ندارند. سطح API دات نت Core هم بیشتر است از NET Standard. و در یکسری از موارد هم کاملا ناسازگار با دات نت کامل. بنابراین توافقی که در اینجا وجود دارد، صرفا پیاده سازی قرارداد NET Standard. است و بیشتر از آن هم مربوط است به توسعه دهندگان آن سکوی کاری خاص که الزامی به یکی بودن آن‌ها نیست.
کاری که پیشتر می‌خواستند انجام دهند، محدود کردن ASP.NET Core به سطح API موجود در NET Core. بود (NET Core 2.0 only. یا تصویر زیر) و نه صرفا به NET Standard. . این مساله برای توسعه دهندگان ASP.NET Core می‌توانست فوق العاده باشد؛ چون سطح API بیشتر و به‌روزتری را در اختیارشان قرار می‌داد و اگر قابلیتی در NET Standard. وجود نداشت، نمی‌بایستی درخواست می‌دادند تا اضافه شود تا بعد بتوانند استفاده کنند.


اما چون این مساله و سطح API بیشتر و گاهی از اوقات کاملا متفاوت، سازگاری با کتابخانه‌هایی را که در میدان دید این API قرار نمی‌گرفتند، زیر سؤال می‌برد، ارتقاء برنامه‌های قبلی را با مشکل مواجه می‌کرد. به همین جهت تصمیم گرفته‌اند که ASP.NET Core را سازگار با دات نت فریم ورک کامل نیز ارائه دهند و بنابراین «محدودش کنند» به NET Standard 2.0.  و نه حالت NET Core only‌. قبلی: اطلاعات بیشتر


به علاوه باید درنظر داشت که امکان اضافه کردن یک بسته‌ی نیوگت از یک کتابخانه‌ی نوشته شده‌ی برای دات نت کامل در برنامه‌های دات نت Core به معنای تضمینی برای کار کردن آن در زمان اجرا نخواهد بود. از این جهت که دات نت کامل، به همراه قسمت‌هایی است که در NET Standard. وجود خارجی ندارند. بنابراین اگر کتابخانه‌ی استفاده شده صرفا این API مشترک را هدف قرار داده‌است، هم قابلیت اتصال و هم قابلیت اجرا را خواهد داشت؛ اما اگر برای مثال کسی بسته‌ی NServiceBus را به پروژه‌ی ASP.NET Core 2.0 اضافه کند، بدون مشکل کامپایل خواهد شد. اما از آنجائیکه این کتابخانه از MSMQ استفاده می‌کند که خارج از میدان دید این استاندارد است، در زمان اجرا با شکست مواجه خواهد شد.
نظرات مطالب
رمزنگاری خودکار فیلدها توسط Entity Framework Core
- شاید جالب باشد بدانید که EF-Core با دانت 4x هم قابل استفاده‌است. البته تا EF Core 3x بر اساس NET Standard 2.0. کامپایل شده و با دات نت 4x سازگاری دارد. اما EF Core 5x بر اساس NET Standard 2.1. کامپایل شده و با دات نت 4x دیگر سازگار نیست.
- با توجه به اینکه عملیات انجام شده در سطح کلاینت انجام می‌شود، می‌توان معادل آن‌را با AutoMapper هم انجام داد.
- و یا می‌توان با استفاده از change tracker این تغییرات را اعمال کرد.