نکته‌ی غیرفعال کردن کش مرورگر در MVC رو تست کردید؟
۱۰ سال و ۲ ماه قبل، جمعه ۱۰ مرداد ۱۳۹۳، ساعت ۱۶:۳۷
۱۰ سال و ۲ ماه قبل، پنجشنبه ۹ مرداد ۱۳۹۳، ساعت ۱۵:۳۳
فرض کن داری از یک هاست اشتراکی استفاده می‌کنی. دسترسی ادمین هم روی سرور نداری برای اجرا سرویس ویندوز یا فرض کن در یک سازمان بهت گفتن ما فقط اجازه می‌دیم فایل‌های سایتت رو روی سرور کپی کنی. دسترسی بیشتری بهت نمی‌دیم. اون وقت چکار می‌کنی؟
۱۰ سال و ۲ ماه قبل، چهارشنبه ۸ مرداد ۱۳۹۳، ساعت ۱۶:۴۰
خوب کاربر رو اینقدر عذاب ندید. همون قسمت بررسی با Regex کافی هست. بیشتر نیازی نیست.
input = input.PadLeft(10, '0');
if (!Regex.IsMatch(input, @"^\d{10}$"))
return false;
۱۰ سال و ۲ ماه قبل، چهارشنبه ۸ مرداد ۱۳۹۳، ساعت ۱۶:۳۸
خیلی از قابلیت‌ها مخصوص سازمان‌ها طراحی می‌شن.
۱۰ سال و ۲ ماه قبل، پنجشنبه ۲ مرداد ۱۳۹۳، ساعت ۱۷:۱۱
یک جدول طراحی کنید به نام mass mail که در آن یک Content به علاوه فیلد IsDone وجود داره. مدیر سیستم متن خودش رو به صورت معمول در این جدول ثبت کنه. در وظیفه‌ی پس زمینه، رکوردهایی را که IsDone آن‌ها false است یکی یکی یافته و پردازش کنید. بعد از اتمام کار، IsDone هر رکورد را true کنید.
مزیت این روش اینه که دو ترد کاملا مجزای رابط کاربری و ترد وظیفه‌ی پس زمینه، هیچ تداخل و تماسی با هم نخواهند داشت تا سبب کرش برنامه شوند.
۱۰ سال و ۲ ماه قبل، پنجشنبه ۲ مرداد ۱۳۹۳، ساعت ۱۵:۴۴
ترد اجرایی یک وظیفه‌ی پس زمینه با ترد اجرایی یک درخواست وب یکی نیست. بنابراین نمی‌تونید به اشیاء رابط کاربری در تردی دیگر دسترسی داشته باشید. در برنامه‌های دسکتاپ اگر اینکار را انجام بدید، برنامه آنی کرش می‌کنه. در وب هم فرقی نمی‌کنه؛ اصول یکی هست.
کاری که می‌خواهید انجام بدید کلا نباید از این طریق انجام بشه. اگر هدفتون مثلا پیاده سازی auto-save هست که در بعضی از سایت‌ها دیدید که هر از چند ثانیه یکبار متن رو ذخیره می‌کنند، این رو با یک تایمر جاوا اسکریپتی سمت کاربر و Ajax انجام می‌دن و نه با یک وظیفه‌ی پس زمینه.
۱۰ سال و ۲ ماه قبل، پنجشنبه ۲ مرداد ۱۳۹۳، ساعت ۱۴:۲۶
ضمن تشکر از ایده‌ای که مطرح کردید. طول عمر httpContext.Items فقط محدوده به یک درخواست و پس از پایان درخواست از بین می‌ره. مثلا یکی از کاربردهاش ذخیره اطلاعات Unit of work در طول یک درخواست هست و بعد از بین رفتن خودکار آن. بنابراین در این مثال cache.GetViewLocation اصلی بعد از یک درخواست مجددا فراخوانی میشه، چون GetRequestCache نه فقط طول عمر کوتاهی داره، بلکه اساسا کاری به key متد GetViewLocation نداره. کار s_key تعریف شده عموما تعریف lock هست نه استفاده ازش به عنوان کلید دیکشنری. بنابراین اگر خود MVC از HttpContext.Cache استفاده کرده، کار درستی بوده، چون به ازای هر درخواست نیازی نیست مجددا محاسبه بشه.
۱۰ سال و ۲ ماه قبل، شنبه ۲۸ تیر ۱۳۹۳، ساعت ۱۶:۱۱
خود EF متدی به نام AddOrUpdate داره: http://msdn.microsoft.com/en-us/library/hh846520%28v=vs.103%29.aspx
در اصل تک مسئولیتی، مسئولیت به دلیل تغییر یک کلاس ترجمه میشه. بنابراین در این اصل می‌گن که یک کلاس باید فقط یک دلیل برای تغییر داشته باشه. برای مثال کلاسی که هم اطلاعات گزارشی رو تهیه می‌کنه و هم اون رو پرینت می‌کنه، دو مسئولیت رو به عهده گرفته که میشه از هم جداشون کرد. اما در اینجا یک مسئولیت به روز رسانی اطلاعات یک موجودیت خاص بیشتر در کار نیست. دلیل دومی برای تغییر کلاس نداریم. وابستگی خارجی دومی نداره.
۱۰ سال و ۳ ماه قبل، دوشنبه ۲۳ تیر ۱۳۹۳، ساعت ۱۵:۳۰
در مطلب استفاده مستقیم از عبارات SQL در EF Code first بحث شده. از متد جنریک db.Database.SqlQuery باید استفاده کنید.
۱۰ سال و ۳ ماه قبل، جمعه ۲۰ تیر ۱۳۹۳، ساعت ۱۷:۳۰
- کاری که می‌خوای، منطقا زیر سؤاله. هم قرار نال پذیر باشه. هم کاربر باید اجبارا پرش کنه! یعنی چی اینکار؟!
- در مورد ویژگی‌های اعتبار سنجی سفارشی و مدیریت کدهای سمت کلاینت اون‌ها مطلب در سایت موجوده:
طراحی ValidationAttribute دلخواه و هماهنگ سازی آن با ASP.NET MVC