طول عمر Container ایی که تعاریف اولیه را دارد باید به صورت singleton تعریف شود. اگر قرار باشد هر جایی مجزا وهله سازی شود، Containerهای متفاوتی خواهید داشت با اشیاء متفاوتی. یک مثال در این مورد: DI06.zip
Entity Framework Core for Beginners - 5 part video series with full source code, notes, code tours, and a dev container.
Windows Server 2022 brings innovations and improvements in Windows Server container platform, application compatibility and containerization tooling.
- مبحثی که در اینجا مطرح شده، مرتبط با حالت‌های عدم استفاده‌ی از سیستم تزریق وابستگی‌ها است. البته می‌توان این نوع Containerها را در حالت «service locator»، در همه‌جا استفاده کرد و محدودیتی هم ندارند.
- اگر از یک سیستم تزریق وابستگی‌ها استفاده می‌کنید، مطلب جاری را فراموش کنید. یک کلاس معمولی را ایجاد کرده و یک اینترفیس را از آن استخراج کنید (مانند همیشه و بسیار عادی). سپس این اینترفیس و کلاس پیاده سازی کننده‌ی آن‌را با «طول عمر» singleton به این IoC Container معرفی کنید (مهم نیست نام آن IoC Container چیست. این روش همه جا کار می‌کند). اکنون چون مدیریت طول عمر این سرویس توسط IoC container مورد استفاده کنترل می‌شود، می‌توانید در سازنده‌ی آن تمام سرویس‌های دیگر را هم تزریق کرده (مانند تمام سرویس‌های دیگر تعریف شده) و استفاده کنید؛ چون وهله سازی و مدیریت طول عمر آن توسط خود Container مدیریت می‌شود.
- اگر از یک سیستم تزریق وابستگی‌ها استفاده می‌کنید، مطلب جاری را فراموش کنید. یک کلاس معمولی را ایجاد کرده و یک اینترفیس را از آن استخراج کنید (مانند همیشه و بسیار عادی). سپس این اینترفیس و کلاس پیاده سازی کننده‌ی آن‌را با «طول عمر» singleton به این IoC Container معرفی کنید (مهم نیست نام آن IoC Container چیست. این روش همه جا کار می‌کند). اکنون چون مدیریت طول عمر این سرویس توسط IoC container مورد استفاده کنترل می‌شود، می‌توانید در سازنده‌ی آن تمام سرویس‌های دیگر را هم تزریق کرده (مانند تمام سرویس‌های دیگر تعریف شده) و استفاده کنید؛ چون وهله سازی و مدیریت طول عمر آن توسط خود Container مدیریت می‌شود.
- استفاده و یا تعریف متدهای Async در اینجا هیچ تفاوتی با قبل ندارد. همان امضای متدهای Task دار و در صورت نیاز async دار را ارائه دهید.
یک نکته: تزریق وابستگی‌ها در سازنده‌ی کلاس‌هایی با طول عمر singleton یکسری نکات خاص خودشان را دارند.
درحال R&D در راستای حذف وابستگی به StructureMap برای تزریق وابستگی‌ها با طول عمر Tenant-Singleton، هستم. این وابستگی به دلیل کمبودهای IoC Container توکار، ایجاد شده است.
- برای طراحی افزونه پذیر از ExtCore استفاده کنید.
- «کتابخانه‌های کمکی جهت ساده سازی ثبت تنظیمات اولیه‌ی IoC Container توکار NET Core.» هم که نامبرده شدند، همین کار اسکن و اتصال را انجام می‌دهند.
امکانی که در قسمت "نیاز به تعویض IoC Container توکار ASP.NET Core " در همین مقاله فرمودین رو چه کار کنیم؟ :
• امکان اسکن اسمبلی‌های مختلف جهت یافتن اینترفیس‌ها و اتصال خودکار آن‌ها (طراحی‌های افزونه پذیر)
یک نکته‌ی تکمیلی: ترکیب ngIf و ngFor بر روی یک المان
فرض کنید می‌خواهید در همان حالیکه عنصری را در طی یک حلقه نمایش می‌دهید، از همان آیتم جاری برای تشخیص یکی از خاصیت‌های آن نیز استفاده کنید:
یک چنین ترکیبی در Angular مجاز نیست و راه حل پیشنهاد شده‌ی آن استفاده از ng-container است:
مزیت مهم آن عدم درج ng-container در DOM است. برای مثال قصد نداریم یک div اضافی را داخل تعاریف یک جدول قرار دهیم و آن‌را از شکل استاندارد خارج کنیم.
فرض کنید می‌خواهید در همان حالیکه عنصری را در طی یک حلقه نمایش می‌دهید، از همان آیتم جاری برای تشخیص یکی از خاصیت‌های آن نیز استفاده کنید:
<td *ngFor="let item of headerItems" *ngIf="item.visible">{{ item?.name }}</td> <ng-container *ngFor="let item of headerItems">
<td *ngIf="item.visible">{{ item?.name }}</td>
</ng-container> 
مطلب شما را مطالعه کردم. تنها ایرادی که می‌توان اشاره کرد Implement کردن دستی تک تک سرویسها در Windsor Container می‌باشد. آیا راه حلی برای این موضوع هست ؟ (مطمئنا در پروژه هایی با تعداد سرویس و کنترل زیاد مشکل ایجاد می‌کند)
چنانچه بخواهیم از BoundedContext استفاده کنیم، نحوه استفاده از الگوی واحد کار به چه صورت است؟ فرضا چنانچه SaleDbContext, ShippmentDbContext داشته باشیم که هر دو از IUnitOfWork به ارث رفته اند و در یک سرویس بخواهیم عملیاتی را در هر دو Context و طی یک transaction انجام دهیم، Ioc container هنگام وهله سازی IUnitOfWork، چه کلاسی را بایستی new کند؟