این دوجمله رو

«- داده هایی که اخیرا به DbContext اضافه شده‌اند ولی هنوز در Database ذخیره نشده‌اند، درنظر گرفته نخواهند شد.
- داده هایی که در DbContext حذف شده‌اند ولی در Database  هستند، در نتیجه پرس و جو خواهند بود.»

میشه خلاصه‌اش کرد به «تا زمانیکه SaveChanges فراخوانی نشه، از اطلاعات تغییر کرده نمیشه کوئری گرفت (کوئری‌ها همیشه روی دیتابیس انجام می‌شن)؛ اما خاصیت Local این تغییرات محلی رو داره یا اینکه در change tracker میشه موارد EntityState.Added | EntityState.Modified | EntityState.Unchanged رو هم کوئری گرفت».

عنوان مطلب هست «به زبان ساده»، ولی اصل PI و Specification pattern و مانند اون در مقدمه مطلب بکار رفتن که کمی برای قسمت اول زیاده روی هست. ضمنا Refactoring اصلا به معنای بهبود و توسعه همزمان سیستم نیست. Refactoring بهبود کیفیت کدها هست بدون تغییری در ساختار کلی سیستم.

یعنی الان یک Context به ازای کل برنامه دارید که دچار این تداخل شدید؟ معمولا در WPF و همچنین WinForms این Context به ازای هر فرم تعریف می‌شود و با بسته شدن آن تخریب.

حالا یک سؤال مهم! به نظر شما در اولین سؤالی که پرسیدید، یک شخص چطور می‌بایستی ساختار کار شما رو که بر مبنای یک Context در کل برنامه است، حدس می‌زد و عیب یابی می‌کرد؟!

با تشکر از این نکته جدید.

به نظر من اگر فشرده سازی Response فعال باشه اصلا نیازی به حذف فواصل خالی در HTML نهایی نیست. چون حداقل کاری رو که الگوریتم‌های فشرده سازی خوب انجام می‌دن، مدیریت فضاهای خالی است.

شاید بد نباشه به صورت یک کار تحقیقی بررسی بشه که اگر فشرده سازی رو فعال کردیم چند درصد روی حجم دریافتی تاثیر داره. اگر روش حذف فضاهای خالی رو بدون فشرده سازی اعمال کردیم، چند درصد فرقش هست.