SqlDependency محدود هست به SQL Server ضمن اینکه تنظیم آن هم فقط در سمت برنامه نیست. یعنی شخص استفاده کننده باید دسترسی مدیریتی به سرور SQL داشته باشه تا بتونه اون رو تنظیم کنه. ولی زمانیکه با یک ORM کار می‌کنید، تا زمانیکه از API همون ORM استفاده می‌کنید، با عوض کردن پروایدر اون، می‌تونید یک روز از SQL Server و یک روز از اوراکل یا سایر بانک‌های اطلاعاتی استفاده کنید. اینجا است که عدم نیاز به دسترسی مدیریتی و همچنین عمومی‌تر شدن راه حل یک مزیت مهم خواهد شد.
محسن خان محسن خان
طراحی گردش کاری با استفاده از State machines - قسمت اول
‫۹ سال و ۹ ماه قبل، دوشنبه ۸ دی ۱۳۹۳، ساعت ۲۰:۰۳
بهتر هست مطلب قسمت دوم رو در همون قسمت دوم پیگیری کنید. اگر قسمت دوم رو مطالعه کرده باشید، یک قسمت، طراحی کلی state machine هست (مثل کلاس BlogPostStateMachine). در قسمت بعدی اون طراحی manager که کار با دیتابیس در اونجا انجام میشه (مثل کلاس BlogPostManager). الان شما مطالب رو مخلوط کردید که نیازی نبوده. در کلاس BlogPostManager جاهایی که کامنت شده، قسمت‌هایی هست که از دیتابیس اطلاعات رو می‌خونه. اون قسمت‌ها رو خودتون پر کنید.
محسن خان محسن خان
اجرای وظایف زمان بندی شده با Quartz.NET - قسمت اول
‫۹ سال و ۹ ماه قبل، شنبه ۶ دی ۱۳۹۳، ساعت ۰۲:۳۵
از ELMAH استفاده می‌کنید؟ متدهای Application_End و Application_Start را با آن لاگ کنید و همچنین خطاهای مدیریت نشده برنامه را. با لاگ کردن عنوان شده بررسی کنید برنامه چندبار ری استارت شده.
محسن خان محسن خان
اجرای وظایف زمان بندی شده با Quartz.NET - قسمت اول
‫۹ سال و ۱۰ ماه قبل، چهارشنبه ۲۸ آبان ۱۳۹۳، ساعت ۱۳:۰۰

نظرات بالاتر رو خوندید یکبار؟ خلاصه‌اش اینه جهت تکرار:

«ترد اجرایی یک وظیفه‌ی پس زمینه با ترد اجرایی یک درخواست وب یکی نیست. بنابراین نمی‌تونید به اشیاء رابط کاربری در تردی دیگر دسترسی داشته باشید. در برنامه‌های دسکتاپ اگر این‌کار را انجام بدید، برنامه آنی کرش می‌کنه. در وب هم فرقی نمی‌کنه؛ اصول یکی هست.»

اگر dbContext مثلا در سطح فرم ایجاد شده، اون فرم زمانیکه وظیفه‌ی شما قراره اجرا بشه، از بین رفته. وجود خارجی نداره. کار «پس زمینه» به همین معنا هست. dbContext رو داخل وظیفه باید وهله سازی کنید.