سلام مجدد خدمت دوستان عزیز

با چند تا جستجو تو گوگل و بررسی یه مقاله تونستم اون چیزی که میخوام رو بسازم و  سفارشی سازی  سازیش کنم:

روال کار به این صورته که به جای درخواست N  بار به دیتابیس حداقل یه بار pool چک میشه و یه بار با مقدار پر میشه و در دفعات بعد تا زمانی که pool خالی نباشه مقدار بر میگردونه(هر بار که مقداری رو بر گردونه اون مقدار رو از pool کم میکنه)

تکنولوژی که من سفارشیش کردم:

public static class _CacheUrl
    {
        private static Dictionary<int, tbUrl> _cach;
        private static object _lck;
        private static DataContext context = new DataContext();

        static _CacheUrl()
        {
            _cach = new Dictionary<int, tbUrl>();
            _lck = new object();
        }

        public  static tbUrl Read
        {
            get
            {
                lock (_lck)
                {

                    if (_cach.Count == 0)
                    {
                        List<tbUrl> tbUrl = context.tbUrls.Where(r => r.IsCompleted == false).ToList();
                        foreach (var c in tbUrl)
                            _cach.Add(c.Id, c);

                        return _cach.FirstOrDefault().Value;
                    }
                    else
                        return _cach.FirstOrDefault().Value;
                }
            }
        }

        public static void Update(int Id)
        {
            _cach.Remove(Id);
        }
    }

اینم لینک منبع:

https://dzone.com/articles/memory-cache-implementation-c

در مواردی که فیلد جدیدی بروز یا اضاف میشه ، ساختار signalr بسیار عالی عمل میکنه و بدون چک کردن ، خودش رو (فیلد) به برنامه جهت نمایش معرفی میکنه ! خب خیلی خوبه اما

من به دلایل زیر signalr رو توصیه نمیکنم (فقط در صورتی که حداقل دلایل زیر صدق پیدا کنه ولا غیر)

_ در مواقعی که رکوردهایی  از قبل درج شده باشه ! اینجا هدف نهایی انعکاس به سمت اپلیکیشن نیس ! پس نیاز به چک کردن رکوردها هست که ارتباط چندانی با signalr نداره و اینجا بحث round trip  و کاهش io به وجود میاد و خوبه که به جای ارتباطات مکرر با پایگاه داده که باعث کندی برنامه میشه و ترافیک بیخودی ایجاد میکنه تنها با یک بار واکشی رکوردهای مورد نظر ، از رم و الگوهای طراحی بهره گرفت.

_ متاسفانه زیاد با ساختار signalr آشنا نیستم اما بعید نمیدونم که تنها یک بار آگاه سازی انجام میشه و در صورتی که timeout یا خطایی به وجود بیاد رکوردهایی ناکام میمونن .(چون ربات تنها به ازای رکورهایی که فرستنده دیتابیس  یک بار اونها رو ارسال میکنه کار میکنه و اگه به دلیلی از وجود رکورها بی خبر بشه پس قادر به پردازش نیس پس اینجا با عدم صحت عملکرد  مواجه ایم )

_همیشه امکان ارسال n دیتا به سمت اپلیکیشن وجود داره پس HANDLE کردن داده ها که Signalr دریافت میکنه خودش یه چالشه و حتی ممکنه با راه اندازی مجدد سرور همه چی (داده ها )از دست بره