‫۱۱ سال و ۶ ماه قبل، دوشنبه ۲۶ فروردین ۱۳۹۲، ساعت ۱۶:۲۶

سلام و درود بر شما آقای نصیری

من چون توی دات نت تازه کار هستم دوتا سئوال خدمتتون دارم:

من توی برنامه ای که دارم می‌نویسم از الگوی UnitOfWork مطابق با آموزش‌های شما استفاده کردم درضمن برای تزریق وابستگی هم از StructerMap استفاده می‌کنم، برنامه Win Form هستش وتوی Main یک کلاس Configuration رو که کارش Registerکردن کلیهInterface وکلاس هاست رو فراخونی کردم.

اول اینکه : برای آزاد سازی منابع و استفاده بهینه از حافظه در حال استفاده از StructerMap  شما چه پیشنهاد یا روشی رو معرفی می‌کنین؟

دوم اینکه : با ازدیاد و تعدد کلاسها واینترفیس‌ها در حالیکه در ابتدای برنامه کلیه اونها رو با StructerMap   رجیستر می‌کنیم  ودر هرجا که لازم باشه فقط از اونها یک نمونه میسازیم،  اشکالی در روند عملیاتی وکاربری با اون نرم افزار پیش مشتری پیش نمی‌یاد؟ (مخصوصا در سیستم‌های یکپارچه و بزرگ از نظر حافظه).

سوم اینکه: آیا بایدها ونبایدهایی هم در استفاده از StructerMap وجود داره ؟

سپاسگزار شما هستم. 

‫۱۱ سال و ۶ ماه قبل، دوشنبه ۲۶ فروردین ۱۳۹۲، ساعت ۱۴:۲۲
لطفا متن قسمت جاری را یکبار دیگر مطالعه بفرمائید. جواب صریحی را دریافت خواهید کرد.
 (قسمت‌های وهله سازی خودکار وابستگی‌های کلاس‌های به هم وابسته (منظور از Object graph)؛ به علاوه امکان تعریف طول عمر یک شیء طوریکه هربار وهله سازی نشود (مثلا فقط در طول یک درخواست در تمام کلاس‌های وابسته به صورت یک وهله مشترک در دسترس باشد؛ مفید برای حالت استفاده از الگوی واحد کار). همچنین الگوی Service locator و فرق آن با تزریق وابستگی‌ها. مواردی که شاید یکی به نظر به رسند اما یکی نیستند)
‫۱۱ سال و ۶ ماه قبل، دوشنبه ۲۶ فروردین ۱۳۹۲، ساعت ۰۶:۰۳
در اصل کلاس BaseOperation یک کلاس Abstract هست که بقیه Operationها از این کلاس ارثی بری میکنند.
public abstract class BaseOperation : IPartikanOperation
و هیچ وهله سازی مستقیمی از آن در برنامه صورت نمیگرد.
public class UserOperations : BaseOperation, IUserOperations
    {
        private readonly IUserService _userService;        
        private readonly IMessageTemplateService _messageTemplateService;

        
        public UserOperations(IUserService userService, IMessageTemplateService messageTemplateService)
        {
            _userService = userService;
            _messageTemplateService = messageTemplateService;            
        }
راه حلی که من استفاده کردم ، استفاده از پارمتر ورودی برای کلاس‌های فرزند هست
 public UserOperations(IUnitOfWork uow,IUserService userService, IMessageTemplateService messageTemplateService) : base(uow)
        {
            _userService = userService;
            _messageTemplateService = messageTemplateService;            
        }
با توجه به اینکه هیچ وهله سازی از کلاس پایه صورت نمیگره ،آیا لزومی دارد که وابستگی به Container از کلاس پایه گرفته شود ؟
‫۱۱ سال و ۶ ماه قبل، دوشنبه ۲۶ فروردین ۱۳۹۲، ساعت ۰۵:۵۰
- این بهتر است. مدیریت طول عمر اشیاء (مثلا ایجاد یک وهله در طی یک درخواست) و همچنین وهله سازی object graph در چند سطح به صورت خودکار توسط Service Locator هم انجام می‌شود.
- ولی در کل اگر امکان وهله سازی کلاس BaseOperation توسط IoC Container به صورت مستقل وجود دارد (چیزی مثل استفاده از DefaultControllerFactory در ASP.NET MVC) بهتر است اجازه بدید خود IoC Container کار تزریق وابستگی‌ها را به صورت خودکار انجام دهد و کلاس‌ها اطلاعی از وجود آن نداشته باشند.
‫۱۱ سال و ۶ ماه قبل، دوشنبه ۲۶ فروردین ۱۳۹۲، ساعت ۰۵:۴۴
اگر ترکیبی از Service Locator و poor man's dependency injection استفاده شود چه ایراداتی دارد ؟
مثلاً این کد
protected readonly IUnitOfWork UnitOfWork;

        protected BaseOperation():this(ObjectFactory.GetInstance<IUnitOfWork>())
        {
            
        }
        protected BaseOperation(IUnitOfWork uow)
        {
            UnitOfWork = uow;
        }
به غیر از این که کلاس مورد نظر به Container وابسته هست آیا ایراد دیگری هم هست یا خیر ؟
‫۱۱ سال و ۶ ماه قبل، دوشنبه ۲۶ فروردین ۱۳۹۲، ساعت ۰۵:۳۶
به نظر شما از بین فریم ورک‌ها موجود کدام یک بهتره ؟ مخصوصاً مقایسه ای بین Ninject ، Unity و StructerMap اگر داشته باشیم خیلی بهتره 
‫۱۱ سال و ۶ ماه قبل، یکشنبه ۲۵ فروردین ۱۳۹۲، ساعت ۱۷:۴۵
این بحث با کیفیت مطلوب و دقت نظر خاصی مطرح شده است که البته از آقای نصیری هم جز این انتظار نمی‌ره.
ابتدا شرایط موجود بیان و بررسی می‌شود و برای بهبود آن راهکاری را مفید می‌بینیم و می‌پذیریم به نام اصل وارونگی وابستگی یا همان معکوس‌سازی وابستگی که در این بخش به آن پرداخته شده است.
موارد ۲ و ۳ و ۴ که به آن اشاره شده است در حقیقت روند طبیعی محقق شدن این اصل است که در بخش‌های بعدی به آن‌ها پرداخته خواهد شد. توجه به این روند سبب می‌شود این مفاهیم به جای هم به کار برده نشوند.
پس از قبول اصل یاد شده باید آن‌را پیاده سازی نمود. الگوی وارونگی کنترل برای پیاده سازی آن تدوین می‌گردد. برای اجرای این الگو نیاز به روشی پیدا می‌کنیم که وابستگی را به طور کامل بیرون شیء وابسته نگه داریم. پس چاره ای جز تزریق آن در زمانی که لازم است نداریم. بسیار خوب نام آن‌را روش تزریق وابستگی می‌گذاریم. در نهایت تزریق‌هایی که ممکن است پی در پی لازم شود را گردن کس دیگری می‌اندازیم که همان برنامه‌جانبی یا کتابخانه یا فریم‌ورک‌هایی هستند که به آن‌ها می‌گوییم چه وقت چی تزریق کنند. (آن‌ها در بردارنده اطلاعاتی هستند که مثلاً شیء ۱ برای انجام کار شیء ۲ باید به آن داده شود)
حال اگر تازه با این مفاهیم آشنا شده اید توصیه می‌کنم یک بار دیگر این بخش را مطالعه کنید و منتظر روند پیاده سازی این اصل در بخش‌های بعد باشید.

تشکر از مهندس نصیری برای اجرای این دوره آموزشی.
‫۱۱ سال و ۶ ماه قبل، یکشنبه ۲۵ فروردین ۱۳۹۲، ساعت ۱۴:۱۹
مثل همیشه عالی بود، واقعا جامعه برنامه نویسان به این مطالب زیاد نیاز دارند.
خیلی اوقات فکر می‌کنیم همین که از اینترفیس استفاد کنیم کار تمومه؛ غافل از اینکه این اینترفیس‌ها پایین‌تر از اون خطه!