نظرات مطالب
EF Code First #12
نظر شما در مورد این پیاده سازی الگوی کار چیه؟
نظرات مطالب
چک لیست تهیه یک برنامه ASP.NET MVC
راه معادل پیاده سازی سبد خرید.
نظرات مطالب
EF Code First #11
اگر امکان دارد نمونهای از این نوع پیاده سازی را برای NH معرفی کنید.
نظرات مطالب
تکمیل کلاس DelegateCommand
راهی برای پیاده سازی این موضوع در سیلورلایت وجود دارد؟!!!
پاسخ به بازخوردهای پروژهها
خطای Payment Is Not Valid
Storage رو خودتون پیاده سازی کردید؟
قبل از اینکه به httpmoduleها بپردازیم، اجازه بدید کمی در در مورد httphandler اطلاعات کسب کنیم. httphandler ویژگی است که از asp.net به بعد ایجاد شد و در asp کلاسیک خبری از آن نیست.
یک httphandler کامپوننتی است که از طریق اینترفیس System.Web.IHttpHandler پیاده سازی میشود و به پردازش درخواستهای رسیده از httprequest رسیدگی میکند.
فرض کنید کاربری درخواست صفحه default.aspx را کرده است و سرور هم پاسخ آن را میدهد. در واقع پردازش اینکه چه پاسخی باید به کاربر یا کلاینت ارسال شود بر عهده این کامپوننت میباشد. برای وب سرویس هم موضوع به همین صورت است؛ هر نوع درخواست HTTP از این طریق انجام میشود.
حال به سراغ httpmodule میرویم. httpmoduleها اسمبلی یا ماژولهایی هستن که بر سر راه هر درخواست کاربر از سرور قرار گرفته و قبل از اینکه درخواست شما به httphandler برسد، اول از فیلتر اینها رد میشود. در واقع موقعی که شما درخواست صفحه default.aspx را میکنید، درخواست شما به موتور asp.net ارسال میشود و از میان فیلترهایی رد میشود تا به دست httphandler برای پردازش خروجی برسد. برای همین اگر گاهی به جای گفتن asp.net engine عبارت asp.net pipeline هم میگویند همین هست؛ چون درخواست شما از بین بخشهای زیادی میگذرد تا به httphandler برسد که httpmodule یکی از آن بخش هاست. با هر درخواستی که سرور ارسال میشود، httpmoduleها صدا زده میشوند و به برنامه نویس امکان بررسی اطلاعات درخواستی و پردازش درخواستها را در ورودی و خروجی، میدهد و شما میتوانید هر عملی را که نیاز دارید انجام دهید. تعدادی از این ماژولهای آماده، همان stateها و Authentication میباشند.
تصویر زیر نحوهی ارسال و بازگشت یک درخواست را به سمت httphandler نشان میدهد
برنامه نویس هم میتواند با استفاده از اینترفیسهای IHttpModule و IHttpHandler در درخواستها دخالت نماید.
برای شروع یک کلاس ایجاد کنید که اینترفیس IHttpModule را پیاده سازی میکند. شما دو متد را باید در این کلاس بنویسید؛ یکی Init و دیگر Dispose. همانطور که مطلع هستید، اولی در ابتدای ایجاد شیء و دیگر موقع از دست رفتن شی صدا زده میشود.
متد Init یک آرگومان از نوع httpapplication دارد که مانند رسم نامگذاری متغیرها، بیشتر به اسم context یا app نام گذاری میشوند:
public void Init(HttpApplication app) { app.BeginRequest += new EventHandler(OnBeginRequest); } public void Dispose(){ }
BeginRequest | این رویداد اولین رویدادی است که اجرا میشود، هر نوع عملی که میخواهید در ابتدای ارسال درخواست انجام دهید، باید در این قسمت قرار بگیرد؛ مثلا قرار دادن یک بنر بالای صفحه |
AuthenticateRequest | خود دانت از یک سیستم امنیتی توکار بهره مند است و اگر میخواهید در مورد آن خصوصی سازی انجام بدهید، این رویداد میتواند کمکتان کند |
AuthorizeRequest | بعد از رویداد بالا، این رویداد برای شناسایی انجام میشود. مثلا دسترسی ها؛ دسترسی به قسمت هایی خاصی از منابع به او داده شود و قسمت هایی بعضی از منابع از او گرفته شود. |
ResolveRequestCache | این رویداد برای کش کردن اطلاعات استفاده میشود. خود دانت تمامی این رویدادها را به صورت تو کار فراهم آورده است؛ ولی اگر باز خصوصی سازی خاصی مد نظر شماست میتوانید در این قسمتها، تغییراتی را اعمال کنید. مثلا ایجاد file caching به جای memory cache و ... |
AcquireRequestState | این قسمت برای مدیریت state میباشد مثلا مدیریت session ها |
PreRequestHandlerExecute | این رویداد قبل از httphandler اجرا میشود. |
PostRequestHandlerExecute | این رویداد بعد از httphandler اجرا میشود. |
ReleaseRequestState | این رویداد برای این صدا زده میشود که به شما بگوید عملیات درخواست پایان یافته است و باید stateهای ایجاد شده را release یا رها کنید. |
UpdateRequestCache | برای خصوصی سازی output cache بکار میرود. |
EndRequest | عملیات درخواست پایان یافته است. در صورتیکه قصد نوشتن دیباگری در طی تمامی عملیات دارید، میتواند به شما کمک کند. |
PreSendRequestHeaders | این رویداد قبل از ارسال طلاعات هدر هست. اگر قصد اضافه کردن اطلاعاتی به هدر دارید، این رویداد را به کار ببرید. |
PreSendRequestContent | این رویداد موقعی صدا زده میشود که متد response.flush فراخوانی شود.، اگر میخواهید به محتوا چیزی اضافه کنید، از اینجا کمک بگیرید. |
Error | این رویداد موقعی رخ میدهد که یک استثنای مدیریت نشده رخ بدهد. برای نوشتن سیستم خطایابی خصوصی از این قسمت عمل کنید. |
Disposed | این رویداد موقعی صدا زده میشود که درخواست، بنا به هر دلیلی پایان یافته است. برای عملیات پاکسازی و .. میشود از آن استفاده کرد. مثلا یک جور rollback برای کارهای انجام گرفته. |
کد زیر را در نظر بگیرید:
کد زیر یک رویداد را تعریف کرده و سپس خود httpapplication را به عنوان sender استفاده میکند.
در اینجا قصد داریم یکی از صفحات را در خروجی تغییر دهیم. آدرس تایپ شده همان باشد ولی صفحهی درخواست شده، صفحهی دیگری است. این کار موقعی بیشتر کاربردی است که آدرس یک صفحه تغییر کرده و کاربر آدرس قبلی را وارد میکند. حالا یا از طریق بوک مارک یا از طریق یک لینک، در یک جای دیگر و شما میخواهید او را به صفحهای جدید انتقال دهید، ولی در نوار آدرس، همان آدرس قبلی باقی بماند. همچنین کار دیگری که قرار است انجام بگیرد محاسبه مدت زمان رسیدگی به درخواست را محاسبه کند ، برای همین در رویداد BeginRequest زمان شروع درخواست را ذخیره و در رویداد EndRequest با به دست آوردن اختلاف زمان فعلی با زمان شروع به مدت زمان مربوطه پی خواهیم برد.
با استفاده از app.Context.Request.RawUrl آدرس اصلی و درخواست شده را یافته و در صورتی که شامل نام صفحه مربوطه بود، با نام صفحهی جدید جابجا میکنیم تا اطلاعات به صفحهی جدید پاس شوند ولی در نوار آدرس، هنوز آدرس قبلی یا درخواست شده، قابل مشاهده است.
در خط ["app.Context.Items["start که یک کلاس ارث بری شده از اینترفیس IDictionary است، بر اساس کلید، داده شما را ذخیره و در مواقع لزوم در هر رویداد به شما باز میگرداند.
public class UrlPath : IHttpModule { public void Init(HttpApplication app) { app.BeginRequest+=new EventHandler(_BeginRequest); app.EndRequest+=new EventHandler(_EndRequest); } public void Dispose() { } void _BeginRequest(object sender, EventArgs e) { HttpApplication app = (HttpApplication) sender; app.Context.Items["start"] = DateTime.Now; if (app.Context.Request.RawUrl.ToLower().Contains("tours_list.aspx")) { app.Context.RewritePath(app.Context.Request.RawUrl.ToLower().Replace("tours_list.aspx","tours_cat.aspx")); } } void _EndRequest(object sender, EventArgs e) { HttpApplication app = (HttpApplication)sender; string log = (DateTime.Now - DateTime.Parse(app.Context.Items["start"].ToString())).ToString(); Debugger.Log(0,"duration","request took " + log+Environment.NewLine); } }
<httpModules> <add name="UrlPath" type="UrlPath"/> </httpModules>
اگر کلاس شما داخل یک namespace قرار دارد، در قسمت type حتما قبل از نام کلاس، آن را تعریف کنید namspace.ClassName
حالا دیگر کلاس UrlPath به عنوان یک httpmodule به سیستم معرفی شده است. تگ httpmodule را بین تگ <system.web> قرار داده ایم.
در ادامه پروژه را start بزنید تا نتیجه کار را ببینید:
اگر IIS شما، هم نسخهی IIS من باشد، نباید تفاوتی مشاهده کنید و میبینید که درخواستها هیچ تغییری نکردند؛ چرا که اصلا httpmodule اجرا نشده است. در واقع در نسخههای قدیمی IIS یعنی 6 به قبل، این تعریف درست است ولی از نسخهی 7 به بعد IIS، روش دیگری برای تعریف را قبول دارد و باید تگ httpmodule، بین دو تگ <syste.webserver> قرار بگیرد و نام تگ httpmodule به module تغییر پیدا کند.
پس کد فوق به این صورت تغییر میکند:
<system.webServer> <modules> <add name="UrlRewrite" type="UrlRewrite"/> </modules> </system.webServer>
<validation validateIntegratedModeConfiguration="false"/>
HTTP Error 500.22 - Internal Server Error
در کل استفاده از این ماژول به شما کمک میکند تمامی اطلاعات ارسالی به سیستم را قبل از رسیدن به قسمت پردازش بررسی نمایید و هر نوع تغییری را که میخواهید اعمال کنید و لازم نیست این تغییرات را روی هر بخش، جداگانه انجام دهید یا یک کلاس بنویسید که هر بار در یک جا صدا بزنید و خیلی از موارد دیگر
Global.asax و HttpModule
اگر با global.asax کار کرده باشید حتما میپرسید که الان چه تفاوتی با httpmodule دارد؟ در فایل global هم همینها را دارید و دقیقا همین مزایا مهیاست؛ در واقع global.asax یک پیاده سازی از httpapplication هست.
کلاسهای httpmodule نام دیگری هم دارند به اسم Portable global .asax به معنی یک فایل global.asax قابل حمل یا پرتابل. دلیل این نام گذاری این هست که شما موقعی که یک کد را در فایل global مینویسید، برای همیشه آن کد متعلق به همان پروژه هست و قابل انتقال به یک پروژه دیگر نیست ولی شما میتوانید httpmoduleها را در قالب یک پروژه به هر پروژه ای که دوست دارید رفرنس کنید و کد شما قابلیت استفاده مجدد و Reuse پیدا میکند و هم اینکه در صورت نیاز میتوانید آنها را در قالب یک dll منتشر کنید.
فرض کنید قرارداد IService را تدارک دیدهاید و بر اساس آن سرویسهای A و B را به سیستم تزریق وابستگیهای برنامههای NET Core. تزریق کردهاید (برای مثال در برنامه دو DbContext را تعریف کردهاید و یک اینترفیس IUnitOfWork را دارید). اکنون اگر از این سیستم، یک پیاده سازی IService را درخواست کنید، چه اتفاقی رخ میدهد؟ در حالت معمول آن، آخرین سرویسی را که ثبت کردهاید، یعنی وهلهای از سرویس B را بازگشت خواهد داد. در ادامه قصد داریم با این قابلیت امکان ثبت چندین سرویس مشتق شدهی از یک اینترفیس، بیشتر آشنا شویم.
ثبت پیاده سازیهای متعدد یک اینترفیس در سیستم تزریق وابستگیهای NET Core.
داشتن چندین پیاده سازی از یک اینترفیس، شاید یکی از اهداف اصلی وجود آنها باشد. برای نمونه قرار داد ارسال پیامی را در برنامه، مانند IMessageService به صورت زیر طراحی و سپس بر اساس آن، دو پیاده سازی ارسال پیامها را از طریق ایمیل و SMS، اضافه میکنیم:
در ادامه برای معرفی آنها به سیستم تزریق وابستگیهای NET Core.، به نحو متداول زیر عمل خواهیم کرد و هر دوی این پیاده سازیها را بر اساس اینترفیس آنها معرفی میکنیم:
در این حالت اگر این سرویسها را به صورت زیر به یک کنترلر تزریق کنیم، انتظار دریافت کدام سرویسها را خواهید داشت؟
در این حالت اگر بر روی سازندهی این کنترلر یک break-point را قرار دهیم، پارامترهای تزریق شدهی در سازندهی کلاس به صورت زیر خواهند بود:
همانطور که مشاهده میکنید، هر دو پارامتر، با وهلهای از آخرین سرویس معرفی شدهی از نوع IMessageService مقدار دهی شدهاند؛ یعنی SmsService در اینجا. در ادامه روشهای مختلفی را برای رفع این مشکل بررسی میکنیم.
روش اول: سیستم تزریق وابستگیهای NET Core. از سازندههای IEnumerable پشتیبانی میکند
برای مدیریت دریافت سرویسهایی که از یک اینترفیس مشتق شدهاند، خود NET Core. بدون نیاز به تنظیمات اضافهتری، روش تزریق IEnumerableها را در سازندههای کلاسها پشتیبانی میکند:
در اینجا نیز اگر بر روی سازندهی این کنترلر یک break-point را قرار دهیم، پارامتر تزریق شدهی در سازندهی کلاس به صورت زیر خواهد بود:
به این ترتیب لیست وهلههای تمام سرویسهایی از نوع IMessageService در اختیار ما قرار گرفتهاست و برای اهدافی مانند پیاده سازی الگوهایی در ردهی chain of responsibility و یا الگوی استراتژی، مفید است. در این حالت اگر نیاز به سرویس از نوع خاصی وجود داشت، میتوان از روش زیر استفاده کرد:
و یا اگر از روش Service Locator استفاده میکنید، serviceProvider به همراه متد ویژهی GetServices که لیست تمام سرویسهایی از نوعی خاص را بر میگرداند نیز هست:
روش دوم: دریافت شرطی وهلههای مورد نیاز با «دخالت در مراحل وهله سازی اشیاء توسط IoC Container»
روش «دخالت در مراحل وهله سازی اشیاء توسط IoC Container» را در قسمت قبل بررسی کردیم. یکی دیگر از مثالهایی را که در این مورد میتوان ارائه داد، شرطی کردن بازگشت وهلهها است که برای سناریوی مطلب جاری بسیار مفید است:
الف) برای شرطی کردن بازگشت وهلهها، بهتر است این شرط را بجای رشتهها و یا اعدادی خاص، بر اساس یک enum مشخص انجام دهیم:
در اینجا یک enum جدید را تعریف کردهایم تا مقایسهها را در زمان بازگشت سرویسی خاص، بر اساس اعضای مشخص آن انجام دهیم.
ب) سپس هر دو سرویس مشتق شدهی از یک اینترفیس را به صورت معمولی ثبت میکنیم:
اینکار سبب خواهد شد تا بتوانیم در حین بررسی شرطهای رسیده، برای مثال دستور ()<serviceProvider.GetService<EmailService را صادر کنیم.
ج) اکنون میتوان مرحلهی شرطی کردن بازگشت این وهلهها را به صورت زیر، با دخالت در مراحل وهله سازی اشیاء، پیاده سازی کرد:
در اینجا پارامتر ارسالی به متد AddTransient را از نوع <Func<MessageServiceType, IMessageService انتخاب کردهایم. این مورد نیز دقیقا مانند «مثال 2: وهله سازی در صورت نیاز وابستگیهای یک سرویس به کمک Lazy loading» قسمت قبل عمل میکند. یعنی تا زمانیکه این Func، در قسمتی از کدهای برنامه فراخوانی نشود، سرویسی را نیز بازگشت نخواهد داد.
د) مرحلهی آخر کار، روش استفادهی از این امضایء ویژهی Lazy load شدهاست:
دقیقا همان امضای Func ای را که در متد AddTransient معرفی تنظیمات تزریق وابستگیها تعریف کردیم، به سازندهی یک کنترلر تزریق میکنیم. تا اینجای کار هنوز هیچکدام از سرویسهای از نوع IMessageService وهله سازی نشدهاند (روش دیگر پیاده سازی وهله سازی با تاخیر و در صورت نیاز). اکنون برای وهله سازی آنها باید به صورت زیر عمل کرد:
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید: CoreDependencyInjectionSamples-07.zip
ثبت پیاده سازیهای متعدد یک اینترفیس در سیستم تزریق وابستگیهای NET Core.
داشتن چندین پیاده سازی از یک اینترفیس، شاید یکی از اهداف اصلی وجود آنها باشد. برای نمونه قرار داد ارسال پیامی را در برنامه، مانند IMessageService به صورت زیر طراحی و سپس بر اساس آن، دو پیاده سازی ارسال پیامها را از طریق ایمیل و SMS، اضافه میکنیم:
namespace CoreIocServices { public interface IMessageService { void Send(string message); } public class EmailService : IMessageService { public void Send(string message) { // ... } } public class SmsService : IMessageService { public void Send(string message) { //todo: ... } } }
namespace CoreIocSample02 { public class Startup { public void ConfigureServices(IServiceCollection services) { services.AddTransient<IMessageService, EmailService>(); services.AddTransient<IMessageService, SmsService>(); }
using CoreIocServices; using Microsoft.AspNetCore.Mvc; namespace CoreIocSample02.Controllers { public class MessagesController : Controller { private readonly IMessageService _emailService; private readonly IMessageService _smsService; public MessagesController(IMessageService emailService, IMessageService smsService) { _emailService = emailService; _smsService = smsService; } } }
همانطور که مشاهده میکنید، هر دو پارامتر، با وهلهای از آخرین سرویس معرفی شدهی از نوع IMessageService مقدار دهی شدهاند؛ یعنی SmsService در اینجا. در ادامه روشهای مختلفی را برای رفع این مشکل بررسی میکنیم.
روش اول: سیستم تزریق وابستگیهای NET Core. از سازندههای IEnumerable پشتیبانی میکند
برای مدیریت دریافت سرویسهایی که از یک اینترفیس مشتق شدهاند، خود NET Core. بدون نیاز به تنظیمات اضافهتری، روش تزریق IEnumerableها را در سازندههای کلاسها پشتیبانی میکند:
using System.Collections.Generic; using CoreIocServices; using Microsoft.AspNetCore.Mvc; namespace CoreIocSample02.Controllers { public class MessagesController : Controller { private readonly IEnumerable<IMessageService> _messageServices; public MessagesController(IEnumerable<IMessageService> messageServices) { _messageServices = messageServices; }
به این ترتیب لیست وهلههای تمام سرویسهایی از نوع IMessageService در اختیار ما قرار گرفتهاست و برای اهدافی مانند پیاده سازی الگوهایی در ردهی chain of responsibility و یا الگوی استراتژی، مفید است. در این حالت اگر نیاز به سرویس از نوع خاصی وجود داشت، میتوان از روش زیر استفاده کرد:
var emailService = _messageServices.OfType<EmailService>().First();
var messageServices = serviceProvider.GetServices<IMessageService>();
روش دوم: دریافت شرطی وهلههای مورد نیاز با «دخالت در مراحل وهله سازی اشیاء توسط IoC Container»
روش «دخالت در مراحل وهله سازی اشیاء توسط IoC Container» را در قسمت قبل بررسی کردیم. یکی دیگر از مثالهایی را که در این مورد میتوان ارائه داد، شرطی کردن بازگشت وهلهها است که برای سناریوی مطلب جاری بسیار مفید است:
الف) برای شرطی کردن بازگشت وهلهها، بهتر است این شرط را بجای رشتهها و یا اعدادی خاص، بر اساس یک enum مشخص انجام دهیم:
namespace CoreIocServices { public enum MessageServiceType { EmailService, SmsService }
ب) سپس هر دو سرویس مشتق شدهی از یک اینترفیس را به صورت معمولی ثبت میکنیم:
namespace CoreIocSample02 { public class Startup { public void ConfigureServices(IServiceCollection services) { services.AddTransient<EmailService>(); services.AddTransient<SmsService>();
ج) اکنون میتوان مرحلهی شرطی کردن بازگشت این وهلهها را به صورت زیر، با دخالت در مراحل وهله سازی اشیاء، پیاده سازی کرد:
namespace CoreIocSample02 { public class Startup { public void ConfigureServices(IServiceCollection services) { services.AddTransient<EmailService>(); services.AddTransient<SmsService>(); services.AddTransient<Func<MessageServiceType, IMessageService>>(serviceProvider => key => { switch (key) { case MessageServiceType.EmailService: return serviceProvider.GetRequiredService<EmailService>(); case MessageServiceType.SmsService: return serviceProvider.GetRequiredService<SmsService>(); default: throw new NotImplementedException($"Service of type {key} is not implemented."); } });
د) مرحلهی آخر کار، روش استفادهی از این امضایء ویژهی Lazy load شدهاست:
namespace CoreIocSample02.Controllers { public class MessagesController : Controller { private readonly Func<MessageServiceType, IMessageService> _messageServiceResolver; public MessagesController(Func<MessageServiceType, IMessageService> messageServiceResolver) { _messageServiceResolver = messageServiceResolver; }
public IActionResult Index() { var emailService = _messageServiceResolver(MessageServiceType.EmailService); //use emailService ... return View(); }
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید: CoreDependencyInjectionSamples-07.zip
سلام
توی یه پیاده سازی Singleton به این روش من نیاز دارم
1) از یه سرویس برای فراخوانی دادهها به روش تزریق وابستگی استفاده کنم (که از Autofac استفاده میکنم)
2) و اینکه متدی که دادهها رو فراخوانی میکنه Async هست. چطور از اون متد توی این کلاس Singleton استفاده کنم ؟
من الان میخواهم یک Action در TestDBController ایجاد کنم و یک دستور sql update مستقیما بزنم به دیتابیس. این دستور رو در اکشن بصورت
باید بنویسم یا بهتره اول در Interface و کلاس مربوطه دستور فوق رو پیاده سازی کنم و
_un.ExecuteSqlCommand("Update command");
_blogService.SqlCmd("update command ");
بنویسم.