اشتراکها
اشتراکها
NET Core 3.0 Preview 6. منتشر شد
Today, we are announcing .NET Core 3.0 Preview 6. It includes updates for compiling assemblies for improved startup, optimizing applications for size with linker and EventPipe improvements. We’ve also released new Docker images for Alpine on ARM64.
اشتراکها
استفاده از React و TypeScript
اگر در کدهای خود قطعه کد ذیل را دارید:
استفادهی از using در اینجا، نهتنها غیرضروری و اشتباه است، بلکه سبب از کار افتادن زود هنگام برنامهی شما با صدور استثنای ذیل خواهد شد:
HttpClient خود را Dispose نکنید
کلاس HttpClient اینترفیس IDisposable را پیاده سازی میکند. بنابراین روش استفادهی اصولی آن باید به صورت ذیل و با پیاده سازی خودکار رهاسازی منابع مرتبط با آن باشد:
اما در این حال فرض کنید به همین روش تعدادی درخواست را ارسال کردهاید:
مشکل این روش، در ایجاد سوکتهای متعددی است که حتی پس از بسته شدن برنامه نیز باز، باقی خواهند ماند:
این یک نمونهی خروجی برنامهی فوق، توسط دستور netstat «پس از بسته شدن کامل برنامه» است.
بنابراین اگر برنامهی شما تعداد زیادی کاربر دارد و یا تعداد زیادی درخواست را به روش فوق ارسال میکند، سیستم عامل به حد اشباع ایجاد سوکتهای جدید خواهد رسید.
این مشکل نیز ارتباطی به طراحی این کلاس و یا زبان #C و حتی استفادهی از using نیز ندارد. این رفتار، رفتار معمول سیستم عامل، با سوکتهای ایجاد شدهاست. TIME_WAIT ایی را که در اینجا ملاحظه میکنید، به معنای بسته شدن اتصال از طرف برنامهی ما است؛ اما سیستم عامل هنوز منتظر نتیجهی نهایی، از طرف دیگر اتصال است که آیا قرار است بستهی TCP ایی را دریافت کند یا خیر و یا شاید در بین راه تاخیری وجود داشتهاست. برای نمونه ویندوز به مدت 240 ثانیه یک اتصال را در این حالت حفظ خواهد کرد، که مقدار آن نیز در اینجا تنظیم میشود:
بنابراین روش توصیه شدهی کار با HttpClient، داشتن یک وهلهی سراسری از آن در برنامه و عدم Dispose آن است. HttpClient نیز thread-safe طراحی شدهاست و دسترسی به یک شیء سراسری آن در برنامههای چند ریسمانی مشکلی را ایجاد نمیکند. همچنین Dispose آن نیز غیرضروری است و پس از پایان برنامه به صورت خودکار توسط سیستم عامل انجام خواهد شد.
تمام اجزای HttpClient به صورت Thread-safe طراحی نشدهاند
تا اینجا به این نتیجه رسیدیم که روش صحیح کار کردن با HttpClient، نیاز به داشتن یک وهلهی Singleton از آنرا در سراسر برنامه دارد و Dispose صریح آن، بجز اشباع سوکتهای سیستم عامل و ناپایدار کردن تمام برنامههایی که از آن سرویس میگیرند، حاصلی را به همراه نخواهد داشت. در این بین مطابق مستندات HttpClient، استفادهی از متدهای ذیل این کلاس thread-safe هستند:
اما تغییر این خواص در کلاس HttpClient به هیچ عنوان thread-safe نبوده و در برنامههای چند ریسمانی و چند کاربری، مشکل ساز میشوند:
بنابراین در طراحی کلاس مدیریت کنندهی HttpClient برنامهی خود نیاز است به ازای هر BaseAddress، یک HttpClient خاص آنرا ایجاد کرد و HttpClientهای سراسری نمیتوانند BaseAddressهای خود را نیز به اشتراک گذاشته و تغییری را در آن ایجاد کنند.
استفادهی سراسری و مجدد از HttpClient، تغییرات DNS را متوجه نمیشود
با طراحی یک کلاس مدیریت کنندهی سراسری HttpClient با طول عمر Singelton، به یک مشکل دیگر نیز برخواهیم خورد: چون در اینجا از اتصالات، استفادهی مجدد میشوند، دیگر تغییرات DNS را لحاظ نخواهند کرد.
برای حل این مشکل، در زمان ایجاد یک HttpClient سراسری، به ازای یک BaseAddress مشخص، باید از ServicePointManager کوئری گرفته و زمان اجارهی اتصال آنرا دقیقا مشخص کنیم:
با اینکار هرچند هنوز هم از اتصالات استفادهی مجدد میشود، اما این استفادهی مجدد، نامحدود نبوده و مدت معینی را پیدا میکند.
طراحی یک کلاس، برای مدیریت سراسری وهلههای HttpClient
تا اینجا به صورت خلاصه به نکات ذیل رسیدیم:
- HttpClient باید به صورت یک وهلهی سراسری Singleton مورد استفاده قرار گیرد. هر وهله سازی مجدد آن 35ms زمان میبرد.
- Dispose یک HttpClient غیرضروری است.
- HttpClient تقریبا thread safe طراحی شدهاست؛ اما تعدادی از خواص آن مانند BaseAddress اینگونه نیستند.
- برای رفع مشکل اتصالات چسبنده (اتصالاتی که هیچگاه پایان نمییابند)، نیاز است timeout آنرا تنظیم کرد.
بنابراین بهتر است این نکات را در یک کلاس به صورت ذیل کپسوله کنیم:
در اینجا به ازای هر baseAddress جدید، یک HttpClient خاص آن ایجاد میشود تا در کل برنامه مورد استفادهی مجدد قرار گیرد. برای مدیریت thread-safe ایجاد HttpClientها نیز از نکتهی مطلب «الگویی برای مدیریت دسترسی همزمان به ConcurrentDictionary» استفاده شدهاست. همچنین نکات تنظیم ConnectionLeaseTimeout و سایر خواص غیر thread-safe کلاس HttpClient نیز در اینجا لحاظ شدهاند.
پس از تدارک این کلاس، نحوهی معرفی آن به سیستم باید به صورت Singleton باشد. برای مثال اگر از ASP.NET Core استفاده میکنید، آنرا به صورت ذیل ثبت کنید:
اکنون، یک نمونه، نحوهی استفادهی از اینترفیس IHttpClientFactory تزریقی به صورت ذیل میباشد:
سرویس IHttpClientFactory یک HttpClient را به ازای host درخواستی ایجاد کرده و در طول عمر برنامه از آن استفادهی مجدد میکند. به همین جهت دیگر مشکل اشباع سوکتها در این سیستم رخ نخواهند داد.
برای مطالعهی بیشتر
You're using HttpClient wrong and it is destabilizing your software
Disposable, Finalizers, and HttpClient
Using HttpClient as it was intended (because you’re not)
Singleton HttpClient? Beware of this serious behaviour and how to fix it
Beware of the .NET HttpClient
Effectively Using HttpClient
using(var client = new HttpClient()) { // do something with http client }
Unable to connect to the remote server System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted.
HttpClient خود را Dispose نکنید
کلاس HttpClient اینترفیس IDisposable را پیاده سازی میکند. بنابراین روش استفادهی اصولی آن باید به صورت ذیل و با پیاده سازی خودکار رهاسازی منابع مرتبط با آن باشد:
using (var client = new HttpClient()) { var result = await client.GetAsync("http://example.com/"); }
for (int i = 0; i < 10; i++) { using (var client = new HttpClient()) { var result = await client.GetAsync("http://example.com/"); Console.WriteLine(result.StatusCode); } }
TCP 192.168.1.6:13996 93.184.216.34:http TIME_WAIT TCP 192.168.1.6:13997 93.184.216.34:http TIME_WAIT TCP 192.168.1.6:13998 93.184.216.34:http TIME_WAIT TCP 192.168.1.6:13999 93.184.216.34:http TIME_WAIT TCP 192.168.1.6:14000 93.184.216.34:http TIME_WAIT TCP 192.168.1.6:14001 93.184.216.34:http TIME_WAIT TCP 192.168.1.6:14002 93.184.216.34:http TIME_WAIT TCP 192.168.1.6:14003 93.184.216.34:http TIME_WAIT TCP 192.168.1.6:14004 93.184.216.34:http TIME_WAIT TCP 192.168.1.6:14005 93.184.216.34:http TIME_WAIT
بنابراین اگر برنامهی شما تعداد زیادی کاربر دارد و یا تعداد زیادی درخواست را به روش فوق ارسال میکند، سیستم عامل به حد اشباع ایجاد سوکتهای جدید خواهد رسید.
این مشکل نیز ارتباطی به طراحی این کلاس و یا زبان #C و حتی استفادهی از using نیز ندارد. این رفتار، رفتار معمول سیستم عامل، با سوکتهای ایجاد شدهاست. TIME_WAIT ایی را که در اینجا ملاحظه میکنید، به معنای بسته شدن اتصال از طرف برنامهی ما است؛ اما سیستم عامل هنوز منتظر نتیجهی نهایی، از طرف دیگر اتصال است که آیا قرار است بستهی TCP ایی را دریافت کند یا خیر و یا شاید در بین راه تاخیری وجود داشتهاست. برای نمونه ویندوز به مدت 240 ثانیه یک اتصال را در این حالت حفظ خواهد کرد، که مقدار آن نیز در اینجا تنظیم میشود:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpTimedWaitDelay]
بنابراین روش توصیه شدهی کار با HttpClient، داشتن یک وهلهی سراسری از آن در برنامه و عدم Dispose آن است. HttpClient نیز thread-safe طراحی شدهاست و دسترسی به یک شیء سراسری آن در برنامههای چند ریسمانی مشکلی را ایجاد نمیکند. همچنین Dispose آن نیز غیرضروری است و پس از پایان برنامه به صورت خودکار توسط سیستم عامل انجام خواهد شد.
تمام اجزای HttpClient به صورت Thread-safe طراحی نشدهاند
تا اینجا به این نتیجه رسیدیم که روش صحیح کار کردن با HttpClient، نیاز به داشتن یک وهلهی Singleton از آنرا در سراسر برنامه دارد و Dispose صریح آن، بجز اشباع سوکتهای سیستم عامل و ناپایدار کردن تمام برنامههایی که از آن سرویس میگیرند، حاصلی را به همراه نخواهد داشت. در این بین مطابق مستندات HttpClient، استفادهی از متدهای ذیل این کلاس thread-safe هستند:
CancelPendingRequests DeleteAsync GetAsync GetByteArrayAsync GetStreamAsync GetStringAsync PostAsync PutAsync SendAsync
BaseAddress DefaultRequestHeaders MaxResponseContentBufferSize Timeout
استفادهی سراسری و مجدد از HttpClient، تغییرات DNS را متوجه نمیشود
با طراحی یک کلاس مدیریت کنندهی سراسری HttpClient با طول عمر Singelton، به یک مشکل دیگر نیز برخواهیم خورد: چون در اینجا از اتصالات، استفادهی مجدد میشوند، دیگر تغییرات DNS را لحاظ نخواهند کرد.
برای حل این مشکل، در زمان ایجاد یک HttpClient سراسری، به ازای یک BaseAddress مشخص، باید از ServicePointManager کوئری گرفته و زمان اجارهی اتصال آنرا دقیقا مشخص کنیم:
var sp = ServicePointManager.FindServicePoint(new Uri("http://thisisasample.com")); sp.ConnectionLeaseTimeout = 60*1000; //In milliseconds
طراحی یک کلاس، برای مدیریت سراسری وهلههای HttpClient
تا اینجا به صورت خلاصه به نکات ذیل رسیدیم:
- HttpClient باید به صورت یک وهلهی سراسری Singleton مورد استفاده قرار گیرد. هر وهله سازی مجدد آن 35ms زمان میبرد.
- Dispose یک HttpClient غیرضروری است.
- HttpClient تقریبا thread safe طراحی شدهاست؛ اما تعدادی از خواص آن مانند BaseAddress اینگونه نیستند.
- برای رفع مشکل اتصالات چسبنده (اتصالاتی که هیچگاه پایان نمییابند)، نیاز است timeout آنرا تنظیم کرد.
بنابراین بهتر است این نکات را در یک کلاس به صورت ذیل کپسوله کنیم:
using System; using System.Collections.Generic; using System.Net.Http; namespace HttpClientTips { public interface IHttpClientFactory : IDisposable { HttpClient GetOrCreate( Uri baseAddress, IDictionary<string, string> defaultRequestHeaders = null, TimeSpan? timeout = null, long? maxResponseContentBufferSize = null, HttpMessageHandler handler = null); } }
using System; using System.Collections.Concurrent; using System.Collections.Generic; using System.Net; using System.Net.Http; using System.Threading; namespace HttpClientTips { /// <summary> /// Lifetime of this class should be set to `Singleton`. /// </summary> public class HttpClientFactory : IHttpClientFactory { // 'GetOrAdd' call on the dictionary is not thread safe and we might end up creating the HttpClient more than // once. To prevent this Lazy<> is used. In the worst case multiple Lazy<> objects are created for multiple // threads but only one of the objects succeeds in creating the HttpClient. private readonly ConcurrentDictionary<Uri, Lazy<HttpClient>> _httpClients = new ConcurrentDictionary<Uri, Lazy<HttpClient>>(); private const int ConnectionLeaseTimeout = 60 * 1000; // 1 minute public HttpClientFactory() { // Default is 2 minutes: https://msdn.microsoft.com/en-us/library/system.net.servicepointmanager.dnsrefreshtimeout(v=vs.110).aspx ServicePointManager.DnsRefreshTimeout = (int)TimeSpan.FromMinutes(1).TotalMilliseconds; // Increases the concurrent outbound connections ServicePointManager.DefaultConnectionLimit = 1024; } public HttpClient GetOrCreate( Uri baseAddress, IDictionary<string, string> defaultRequestHeaders = null, TimeSpan? timeout = null, long? maxResponseContentBufferSize = null, HttpMessageHandler handler = null) { return _httpClients.GetOrAdd(baseAddress, uri => new Lazy<HttpClient>(() => { // Reusing a single HttpClient instance across a multi-threaded application means // you can't change the values of the stateful properties (which are not thread safe), // like BaseAddress, DefaultRequestHeaders, MaxResponseContentBufferSize and Timeout. // So you can only use them if they are constant across your application and need their own instance if being varied. var client = handler == null ? new HttpClient { BaseAddress = baseAddress } : new HttpClient(handler, disposeHandler: false) { BaseAddress = baseAddress }; setRequestTimeout(timeout, client); setMaxResponseBufferSize(maxResponseContentBufferSize, client); setDefaultHeaders(defaultRequestHeaders, client); setConnectionLeaseTimeout(baseAddress, client); return client; }, LazyThreadSafetyMode.ExecutionAndPublication)).Value; } public void Dispose() { foreach (var httpClient in _httpClients.Values) { httpClient.Value.Dispose(); } } private static void setConnectionLeaseTimeout(Uri baseAddress, HttpClient client) { // This ensures connections are used efficiently but not indefinitely. client.DefaultRequestHeaders.ConnectionClose = false; // keeps the connection open -> more efficient use of the client ServicePointManager.FindServicePoint(baseAddress).ConnectionLeaseTimeout = ConnectionLeaseTimeout; // ensures connections are not used indefinitely. } private static void setDefaultHeaders(IDictionary<string, string> defaultRequestHeaders, HttpClient client) { if (defaultRequestHeaders == null) { return; } foreach (var item in defaultRequestHeaders) { client.DefaultRequestHeaders.Add(item.Key, item.Value); } } private static void setMaxResponseBufferSize(long? maxResponseContentBufferSize, HttpClient client) { if (maxResponseContentBufferSize.HasValue) { client.MaxResponseContentBufferSize = maxResponseContentBufferSize.Value; } } private static void setRequestTimeout(TimeSpan? timeout, HttpClient client) { if (timeout.HasValue) { client.Timeout = timeout.Value; } } } }
پس از تدارک این کلاس، نحوهی معرفی آن به سیستم باید به صورت Singleton باشد. برای مثال اگر از ASP.NET Core استفاده میکنید، آنرا به صورت ذیل ثبت کنید:
namespace HttpClientTips.Web { public class Startup { public void ConfigureServices(IServiceCollection services) { services.AddSingleton<IHttpClientFactory, HttpClientFactory>(); services.AddMvc(); }
اکنون، یک نمونه، نحوهی استفادهی از اینترفیس IHttpClientFactory تزریقی به صورت ذیل میباشد:
namespace HttpClientTips.Web.Controllers { public class HomeController : Controller { private readonly IHttpClientFactory _httpClientFactory; public HomeController(IHttpClientFactory httpClientFactory) { _httpClientFactory = httpClientFactory; } public async Task<IActionResult> Index() { var host = new Uri("http://localhost:5000"); var httpClient = _httpClientFactory.GetOrCreate(host); var responseMessage = await httpClient.GetAsync("home/about").ConfigureAwait(false); var responseContent = await responseMessage.Content.ReadAsStringAsync().ConfigureAwait(false); return Content(responseContent); }
برای مطالعهی بیشتر
You're using HttpClient wrong and it is destabilizing your software
Disposable, Finalizers, and HttpClient
Using HttpClient as it was intended (because you’re not)
Singleton HttpClient? Beware of this serious behaviour and how to fix it
Beware of the .NET HttpClient
Effectively Using HttpClient
اشتراکها
زبان برنامه نویسی Spider
This package helps set up SqlClient in applications using dependency injection, notably ASP.NET and Worker Service applications. It allows easy configuration of your database connections and registers the appropriate services in your DI container. It also enables you to log events from Microsoft.Data.SqlClient using standard .NET logging (ILogger).
فایلهای پروژهها
PdfRpt-2.6.7z
- Added `jqGrid to PDF Report` Sample. - Improved speed of the aggregate functions. - Removed the obsolete HTML Worker classes. - Added NuGet package references instead of local asm references. - Added a new sample to demonstrate how to convert PDF files to images, using Win8.1 API in desktop applications. - Added a new sample to demonstrate how to view PDF files, using Win8.1 API in desktop applications.
در قسمت قبل به صورت اجمالی با الگوریتمهای داده کاوی در SSDT آشنا شدید. در این قسمت به الگوریتم Naive Bayes خواهیم پرداخت.
برای روشنتر شدن مطلب، سیستم رای گیری را در نظر بگیرید، در رابطه با سیستم رای گیری از طریق این الگوریتم میتوان به پرسشهای زیر پاسخ داد:
- مهمترین آرای هر حزب چه هستند؟
- توزیع آرا در رابطه با یک عمل خاص (پرداخت یارانه یا عدم پرداخت آن) چگونه بوده است؟
- توزیع آرای یک عمل خاص درمیان آرای اعمال دیگر چگونه بوده است و چه ارتباطی بین آنها است؟
این الگوریتم، ارتباط بین ویژگیها را مشخص میکند، این درحالی است که از طریق الگوریتمهای دیگر این کار به سادگی قابل کشف نیست.
یک راه خوب برای شروع داده کاوی ساخت مدل Naïve Bayes و چک کردن ورودی و خروجی برروی تمام ستونها است. مدل حاصل سبب میشود که درک بهتری از دادهها پیدا کرده و ساخت مدلهای دیگر داده کاوی مانند درخت تصمیم و ... راحتتر انجام پذیرد. به همین جهت، اولین الگوریتم معرفی شده نیز این الگوریتم میباشد.
بنابراین زمانیکه با یک مجموعه داده جدید روبرو میشویم، راحتترین راه برای شروع داده کاوی، ساخت یک مدل از Naïve Bayes است، به طوریکه تمامی ستونهای غیرکلید را به عنوان predict یا همان هم ورودی-هم خروجی در نظر میگیریم. پس از آموزش مدل به قسمت Dependency Network میرویم. نمونه ای از شبکه وابستگیها را در شکل زیر مشاهده میکنید که در حقیقت گرافی از نودها است.
نودهای مختلف نشان دهنده ستونهای انتخاب شده هستند و جهت ارتباط بین نودها از ورودی به سمت خروجی است. ارتباطهای دوطرفه نشان دهنده این هستند که از هر یک از دو نود میتوان دیگری را پیش بینی کرد. سمت چپ این گراف در SSDT یک نوار وجود دارد (که در شکل زیر آمده است)، هرچه نوار کناری را به سمت پایین ببریم ارتباطهای قویتر نشان داده شده و ارتباط هایی که دارای قدرت کمتری هستند حذف میشوند. بنابراین زمانی که نوار کناری را در پایینترین حالت قرار دهیم میتوان قویترین ارتباط بین ستونهای ورودی و خروجی را مشاهده نمود.
نکته مهم: اگر هدف ما پیش بینی یک ویژگی باشد، ارتباط قوی ما بین دو ورودی، مشخص میکند که استفاده از هردوی آنها برای پیش بینی یک ویژگی خروجی، کاری بس اشتباه است؛ زیرا ورودیهای شبیه به هم میتوانند اثر دوبرابری داشته باشند. برای مثال در شکل بالا در صورتی که ارتباط موجود بین دو ویژگی Young Frankenstein و Monty Python and the Holy Grail قوی باشد بایستی از انتخاب هر دوی این ویژگیها به عنوان ورودی برای پیش بینی ویژگی Princess Bride پرهیز نمود.
جهت درک بهتر دادهها میتوان به قسمت Attribute Profile مراجعه نمود. همانطور که درشکل زیر آمده است در این بخش ماتریسی از نحوه ارتباط بین تمامی حالات ورودیها و خروجیها نشان داده شده است.
از لیست کشویی، خروجی مدنظر را انتخاب میکنیم و ماتریس درصد پیش بینی خروجی از روی ورودی یا ورودیها نشان داده میشود.
اگر هدف درک شباهتها و اختلافات حالتهای هدف پیش بینی باشد میتوان از دو قسمت Attribute Characteristics و Attribute Discrimination استفاده نمود. در رابطه با Attribute Characteristics دو مساله را باید در نظر داشت:
- قدرت پیش بینی ندارد یعنی نباید در این قسمت از روی ویژگیها به پیش بینی هدفی پرداخت.
- ورودی هایی که امتیازشان از مینیمم امتیاز یک گره پایینتر است نشان داده نمیشوند.
و اما در رابطه با Attribute Discrimination نیز باید قبل از هر قضاوتی، مراقب سطح پشتیبانی (support level) ویژگیها باشیم. برای مثال در رابطه با رای گیری در رابطه با یک عمل خاص مشاهده میشود که اختلاف زیادی بین حزب دموکرات و حزب مستقل وجود دارد که متاسفانه این تفسیر اشتباه است چرا که پس از بررسی مجموعه داده به این نتیجه میرسیم که داده مربوط به حزب مستقل فقط دو مورد است و هردوی آنها در این آمار آمدهاند. یعنی 100 درصد آنها و این درحالی است که داده مربوط به حزب دموکرات زیاد بوده و ممکن است این درصد اعلام شده روی این عمل خاص حتی از حزب مستقل پایینتر باشد. شکل زیر نمایی از Attribute Discrimination می باشد.
از آنجاکه فاز پردازش این الگوریتم فقط اولین دسته مرتب شده از ارتباط بین ورودی و خروجیها را حساب میکند، پس نگرانی از بابت پردازش نیست. بنابراین این الگوریتم برای مجموعه دادههای خیلی بزرگ با ویژگیهای بسیار زیاد، مناسب است.
در این الگوریتم ورودی و خروجی باید Discrete (گسسته) باشند و در صورتیکه Continuous (پیوسته) باشند بایستی Discretize شوند. البته باید درنظر داشت که در حالت کلی این الگوریتم در رابطه با دادههای Continuous کاربرد مناسبی ندارد. بنابراین پیش بینی این دادهها حتی اگر Discretize شوند با این الگوریتم خوب نیست.
در پایان بهتر است دوباره به این نکته اشاره شود که بایستی مراقب بود تا ورودیها تقریبا مستقل از یکدیگر انتخاب شوند؛ زیرا ورودیهای شبیه به هم میتوانند اثر دوبرابری و مخربی داشته باشند که بایستی از آن اجتناب کرد. به دلیل چنین رفتاری، ارزیابی مدل توسط lift chart حتما پیشنهاد میشود.
این روش منحصر به Nop نیست و امکان استفادهی از آن بر روی هر سورس دیگری نیز وجود دارد. همچنین اگر در رابطه با NopCommerce اطلاعاتی ندارید، میتوانید از اینجا جهت آشنا شدن با این فروشگاه ساز Asp.net core استفاده کنید.
مراحل پیاده سازی
یک اینترفیس را به اسم ICustomService ایجاد کردم که یک Prop به اسم InjectType دارد و مشخص میکند به چه صورتی این سرویس به ServiceCollection تزریق شود. از طرفی با استفاده از Order، الویت اضافه شدن سرویس به ServiceCollection را مشخص میکنیم و در نهایت با ImplementationType مشخص میکنیم سرویسی که اضافه شده، باید به یک اینترفیس Map شود یا خیر؟ اما مهمتر از اینکه ویژگیهای تزریق وابستگی مشخص شود، مشخص میکند چه سرویسهایی توسط ما اضافه شدهاند و از سرویسهای nop تفکیک میشوند.
قانون اول
برای هر سرویسی که ایجاد میکنیم و میخواهیم به DI معرفی کنیم، آن سرویس باید ICustomService را پیاده سازی کرده باشد؛ دقیقا به خاطر دو دلیلی که در بالا به آنها اشاره شد.
قانون دوم
هر کلاسی که Interface مرتبط به سرویسها را پیاده سازی میکند، باید prop InjectType را در سازندهی خودش مقدار دهی کند. بدین شکل متوجه میشویم از چه طریقی باید تزریق انجام شود. تا اینجا یک چارچوب را مشخص کردیم تا سرویسها را بتوانیم تشخیص دهیم\ اما هنوز کار اصلی باقی ماندهاست. برای نمونه میتوان کد زیر را در نظر گرفت :
برای پیاده سازی سرویس ایجاد شده، کد زیر را ایجاد میکنیم :
تعیین نقطه شروع
کد زیر در واقع نقطهی اتصال سرویسهای نوشته شده و اتمام کار تزریق وابستگی است. با توجه به پیاده سازیهای انجام شدهی توسط سرویسها میتوان با Reflection سرویسهای نوشته شده را تشخیص داد که در نهایت با ویژگیهایی که در سرویسها پیاده سازی شده موجود است، به ServiceCollection اضافه میشوند.
نکتهی آخر آن که این داستانها صرفا برای سرویسهایی هست که توسط برنامه نویس به پروژهی Nop اضافه میشود.
لینک گیتهاب
همانطور که در جریان هستید، برای اینکه بحث DI را در پروژه داشته باشیم، باید به ازای هر سرویس مشخص کنیم که کدام اینترفیس، به کدام کلاس، map شود. به بیان دیگر باید مشخص کرد هر وقت یک شیء از Container درخواست شد، از چه کلاسی باید این شیء ساخته شود؛ در عینحال باید LifeTime وجود شیء در حافظه نیز مشخص شود. حال تصور کنید تعداد سرویسهای شما در حال زیاد شدن است. در این حالت مجبور هستید دائما این سرویسها را ثبت کنید؛ علاوه بر اینکه باید کدهای تکراری را جهت تعریف این سرویسها بنویسید و باید بهخاطر بسپارید که سرویس جدید را ثبت کنید. در این مقاله تلاش بر این است تا دیگر نیازی به تعریف کردن تک تک سرویسها نباشد؛ بهطوری که با رعایت دو قانون کلی بتوان سرویسها را به صورت خودکار ثبت کرد.
یک اینترفیس را به اسم ICustomService ایجاد کردم که یک Prop به اسم InjectType دارد و مشخص میکند به چه صورتی این سرویس به ServiceCollection تزریق شود. از طرفی با استفاده از Order، الویت اضافه شدن سرویس به ServiceCollection را مشخص میکنیم و در نهایت با ImplementationType مشخص میکنیم سرویسی که اضافه شده، باید به یک اینترفیس Map شود یا خیر؟ اما مهمتر از اینکه ویژگیهای تزریق وابستگی مشخص شود، مشخص میکند چه سرویسهایی توسط ما اضافه شدهاند و از سرویسهای nop تفکیک میشوند.
namespace Nop.Services { public interface ICustomService { protected InjectType Inject { get; } protected int Order { get; } protected ImplementationType implementationType { get; } } public enum ImplementationType { WithInterface = 0, WithoutInterface = 1 } public enum InjectType { Scopped=0, Transit=1, SingleTon=2 } }
قانون اول
برای هر سرویسی که ایجاد میکنیم و میخواهیم به DI معرفی کنیم، آن سرویس باید ICustomService را پیاده سازی کرده باشد؛ دقیقا به خاطر دو دلیلی که در بالا به آنها اشاره شد.
قانون دوم
هر کلاسی که Interface مرتبط به سرویسها را پیاده سازی میکند، باید prop InjectType را در سازندهی خودش مقدار دهی کند. بدین شکل متوجه میشویم از چه طریقی باید تزریق انجام شود. تا اینجا یک چارچوب را مشخص کردیم تا سرویسها را بتوانیم تشخیص دهیم\ اما هنوز کار اصلی باقی ماندهاست. برای نمونه میتوان کد زیر را در نظر گرفت :
namespace Nop.Services { public interface IMyCustomService: ICustomService { int ok(); } }
namespace Nop.Services { public class MyCustomService : IMyCustomService { public InjectType Inject { get; } public int Order { get; } public ImplementationType implementationType { get; } public MyCustomService() { implementationType = ImplementationType.WithInterface; Inject = InjectType.Scopped; Order = 1; } public int ok() { return 10; } } }
تعیین نقطه شروع
باید نقطه شروع به کار Nop را پیدا کنیم. از آنجایی که با معماری Nop جلو میرویم، با کمی بررسی و دیدن کدها، به کلاسی میرسیم به اسم NopStartup در قسمت Nop.Web.Framework. مسیر دقیق آن: Nop.Web.Framework\Infrastructure\NopStartup.cs. حالا این کلاس چیست؟ در واقع هر کلاسی که از سرویس INopStartup ارث بری کرده باشد، اولویت پیدا میکند و قبل از کدهای دیگر اجرا میشود. باید کلاس جدیدی را به اسم مثلا CustomDependencyInjection ایجاد کنیم، با این تفاوت که حتما از کلاس NopStartup ارث بری کرده باشد و همچنین حتما باید متدی را به اسم ConfigureServices، بازنویسی کند. حالا داخل متدی که گفتم باید شروع کنیم به کار.
کد زیر در واقع نقطهی اتصال سرویسهای نوشته شده و اتمام کار تزریق وابستگی است. با توجه به پیاده سازیهای انجام شدهی توسط سرویسها میتوان با Reflection سرویسهای نوشته شده را تشخیص داد که در نهایت با ویژگیهایی که در سرویسها پیاده سازی شده موجود است، به ServiceCollection اضافه میشوند.
namespace Nop.Web.Framework.Infrastructure { public class CustomDependencyInjection : NopStartup { private static bool IsSubInterface(Type t1, Type t2) { if (!t2.IsAssignableFrom(t1)) return false; if (t1.BaseType == null) return true; return !t2.IsAssignableFrom(t1.BaseType); } public override void ConfigureServices(IServiceCollection services, IConfiguration configuration) { //-------------Get All Services------------- var asm = AppDomain.CurrentDomain .GetAssemblies() .Single(x => x.FullName.Contains("Nop.Services")); //-------------find Services that inheriance of ICustomService------------- var types = asm.DefinedTypes.Where(x => IsSubInterface(x, typeof(ICustomService))); //-----------Get All Custom Service Classess------- var allRelatedClassServices = types .Where(x => x.IsClass) .OrderBy(x=>(Int32)x.GetProperty("Order") .GetValue(Activator.CreateInstance(x), null)); //-----------Get All Custom Service Interfaces------- var allRelatedInterfaceServices = types.Where(x => x.IsInterface); //-----------Matche Class Services To Related Interface Services------- TypeInfo interfaceService=null; foreach (var classService in allRelatedClassServices) { //-----------detect Implementation Type for service----------- var implementationValue = (ImplementationType)classService.GetProperty("implementationType") .GetValue(Activator.CreateInstance(classService), null); //-----------detect inject type for service----------- var InjectValue = (InjectType)classService.GetProperty("Inject") .GetValue(Activator.CreateInstance(classService), null); //-----------get related interface for service class----------- if (implementationValue == ImplementationType.WithInterface) interfaceService = allRelatedInterfaceServices.Single(x => x.Name == $"I{classService.Name}"); //----------finally Add Custom Service To Service Collection----------- switch (InjectValue) { case InjectType.Scopped: if(interfaceService!=null) services.AddScoped(interfaceService, classService); else services.AddScoped(classService); break; case InjectType.Transit: if (interfaceService != null) services.AddTransient(interfaceService, classService); else services.AddTransient(classService); break; case InjectType.SingleTon: if (interfaceService != null) services.AddSingleton(interfaceService, classService); else services.AddSingleton(classService); break; default: break; } interfaceService = null; } } } }
لینک گیتهاب