۱۱ سال و ۹ ماه قبل، یکشنبه ۱ بهمن ۱۳۹۱، ساعت ۱۹:۵۶
۱۱ سال و ۹ ماه قبل، جمعه ۲۹ دی ۱۳۹۱، ساعت ۱۳:۱۸
خیر. این الگو خارج از توضیحات مطلب فوق در مورد «اهمیت بکارگیری الگوی Unit of work و به اشتراک گذاری آن در طی یک درخواست» کار دیگری را انجام نمیدهد.
۱۱ سال و ۹ ماه قبل، جمعه ۲۹ دی ۱۳۹۱، ساعت ۰۳:۴۳
بله. به ازای هر DbContext یک سری تنظیمات مجزا نیاز است. ردیابی تغییرات در یک context کار میکند. همچنین مباحث migrations هم به ازای یک context عمل خواهند کرد.
۱۱ سال و ۹ ماه قبل، جمعه ۲۹ دی ۱۳۹۱، ساعت ۰۳:۰۸
کاری که در اینجا انجام میشه ذخیره اطلاعات به صورت رمزنگاری شده در یک کوکی است. رمزنگاری، ذخیره و مدیریت این کوکی (AuthCookie) خودکار است. در سایر موارد خودتون این مراحل مدیریت کوکیها رو با کدنویسی شبیه سازی کنید.
۱۱ سال و ۹ ماه قبل، جمعه ۲۹ دی ۱۳۹۱، ساعت ۰۲:۵۰
بله. از Forms authentication استفاده کنید.
بعد userId رو به شکل فوق تنظیم کنید. از این به بعد با مراجعه به شیء User به صورت User.Identity.Name به مقدار UserId خواهید رسید.
FormsAuthentication.SetAuthCookie(user.Id.ToString(CultureInfo.InvariantCulture), loginInfo.RememberMe); FormsAuthentication.RedirectFromLoginPage(user.Id.ToString(), loginInfo.RememberMe);
۱۱ سال و ۹ ماه قبل، پنجشنبه ۲۸ دی ۱۳۹۱، ساعت ۱۶:۲۳
این موارد در آخرین لینکی که در متن مقاله است مفصل توضیح داده شده.
- بله. امکان تعریف چندین قلم وجود دارد.
- ذکر قسمت نام فایل اختیاری است (مثلا میشود به یک پوشه هم ارجاع داد). اما باید font family حتما ذکر شود.
- بله. امکان تعریف چندین قلم وجود دارد.
- ذکر قسمت نام فایل اختیاری است (مثلا میشود به یک پوشه هم ارجاع داد). اما باید font family حتما ذکر شود.
۱۱ سال و ۹ ماه قبل، سهشنبه ۲۶ دی ۱۳۹۱، ساعت ۲۰:۵۳
یک روش کلی زمانیکه همه چیز را دستی به هم ریختهاید وجود دارد:
- جدول سیستمی MigrationHistory را از بانک اطلاعاتی حذف کنید.
- کلاسهای قبلی migrations موجود را هم کلا حذف کنید (هرچیزی که وجود دارد).
حالا مراجعه کنید به قسمت چهارم «استفاده از Code first migrations بر روی یک بانک اطلاعاتی موجود» تا مجددا بتوانید جدول سیستمی MigrationHistory تازهای را تولید کنید:
دستورات فوق به این معنا هستند که فرض میشود تطابق کاملی بین بانک اطلاعاتی و کلاسهای مدل وجود دارند. اکنون جدول سیستمی MigrationHistory متناظری را تولید کن.
- جدول سیستمی MigrationHistory را از بانک اطلاعاتی حذف کنید.
- کلاسهای قبلی migrations موجود را هم کلا حذف کنید (هرچیزی که وجود دارد).
حالا مراجعه کنید به قسمت چهارم «استفاده از Code first migrations بر روی یک بانک اطلاعاتی موجود» تا مجددا بتوانید جدول سیستمی MigrationHistory تازهای را تولید کنید:
Add-Migration InitialMigration -IgnoreChanges Update-Database
۱۱ سال و ۹ ماه قبل، سهشنبه ۲۶ دی ۱۳۹۱، ساعت ۱۶:۲۵
تکمیل بحث:
گوگل به تنظیم canonical url هم نیاز دارد. بنابراین تنظیم ذیل به کلاس فوق اضافه شد:
و بعد در فایل layout برنامه خواهیم داشت:
گوگل به تنظیم canonical url هم نیاز دارد. بنابراین تنظیم ذیل به کلاس فوق اضافه شد:
filterContext.Controller.ViewBag.CanonicalUrl = absoluteUrlToLower;
<link rel="canonical" href="@ViewBag.CanonicalUrl"/>
۱۱ سال و ۹ ماه قبل، سهشنبه ۲۶ دی ۱۳۹۱، ساعت ۱۵:۵۶
این کتابخانه وابسته به MVC یا WinForms و امثال آن نیست. بر اساس دیتاسورس شما کار میکند و سایر تنظیماتی که با کدنویسی مشخص میکنید.
یکبار یک قالب کلی برای آن تهیه کنید. سپس از روش تولید پویای ستونها استفاده کنید:
الف) تولید پویای ستونها در حالت استفاده از SQL خام
ب) تولید پویای ستونها در حالت استفاده از ORMها
یکبار یک قالب کلی برای آن تهیه کنید. سپس از روش تولید پویای ستونها استفاده کنید:
الف) تولید پویای ستونها در حالت استفاده از SQL خام
ب) تولید پویای ستونها در حالت استفاده از ORMها
۱۱ سال و ۹ ماه قبل، سهشنبه ۲۶ دی ۱۳۹۱، ساعت ۱۴:۲۷
بحث ASP.NET متفاوت است با Windows Forms یا WPF. در برنامههای وب یک زیر ساخت آماده برای آغاز و پایان درخواستها و مدیریت خودکار این مسایل وجود دارد. معادل آن مثلا در یک برنامه مبتنی بر MVVM، مدیریت طول عمر یک context در طول عمر ViewModel برنامه است. علت این مساله هم به stateless بودن برنامههای وب و state-full بودن برنامههای ویندوزی بر میگردد. در یک برنامه وب در پایان درخواست، تمام اشیاء یک فرم در سمت سرور تخریب میشوند. اما در یک برنامه ویندوزی تا زمانیکه یک فرم باز است، اشیاء آن تخریب نخواهند شد. بنابراین مدیریت context در برنامههای ویندوزی «دستی» است. در زمان شروع فرم context شروع خواهد شد، زمان تخریب/بستن آن، با بستن یا dispose یک context، خودبخود اتصالات هم قطع خواهند شد.
در متد Program.Main هم میتونید تنظیمات اولیه ObjectFactory رو قرار بدید (شبیه به Application_Start برنامههای وب).
بنابراین در برنامههای وب «context/session per http request» داریم؛ در برنامههای ویندوزی «context per operation or per form». یعنی میتونید بسته به معماری برنامه ویندوزی خود، context را در سطح یک فرم تعریف کنید و مدیریت؛ و یا در سطح یک عملیات کوتاه مانند یک کلیک. تمام مباحث ObjectFactory.GetInstance، uow.SaveChanges و یا Dispose آن هم دستی است و زیر ساختی برای مدیریت خودکار آنها همانند برنامههای مثلا ASP.NET MVC وجود ندارد. حداکثر اینکه یک سری base class را شبیه به مثال Web forms زده شده تهیه کنید، تا میزان کدهای تکراری را کاهش بدید.
در متد Program.Main هم میتونید تنظیمات اولیه ObjectFactory رو قرار بدید (شبیه به Application_Start برنامههای وب).
بنابراین در برنامههای وب «context/session per http request» داریم؛ در برنامههای ویندوزی «context per operation or per form». یعنی میتونید بسته به معماری برنامه ویندوزی خود، context را در سطح یک فرم تعریف کنید و مدیریت؛ و یا در سطح یک عملیات کوتاه مانند یک کلیک. تمام مباحث ObjectFactory.GetInstance، uow.SaveChanges و یا Dispose آن هم دستی است و زیر ساختی برای مدیریت خودکار آنها همانند برنامههای مثلا ASP.NET MVC وجود ندارد. حداکثر اینکه یک سری base class را شبیه به مثال Web forms زده شده تهیه کنید، تا میزان کدهای تکراری را کاهش بدید.