‫۱ سال و ۷ ماه قبل، یکشنبه ۲۵ دی ۱۴۰۱، ساعت ۱۶:۱۸
موضوع هزینه Resolve کردن اینترفیس‌ها نیست. هر بار یک کلاس را درخواست میکنیم، علاوه بر سازنده(Constructor) خود کلاس اصلی، سازنده همه کلاس‌های وابسته  نیز فراخوانی میشوند(از همه آنها instance ایجاد میشود در حافظه) در نتیجه مثلا برای فراخوانی یک متد ساده ممکنه است دهها وهله(instance) از کلاس‌های مختلف ایجاد شود بدون اینکه نیازی به آنها داشته باشیم.
موضوع اینکه در تعریف و رجیستر کردن وابستگی‌های یک کلاس سعی کنیم با سختگیری یک کلاس را با حداقل وابستگی‌ها تزریق کنیم. 
‫۱ سال و ۷ ماه قبل، شنبه ۲۴ دی ۱۴۰۱، ساعت ۱۲:۲۹
جالب و مفید بود. فقط یک نکته ای که باید مدنظر داشت معمولا برخلاف اون چیزی که بنظر میاد هر تزریق وابستگی یک بار اضافی موقع ایجاد یک اسکوپ(scope) جدید با خودش به همراه داره. معمولا وقتی تعداد سرویس‌ها کمه و اپلیکیشن ما پیچیدگی چندانی نداره از این بار اضافی صرف نظر میکنیم اما با افزایش تعداد سرویس‌ها و کانتکست ها(dbcontext) و بزرگ شدن پروژه اثرات تزریق‌های وابستگی زیاد و داینامیک خودش رو کم کم نشون میده. مگه اینکه این وابستگی‌ها هوشمندانه و بصورت حداقلی به ازای هر scope ایجاد شود.
به جز وب، این مشکل در چت بات‌ها هم مرسوم است. یادمه یک بات برای پروموشن و دریافت تخفیف یک شرکت ایرانی نوشته بودیم. اما چون race condition رو توش درست هندل نکرده بودیم، بعضی از تینیجرها یک روشی رو یاد گرفته بودند که اینترنت گوشی شون رو قطع میکردند، ده‌ها بار روی دکمه دریافت تخفیف (inline button) کلیک میکردند، بعد اینترنت رو که وصل میکردند، تلگرام همه درخواست‌ها رو یکجا (در کسری از ثانیه) میفرستاد به webhook ما و ممکن بود چندتا کد تخفیف، برای کاربر ارسال بشه.
‫۵ سال و ۸ ماه قبل، دوشنبه ۲۴ دی ۱۳۹۷، ساعت ۲۰:۱۵
لطفا در صورت امکان توضیح دهید در معماری توزیع شده چرا از کافکا برای Message broker استفاده کردید؟ و مثلا چرا RabbitMq رو انتخاب نکردید؟ با توجه به اینکه مرسوم است که میگویند در سیستم هایی که سرعت ارسال پیام و Real time بودن برای شما اهمیت داشته باشد rabbit انتخاب بهتری است.
‫۷ سال و ۵ ماه قبل، شنبه ۲ اردیبهشت ۱۳۹۶، ساعت ۱۴:۳۷
البته یک مشکل اساسی در این روش که وجود دارد و آن امنیت پایین در استفاده از Entity‌های ماژول‌های مختلف است.
در پروژه‌های بزرگ و ERP هر ماژول باید به یکسری Entityهای مشخصی دسترسی و ارتباط داشته باشد و نباید بصورت نامحدود با هر Entity از هر ماژولی join بزند.
در این روش تقریبا همه Entityها در یک سطح قرار دارند و کپسوله سازی وجود ندارد.
‫۹ سال و ۱۱ ماه قبل، سه‌شنبه ۶ آبان ۱۳۹۳، ساعت ۱۸:۱۱
ممنون بابت نظراتتان.
عرض کردم  مطلب را کامل بخوانید.این مشکل در سیستم هایی با پردازش بالا و در زمان‌های هزارم ثانیه رخ میدهد.به این معنی که کلاس Random مقادیر متفاوتی ایجاد نمیکند.و عملا کارایی ندارد.
‫۹ سال و ۱۱ ماه قبل، دوشنبه ۲۸ مهر ۱۳۹۳، ساعت ۱۷:۴۷
بله استفاده از روش مطروحه شما استاندارد و اصولی‌تر میباشد.
راهکار من سر راست‌تر و سریع‌تر میباشد و برای افراد مبتدی کاربرد بیشتری دارد به اضافه اینکه خیلی از اوقات اسمبلی‌های خارجی در پروژه مدام دستخوش تغییر مسیر،تغییر نام و یا حتی ممکن است بکلی از پروژه کنار گذاشته شوند.