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

نیازی نیست به ازای هر تبلیغ یک جاب درست کنید. کلا یک جاب درست کنید که مثلا هر 5 دقیقه یکبار از دیتابیس کوئری بگیره. مواردی رو که منقضی شده (مقایسه تاریخ سرور با تاریخ فیلد انقضاء تبلیغ) پیدا کنه و براشون ایمیل ارسال کنه. به این صورت سربار خیلی خیلی کمی خواهید داشت.

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

ممنون از شما. یک روش برای اینکه مستقیما با XML Reader کار نکنیم می‌تونه استفاده از روش‌های سریالایز کردن کلاس‌ها باشه. دردسرش کمتره.

یک سؤال: این فلش‌های انحنا دار رو با چه برنامه‌ای ایجاد کردید؟

‫۱۱ سال و ۲ ماه قبل، یکشنبه ۱۳ مرداد ۱۳۹۲، ساعت ۱۲:۵۰
کد سمت سرور db.vProjects.ToDataSourceResult چطور تهیه شده؟ در موردش اینجا بحث شده . شما یک IQueryable باید در اختیارش قرار بدی (که از لحاظ لایه بندی کار مشکل داره) تا بر اساس اطلاعات شماره صفحه و غیره‌ای که از کلاینت می‌رسه خودش مباحث Take و Skip رو پیاده سازی کنه. در حقیقت این کتابخانه فقط یک متد الحاقی اضافه‌تر برای اینکار جهت مدیریت مباحث سمت سرور داره.
‫۱۱ سال و ۲ ماه قبل، یکشنبه ۱۳ مرداد ۱۳۹۲، ساعت ۰۵:۰۱
می‌تونی یک مثال با پروفایل SQL نهایی آن ارائه بدی. مطابق بررسی که کردم و حداقل دو تا لینکی که دادم در مورد این کتابخانه، موارد پردازش Take و Skip سمت سرور اون خودکار نیست.
‫۱۱ سال و ۲ ماه قبل، یکشنبه ۱۳ مرداد ۱۳۹۲، ساعت ۰۲:۵۷
بله. مدیریت می‌کنه، نه به تنهایی. اینجا هم باید اطلاعات Skip و Take رو بهش بدی تا صفحه بندی کم هزینه‌ای رو اعمال کنه. خود GridView در وب فرم‌ها هم paging داره. مشکلش اینه که در حالت پیش فرض کل اطلاعات رو از سرور واکشی می‌کنه و بعد یک صفحه رو نمایش می‌ده. بحث اینه که گرید اگر قراره یک صفحه رو نمایش بده که 20 ردیف داره، بتونه فقط 20 رکورد رو واکشی کنه و نه کل اطلاعات رو و این نیاز به کوئری‌های خاصی در سمت سرور داره. یک نمونه‌اش رو در واکشی اطلاعات به صورت تکه تکه لینک دادم.