نظرات مطالب
Base64 و کاربرد جالب آن
- مرسوم نیست این همه اطلاعات کد شده رو در یک tetxbox نمایش بدن. به چه دلیلی و چه مقصودی را برآورده میکند؟
- برای RichTextBox یک سری متد BeginUpdate و EndUpdate هست.
- در کد فوق میشود بجای GetExtension از متد توکار Path.GetExtension استفاده کرد.
- تصاویر وب عموما حجیم نیستند (خصوصا زمانیکه قرار است تبدیل به base64 شوند). یعنی حجم بالای 10 مگابایت ندارند که بخواهید با استریمها کار کنید. بهتر است یک ضرب از متد File.ReadAllBytes استفاده کنید. همچنین در این حالت مشخص (با توجه به حجم پایین تصاویر مورد استفاده در وب سایتها)، استفاده از تردها را هم حذف کنید.
- همیشه زمانیکه کدنویسی میکنید این سؤال رو از خودتون بپرسید:
آیا کاری که دارم انجام میدم قابلیت استفاده مجدد داره؟ میشه از قسمتی از نتیجهاش در یک پروژه دیگر استفاده کرد؟
مثلا در کد شما بهتر است قسمت تبدیل تصویر به معادل base64 آن تبدیل به یک متد کمکی با قابلیت استفاده مجدد شود تا اینکه منطق پیاده سازی آن در بین کدهای UI دفن شده باشد. مطالعه قسمت Refactoring در سایت در این زمینه مفید است.
- برای RichTextBox یک سری متد BeginUpdate و EndUpdate هست.
- در کد فوق میشود بجای GetExtension از متد توکار Path.GetExtension استفاده کرد.
- تصاویر وب عموما حجیم نیستند (خصوصا زمانیکه قرار است تبدیل به base64 شوند). یعنی حجم بالای 10 مگابایت ندارند که بخواهید با استریمها کار کنید. بهتر است یک ضرب از متد File.ReadAllBytes استفاده کنید. همچنین در این حالت مشخص (با توجه به حجم پایین تصاویر مورد استفاده در وب سایتها)، استفاده از تردها را هم حذف کنید.
- همیشه زمانیکه کدنویسی میکنید این سؤال رو از خودتون بپرسید:
آیا کاری که دارم انجام میدم قابلیت استفاده مجدد داره؟ میشه از قسمتی از نتیجهاش در یک پروژه دیگر استفاده کرد؟
مثلا در کد شما بهتر است قسمت تبدیل تصویر به معادل base64 آن تبدیل به یک متد کمکی با قابلیت استفاده مجدد شود تا اینکه منطق پیاده سازی آن در بین کدهای UI دفن شده باشد. مطالعه قسمت Refactoring در سایت در این زمینه مفید است.
- کلاس UsersManagerService اطلاعی از نحوهی پیاده سازی IMessageService ندارد. بنابراین تغییر پیاده سازی IMessageService تاثیری در کدهای فعلی این کلاس نخواهد داشت. فقط تنظیمات IoC Container ابتدای بحث اندکی تغییر خواهد کرد و نه کدهای اصلی برنامه. بنابراین بستهاست برای تغییر (کدهای فعلی آن نیازی به تغییر ندارند) و باز است برای توسعه (میتوان انواع پیاده سازیها را جهت این اینترفیسها ارائه داد).
- همچنین اگر برنامه نیاز به سرویسهای بیشتری از نوع IMessageService داشته باشد، بدیهی است باید کدهای متناظری هم از آن به کلاس UsersManagerService اضافه شوند و طراحی این کلاس تغییر کند. مانند این است که کنترلری امروز نیاز به لیست کاربران و سرویس کاربران دارد. روز بعد شاید نیاز به سرویس ارسال ایمیل به آنها را هم پیدا کند. در این حالت طراحی این کنترلر باید تغییر کند و این تغییر ناقض اصلی نیست. صرفا برآورده کردن نیاز کاری است. حتی این تغییر هم ناقض Open Closed Principle نیست؛ چون باز است جهت تعویض پیاده سازی سرویس ایمیل و بستهاست جهت تغییرات آتی، از این جهت که اطلاعی از جزئیات پیاده سازی اینترفیس و سرویس ایمیل ندارد.
- این مثال صرفا جهت حل مسالهی ASP.NET Identity ارائه شد و استفادهی از یک اینترفیس برای تمام کارها. اگر قرار بود من آنرا طراحی کنم، برای ارسال ایمیل یک اینترفیس و برای ارسال SMS یک اینترفیس دیگر ایجاد میکردم. یک طراحی خوب باید دارای حداقل ابهام باشد.
- همچنین اگر برنامه نیاز به سرویسهای بیشتری از نوع IMessageService داشته باشد، بدیهی است باید کدهای متناظری هم از آن به کلاس UsersManagerService اضافه شوند و طراحی این کلاس تغییر کند. مانند این است که کنترلری امروز نیاز به لیست کاربران و سرویس کاربران دارد. روز بعد شاید نیاز به سرویس ارسال ایمیل به آنها را هم پیدا کند. در این حالت طراحی این کنترلر باید تغییر کند و این تغییر ناقض اصلی نیست. صرفا برآورده کردن نیاز کاری است. حتی این تغییر هم ناقض Open Closed Principle نیست؛ چون باز است جهت تعویض پیاده سازی سرویس ایمیل و بستهاست جهت تغییرات آتی، از این جهت که اطلاعی از جزئیات پیاده سازی اینترفیس و سرویس ایمیل ندارد.
- این مثال صرفا جهت حل مسالهی ASP.NET Identity ارائه شد و استفادهی از یک اینترفیس برای تمام کارها. اگر قرار بود من آنرا طراحی کنم، برای ارسال ایمیل یک اینترفیس و برای ارسال SMS یک اینترفیس دیگر ایجاد میکردم. یک طراحی خوب باید دارای حداقل ابهام باشد.
نظرات مطالب
کمپین ضد IF !
من شباهتی بین مطلب این مقاله و Dependency Injection نمی بینم.
مطلب بالا دقیقا پیاده سازی الگوی طراحی Strategy هست. جایی که رفتارها (عملیات محاسبه Aggregate) از رفتار کننده (محاسبه گر، ماشین حساب) جدا شده و در کلاسهای خودشان که یک اینترفیس مشترک را پیاده سازی می کنند، تعریف می شوند.
مطلب بالا دقیقا پیاده سازی الگوی طراحی Strategy هست. جایی که رفتارها (عملیات محاسبه Aggregate) از رفتار کننده (محاسبه گر، ماشین حساب) جدا شده و در کلاسهای خودشان که یک اینترفیس مشترک را پیاده سازی می کنند، تعریف می شوند.
وبلاگها و سایتهای ایرانی
Visual Studio
امنیت
- رمزنگاری کوانتمی و شبکهای رمزنگاری شده با این روش
ASP. Net
طراحی وب
اسکیوال سرور
به روز رسانیها
ابزارها
- نگارش جدید برنامه RSS Bandit . (برنامهای سورس باز نوشته شده با سی شارپ)
- Visual Round Trip Analyzer (استفاده از NetMon API)
سیشارپ
- Interactive GUI Shell از توسعه دهندگان تیم Mono
عمومی دات نت
- آشنایی با کلاس CommaDelimitedStringCollection در دات نت فریم ورک
- مونو و دات نت گزارشی از PDC2008
CPP
دلفی
- CompilerPlugin برای دلفی 2009. (توسط آن میتوان پروژههای دلفی 2007 را با دلفی 2009 نیز کامپایل کرد)
- نسخه جدید CnPack منتشر شد. (با پشتیبانی دلفی 5 تا 2009)
ویندوز
- آنالیز crash dumps ویندوز . (آیا میدانید صفحات آبی ویندوز را چگونه باید تفسیر کرد؟)
Office
- آشنایی با یک سری از اصطلاحات outlook 2007 برای برنامه نویسها. (اگر قصد داشته باشید یک add-in را برای outlook 2007 با استفاده از امکانات VSTO توسعه دهید، آشنایی با این اصطلاحات بسیار ضروری خواهد بود)
متفرقه
مطالب دورهها
بایدها و نبایدهای استفاده از IoC Containers
طوری با IoC Containers کار کنید که انگار وجود خارجی ندارند
تفاوت پایهای که بین یک فریم ورک IoC و سایر فریم ورکها وجود دارد، در معکوس شدن مسئولیتها است. در اینجا لایههای مختلف برنامه شما نیستند که فریم ورک IoC را فراخوانی میکنند؛ بلکه این فریم ورک IoC است که از جزئیات ارتباطات و وابستگیهای سیستم شما آگاه است و نهایتا کار کنترل وهله سازی اشیاء مختلف را عهده دار خواهد شد. طول عمر آنها را تنظیم کرده یا حتی در بعضی از موارد مانند برنامه نویسی جنبهگرا یا AOP، نسبت به تزئین این اشیاء یا دخالت در مراحل مختلف فراخوانی متدهای آنها نیز نقش خواهد داشت. نکتهی مهم در اینجا، نا آگاهی برنامه از حضور آنها است.
بنابراین در پروژه شما اگر ماژولها و لایههای مختلفی حضور دارند، تنها برنامه اصلی است که باید ارجاعی را به فریم ورک IoC داشته باشد و نه سایر لایههای سیستم. علت حضور آن در ریشه سیستم نیز تنها باید به اصطلاحا bootstrapping و اعمال تنظیمات مرتبط با آن خلاصه شود.
به عبارتی استفاده صحیح از یک فریم ورک IoC نباید به شکل الگوی Service Locator باشد؛ حالتی که در تمام قسمتهای برنامه مدام مشاهده میکنید resolver.Resolve، resolver.Resolve و الی آخر. باید از این نوع استفاده از فریم ورکهای IoC تا حد ممکن حذر شود و کدهای برنامه نباید وابستگی مستقیم ثانویهای را به نام خود فریم ورک IoC پیدا کنند.
نمونهای از نحوه صحیح استفاده از یک IoC Container را مشاهده میکنید. تنها در سه نقطه است که یک IoC container باید حضور پیدا کند:
الف) در آغاز برنامه برای اعمال تنظیمات اولیه و bootstrapping
ب) پیش از اجرای عملی جهت وهله سازی وابستگیهای مورد نیاز
ج) پس از اجرای عمل مورد نظر جهت آزاد سازی منابع
نکته مهم اینجا است که در حین اجرای فرآیند، این فرآیند باید تا حد ممکن از حضور IoC container بیخبر باشد و کار تشکیل اشیاء باید خارج از منطق تجاری برنامه انجام شود: IoC container خود را صدا نزنید؛ او شما را صدا خواهد زد.
عنوان شد تا «حد ممکن». این تا حد ممکن به چه معنایی است؟ اگر کار وهله سازی اشیاء را میتوانید تحت کنترل قرار دهید، مثلا آیا میتوانید در نحوه وهله سازی کنترلرها در ASP.NET MVC دخل و تصرف کرده و در زمان وهله سازی، اینکار را به یک IoC Container واگذار کنید؟ اگر بلی، دیگر به هیچ عنوانی نباید داخل کلاسهای فراخوانی شده و تزریق شده به کنترلرهای برنامه اثری از IoC Container شما مشاهده شود. زیرا این فریم ورکها اینقدر توانمند هستند که بتوانند تا چندین لایه از سیستم را واکاوی کرده و وابستگیهای لازم را وهله سازی کنند.
اگر خیر (نمیتوانید کار وهله سازی اشیاء را مستقیما تحت کنترل قرار دهید)؛ مانند تهیه یک Role Provider سفارشی در ASP.NET MVC که کار وهله سازی این Role Provider راسا توسط موتور ASP.NET انجام میشود و در این بین امکان دخل و تصرفی هم در آن ممکن نیست، آنگاه مجاز است داخل این کلاس ویژه از متدهای container.Resolve استفاده کرد؛ چون چارهی دیگری وجود ندارد و IoC Container نیست که کار وهله سازی ابتدایی آنرا عهده دار شده است. باید دقت داشت به این حالت خاص دیگر تزریق وابستگیها گفته نمیشود؛ بلکه نام الگوی آن Service locator است. در Service locator یک کامپوننت خودش به دنبال وابستگیهای مورد نیازش میگردد. در حالت تزریق وابستگیها، یک کامپوننت وابستگیهای مورد نیاز را درخواست میکند.
یک مثال:
کاری که در اینجا انجام شده است نمونه اشتباهی از استفاده از یک IoC Container میباشد. به صرف اینکه مشغول به استفاده از یک IoC Container هستیم به این معنا نیست که واقعا الگوی معکوس سازی وابستگیها را درست درک کردهایم. در اینجا الگوی Service locator مورد استفاده است و نه الگوی تزریق وابستگیها. به عبارتی در مثال فوق، کلاس ExampleClass وابسته است به یک وابستگی جدیدی به نام Container، علاوه بر وابستگی IService ایی که به او قرار است خدماتی را ارائه دهد.
نمونه اصلاح شده کلاس فوق، تزریق وابستگیها در سازنده کلاس به نحو زیر است:
در اینجا این کلاس است که وابستگیهای خود را درخواست میکند و نه اینکه خودش به دنبال آنها بگردد.
نمونه دیگری از کلاسی که خودش به دنبال یافتن و وهله سازی وابستگیهای مورد نیازش است مثال زیر میباشد:
به این کار poor man's dependency injection هم گفته میشود؛ اولین سازنده از طریق یک default constructor سعی کرده است وابستگیهای کلاس را، خودش تامین کند. باز هم کلاس میداند که به چه وابستگی خاصی نیاز دارد و عملا معکوس سازی وابستگیها رخ نداده است. همچنین استفاده از این حالت زمانیکه کلاس Dinner خودش وابستگی به کلاسهای دیگر داشته باشد، بسیار به هم ریخته و مشکل خواهد بود. مزیت استفاده از IoC Containers وهله سازی یک large object graph کامل است. به علاوه توسط IoC Containers مدیریت طول عمر اشیاء را نیز میتوان تحت نظر قرار داد. برای مثال میتوان به یک IoC Container گفت تنها یک وهله از DbContext را در طول یک درخواست ایجاد و آنرا در اختیار لایههای مختلف برنامه قرار بده؛ چون نیاز داریم کاری که در طی یک درخواست انجام میشود، در داخل یک تراکنش انجام شده و همچنین بیجهت به ازای هر new DbConetxt جدید، یکبار اتصالی به بانک اطلاعاتی باز و بسته نشود (سرعت بیشتر، سربار کمتر).
تفاوت پایهای که بین یک فریم ورک IoC و سایر فریم ورکها وجود دارد، در معکوس شدن مسئولیتها است. در اینجا لایههای مختلف برنامه شما نیستند که فریم ورک IoC را فراخوانی میکنند؛ بلکه این فریم ورک IoC است که از جزئیات ارتباطات و وابستگیهای سیستم شما آگاه است و نهایتا کار کنترل وهله سازی اشیاء مختلف را عهده دار خواهد شد. طول عمر آنها را تنظیم کرده یا حتی در بعضی از موارد مانند برنامه نویسی جنبهگرا یا AOP، نسبت به تزئین این اشیاء یا دخالت در مراحل مختلف فراخوانی متدهای آنها نیز نقش خواهد داشت. نکتهی مهم در اینجا، نا آگاهی برنامه از حضور آنها است.
بنابراین در پروژه شما اگر ماژولها و لایههای مختلفی حضور دارند، تنها برنامه اصلی است که باید ارجاعی را به فریم ورک IoC داشته باشد و نه سایر لایههای سیستم. علت حضور آن در ریشه سیستم نیز تنها باید به اصطلاحا bootstrapping و اعمال تنظیمات مرتبط با آن خلاصه شود.
به عبارتی استفاده صحیح از یک فریم ورک IoC نباید به شکل الگوی Service Locator باشد؛ حالتی که در تمام قسمتهای برنامه مدام مشاهده میکنید resolver.Resolve، resolver.Resolve و الی آخر. باید از این نوع استفاده از فریم ورکهای IoC تا حد ممکن حذر شود و کدهای برنامه نباید وابستگی مستقیم ثانویهای را به نام خود فریم ورک IoC پیدا کنند.
var container = BootstrapContainer(); var finder = container.Resolve<IDuplicateFinder>(); var processor = container.Resolve<IArgumentsParser>(); Execute( args, processor, finder ); container.Dispose();
الف) در آغاز برنامه برای اعمال تنظیمات اولیه و bootstrapping
ب) پیش از اجرای عملی جهت وهله سازی وابستگیهای مورد نیاز
ج) پس از اجرای عمل مورد نظر جهت آزاد سازی منابع
نکته مهم اینجا است که در حین اجرای فرآیند، این فرآیند باید تا حد ممکن از حضور IoC container بیخبر باشد و کار تشکیل اشیاء باید خارج از منطق تجاری برنامه انجام شود: IoC container خود را صدا نزنید؛ او شما را صدا خواهد زد.
عنوان شد تا «حد ممکن». این تا حد ممکن به چه معنایی است؟ اگر کار وهله سازی اشیاء را میتوانید تحت کنترل قرار دهید، مثلا آیا میتوانید در نحوه وهله سازی کنترلرها در ASP.NET MVC دخل و تصرف کرده و در زمان وهله سازی، اینکار را به یک IoC Container واگذار کنید؟ اگر بلی، دیگر به هیچ عنوانی نباید داخل کلاسهای فراخوانی شده و تزریق شده به کنترلرهای برنامه اثری از IoC Container شما مشاهده شود. زیرا این فریم ورکها اینقدر توانمند هستند که بتوانند تا چندین لایه از سیستم را واکاوی کرده و وابستگیهای لازم را وهله سازی کنند.
اگر خیر (نمیتوانید کار وهله سازی اشیاء را مستقیما تحت کنترل قرار دهید)؛ مانند تهیه یک Role Provider سفارشی در ASP.NET MVC که کار وهله سازی این Role Provider راسا توسط موتور ASP.NET انجام میشود و در این بین امکان دخل و تصرفی هم در آن ممکن نیست، آنگاه مجاز است داخل این کلاس ویژه از متدهای container.Resolve استفاده کرد؛ چون چارهی دیگری وجود ندارد و IoC Container نیست که کار وهله سازی ابتدایی آنرا عهده دار شده است. باید دقت داشت به این حالت خاص دیگر تزریق وابستگیها گفته نمیشود؛ بلکه نام الگوی آن Service locator است. در Service locator یک کامپوننت خودش به دنبال وابستگیهای مورد نیازش میگردد. در حالت تزریق وابستگیها، یک کامپوننت وابستگیهای مورد نیاز را درخواست میکند.
یک مثال:
public class ExampleClass { private readonly IService _service; public ExampleClass() { _service = Container.Resolve<IService>(); } public void DoSomething(int id) { _service.DoSomething(id); } }
نمونه اصلاح شده کلاس فوق، تزریق وابستگیها در سازنده کلاس به نحو زیر است:
public class ExampleClass { private IService _service; public ExampleClass(IService service) { _service = service; } public void DoSomething(int id) { _service.DoSomething(id); } }
نمونه دیگری از کلاسی که خودش به دنبال یافتن و وهله سازی وابستگیهای مورد نیازش است مثال زیر میباشد:
public class Search { IDinner _dinner; public Search(): this(new Dinner()) { } public Search(IDinner dinner) { _dinner = dinner; } }
مطالب دورهها
Lazy loading در تزریق وابستگیها به کمک StructureMap
پیشنیاز این بحث، مطلب «استفاده از StructureMap به عنوان یک IoC Container» میباشد که پیشتر در این سری مطالعه کردید (در حد نحوه نصب StructureMap و آشنایی با تنظیمات اولیه آن)
ابتدا ساختار بحث جاری را به نحو زیر درنظر بگیرید:
در اینجا کار مدیریت سفارشات در کلاس OrderHandler انجام میشود. این کلاس دارای دو وابستگی تزریق شده در سازنده کلاس میباشد.
در متد Handle، اگر مجوز کار توسط متد ShippingAllowed صادر شد، آنگاه کار نهایی توسط متد CreateInvoice باید صورت گیرد. با توجه به اینکه تزریق وابستگیها در سازنده کلاس صورت میگیرد، نیاز است پیش از وهله سازی کلاس OrderHandler، هر دو وابستگی آن وهله سازی و تزریق شوند. در حالیکه در مثال جاری هیچگاه به وهلهای از نوع IAccounting نیاز نخواهد شد؛ زیرا متد ShippingAllowed در این مثال، فقط false بر میگرداند.
و از این نمونهها زیاد هستند. کلاسهایی با تعداد متدهای بالا و تعداد وابستگیهای قابل توجه که ممکن است در طول عمر شیء وهله سازی شده این کلاس، تنها به یکی از این وابستگیها نیاز شود و نه به تمام آنها.
راه حلی برای این مساله در دات نت 4 با معرفی کلاس Lazy ارائه شده است؛ به این نحو که اگر برای مثال در اینجا accounting را Lazy تعریف کنیم، تنها زمانی وهله سازی خواهد شد که به آن نیاز باشد و نه پیش از آن.
سؤال: Lazy loading تزریق وابستگیها را چگونه میتوان توسط StructureMap فعال ساخت؟
ابتدا تعاریف کلاس OrderHandlerرا به نحو زیر بازنویسی میکنیم:
در اینجا سازندههای کلاس، به صورت Lazy معرفی شدهاند. دسترسی به فیلدهای sales و accounting نیز اندکی تغییر کردهاند و اینبار از طریق خاصیت Value آنها باید انجام شود.
مرحله نهایی هم اندکی تغییر در نحوه معرفی تنظیمات اولیه StructureMap است:
به این ترتیب زمانیکه برنامه به sales.Value میرسد آنگاه نیاز به وهله سازی شیء متناظر با آنرا خواهد داشت که در اینجا از طریق متد GetInstance به آن ارسال خواهد گردید.
خروجی برنامه در این حالت:
همانطور که مشاهده میکنید، هرچند کلاس OrderHandlerLazy دارای دو وابستگی تعریف شده در سازنده کلاس است، اما تنها وابستگی Sales آن زمانیکه به آن نیاز شده، وهله سازی گردیده است و خبری از وهله سازی کلاس Accounting نیست (چون مطابق تعاریف کلاسهای برنامه هیچگاه به مسیر accounting.Value نخواهیم رسید؛ بنابراین نیازی هم به وهله سازی آن نخواهد بود).
دریافت مثال این قسمت
DI04.zip
ابتدا ساختار بحث جاری را به نحو زیر درنظر بگیرید:
namespace DI04.Services { public interface IAccounting { void CreateInvoice(int orderId, int count); } } namespace DI04.Services { public interface ISales { bool ShippingAllowed(int orderId); } } namespace DI04.Services { public interface IOrderHandler { void Handle(int orderId, int count); } } using System; namespace DI04.Services { public class Accounting : IAccounting { public Accounting() { Console.WriteLine("Accounting ctor."); } public void CreateInvoice(int orderId, int count) { // ... } } } using System; namespace DI04.Services { public class Sales : ISales { public Sales() { Console.WriteLine("Sales ctor."); } public bool ShippingAllowed(int orderId) { // فقط جهت آزمایش سیستم return false; } } } using System; namespace DI04.Services { public class OrderHandler : IOrderHandler { private readonly IAccounting _accounting; private readonly ISales _sales; public OrderHandler(IAccounting accounting, ISales sales) { Console.WriteLine("OrderHandler ctor."); _accounting = accounting; _sales = sales; } public void Handle(int orderId, int count) { if (_sales.ShippingAllowed(orderId)) { _accounting.CreateInvoice(orderId, count); } } } }
در متد Handle، اگر مجوز کار توسط متد ShippingAllowed صادر شد، آنگاه کار نهایی توسط متد CreateInvoice باید صورت گیرد. با توجه به اینکه تزریق وابستگیها در سازنده کلاس صورت میگیرد، نیاز است پیش از وهله سازی کلاس OrderHandler، هر دو وابستگی آن وهله سازی و تزریق شوند. در حالیکه در مثال جاری هیچگاه به وهلهای از نوع IAccounting نیاز نخواهد شد؛ زیرا متد ShippingAllowed در این مثال، فقط false بر میگرداند.
و از این نمونهها زیاد هستند. کلاسهایی با تعداد متدهای بالا و تعداد وابستگیهای قابل توجه که ممکن است در طول عمر شیء وهله سازی شده این کلاس، تنها به یکی از این وابستگیها نیاز شود و نه به تمام آنها.
راه حلی برای این مساله در دات نت 4 با معرفی کلاس Lazy ارائه شده است؛ به این نحو که اگر برای مثال در اینجا accounting را Lazy تعریف کنیم، تنها زمانی وهله سازی خواهد شد که به آن نیاز باشد و نه پیش از آن.
private readonly Lazy<IAccounting> _accounting;
سؤال: Lazy loading تزریق وابستگیها را چگونه میتوان توسط StructureMap فعال ساخت؟
ابتدا تعاریف کلاس OrderHandlerرا به نحو زیر بازنویسی میکنیم:
using System; namespace DI04.Services { public class OrderHandlerLazy : IOrderHandler { private readonly Lazy<IAccounting> _accounting; private readonly Lazy<ISales> _sales; public OrderHandlerLazy(Lazy<IAccounting> accounting, Lazy<ISales> sales) { Console.WriteLine("OrderHandlerLazy ctor."); _accounting = accounting; _sales = sales; } public void Handle(int orderId, int count) { if (_sales.Value.ShippingAllowed(orderId)) { _accounting.Value.CreateInvoice(orderId, count); } } } }
مرحله نهایی هم اندکی تغییر در نحوه معرفی تنظیمات اولیه StructureMap است:
using System; using DI04.Services; using StructureMap; namespace DI04 { class Program { static void Main(string[] args) { // تنظیمات اولیه برنامه که فقط یکبار باید در طول عمر برنامه انجام شود ObjectFactory.Initialize(x => { x.For<IOrderHandler>().Use<OrderHandlerLazy>(); // Lazy loading x.For<Lazy<IAccounting>>().Use(c => new Lazy<IAccounting>(c.GetInstance<Accounting>)); x.For<Lazy<ISales>>().Use(c => new Lazy<ISales>(c.GetInstance<Sales>)); }); var orderHandler = ObjectFactory.GetInstance<IOrderHandler>(); orderHandler.Handle(orderId: 1, count: 10); } } }
خروجی برنامه در این حالت:
OrderHandlerLazy ctor. Sales ctor.
دریافت مثال این قسمت
DI04.zip
در این دوره به مفاهیمی مانند معکوس سازی وابستگیها و تزریق وابستگیها پرداخته خواهد شد. بسیاری از برنامه نویسها مفاهیم DIP، IoC و DI را با هم مخلوط کرده و بجای هم بکار میبرند. بنابراین قصد داریم هر یک را به تفصیل بررسی کرده و تفاوتهای آنها را برشماریم. سپس سعی خواهیم کرد تا یک کتابخانه تزریق وابستگیهای ابتدایی را ایجاد کرده و نهایتا نحوه استفاده از چندین فریم ورک IOC موجود بررسی خواهند شد. این سری پیشنیاز درک مفاهیمی است که در لایه بندی اجزای مختلف برنامهها مورد نیاز میباشند.