‫۱۰ سال و ۱۱ ماه قبل، جمعه ۳ آبان ۱۳۹۲، ساعت ۲۳:۱۸
در مورد سینگلتون نبودن، بله. نیازی به new هم نداره (حالت معمولی ذکر آن کافی است). در حالت پیش فرض، به ازای هربار فراخوانی، یک وهله جدید را ایجاد می‌کند. مگر اینکه در همینجا صریحا ذکر کنید که سینگلتون نیز مدنظر شما است یا مثلا حالت زنده نگه داشتن شیء در طول عمر یک درخواست وب، مهم است.
‫۱۰ سال و ۱۱ ماه قبل، جمعه ۳ آبان ۱۳۹۲، ساعت ۲۲:۱۷
- بله. باید Context تخریب و بازسازی مجدد شود؛ یا باید از سیستم Tracking آن کوئری بگیرید و سپس مواردی را که تغییر کرده‌اند به حالت اول برگردانید و یا روش سوم استفاده از متد Reload بر روی یک dbContext.Entry است.
+ طول عمر یک Context باید کوتاه باشد یا حداکثر در حد طول عمر یک فرم و نه طول عمر یک برنامه.
+ دو مطلب مرتبط
  بایدها و نبایدهای استفاده از IoC Containers  
 
نکته‌ای در مورد مدیریت طول عمر اشیاء در حالت HybridHttpOrThreadLocalScoped در برنامه‌های دسکتاپ 

برای اینکه با SimpleIoc هم بتوانید وهله‌های متفاوتی را دریافت کنید و نه الزاما استفاده به صورت سینگلتون، باید به متد GetInstance آن یک کلید مشخص را ارسال کنید (مثلا نام فرم جاری یا آدرس صفحه جاری)؛ اگر کلیدی ارسال نشود، سینگلتون عمل می‌کند. در کل بهتر است از یک IoC Container بهتر استفاده کنید که در مورد طول عمر اشیاء راه‌حل‌های متفاوتی را به همراه دارد؛ مانند StrcutureMap. همچنین استفاده از آن به الگوی Service locator محدود نباشد.
‫۱۰ سال و ۱۱ ماه قبل، جمعه ۳ آبان ۱۳۹۲، ساعت ۲۱:۰۱
من توی سازنده کلاس Locator کد زیر را نوشتم
SimpleIoc.Default.Register<IUnitOfWork, SampleContext>();

و بعد هر کجا نیاز دارم از این کد استفاده می‌کنم:
_uow = ServiceLocator.Current.GetInstance<IUnitOfWork>();

مشکلی که دارم وقتی SaveChanges را فراخوانی می‌کنم داخلش this.GetValidationErrors را فراخوانی کردم چون تنها یک instance از SampleContext ساخته میشه خطاهای قبلی دوباره وجود داره.
راهکاری هست خطاها را پاک کرد؟
‫۱۱ سال و ۳ ماه قبل، سه‌شنبه ۴ تیر ۱۳۹۲، ساعت ۱۴:۴۰
مشکلی مشاهده نشد: (تصویری است از یک کنترل مرورگر وب که در آن یک صفحه html بارگذاری شده است)

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

‫۱۱ سال و ۳ ماه قبل، جمعه ۳۱ خرداد ۱۳۹۲، ساعت ۲۲:۰۳
فقط سه مورد (DbEntityValidationException, DbUpdateException, DbUpdateConcurrencyException)  از استثناهای ویژه EF Code first در متد ApplyAllChanges بررسی شدند به همراه خطاهای اعتبارسنجی. مابقی استثناها در صورت رخ دادن به لایه‌های بالاتر منتشر خواهند شد (چون catch نشدند).
همچنین کدهای تکراری نحوه نمایش فقط این سه مورد ویژه و بررسی خطاهای اعتبارسنجی، ضرورتی به تکرار یا بررسی در کل برنامه را ندارد. نیازی نیست در کل برنامه if/else نوشت که بررسی شود آیا خطای اعتبارسنجی هست یا خیر، زمانیکه می‌شود آن‌را به صورت مرکزی و پاکیزه، مدیریت کرد و مدیریت این‌ها هم حالت خاص دیگری ندارد (باید لاگ شوند و باید به اطلاع کاربر رسانده شوند که هر دو مورد در اینجا خودکار است). حداکثر این است که از نحوه نمایش آن راضی نیستید. کار سورس باز است. تغییرش بدید. این روش و این صفحه دیالوگ مطابق سلیقه من طراحی شده.
به علاوه در لایه‌های بالاتر نیز نیازی به بررسی سایر استثناها نیست چون این موارد در فایل App.xaml.cs در بالاترین سطح ممکن دریافت و لاگ می‌شوند؛ همچنین به کاربر هم نمایش داده خواهند شد (در متدهای appDispatcherUnhandledException و currentDomainUnhandledException).

البته این برنامه دسکتاپ است که یک چنین اجازه‌ای رو می‌ده. در برنامه‌های وب این موارد توسط ELMAH لاگ خواهند شد و به کاربر پیغام کلی خطایی رخ داده نمایش داده می‌شود.