۹ سال و ۹ ماه قبل، چهارشنبه ۳ دی ۱۳۹۳، ساعت ۰۴:۵۳
۹ سال و ۹ ماه قبل، چهارشنبه ۳ دی ۱۳۹۳، ساعت ۰۰:۳۴
از متد Any قبل از ثبت در متد Seed استفاده کنید:
if (!context.MemberSettings.Any()) { // ... add new MemberSettings }
۹ سال و ۹ ماه قبل، سهشنبه ۲ دی ۱۳۹۳، ساعت ۱۸:۵۸
از این نسخهی اصلاح شده استفاده کنید: PersianDatePicker-93.10.02.zip
۹ سال و ۹ ماه قبل، سهشنبه ۲ دی ۱۳۹۳، ساعت ۱۴:۰۹
- این فایل باید به ازای هربار تغییر در مدلها دوباره ساخته شود. بنابراین تولید دوباره آن نباید غیرفعال شود.
- Assembly.GetExecutingAssembly().Location برای برنامههای دسکتاپ مفید است (یعنی مسیر فایل اجرایی). در برنامههای وب، به این مسیر عموما دسترسی ندارید. به همین جهت بهتر است از HttpRuntime.AppDomainAppPath استفاده کنید.
- Assembly.GetExecutingAssembly().Location برای برنامههای دسکتاپ مفید است (یعنی مسیر فایل اجرایی). در برنامههای وب، به این مسیر عموما دسترسی ندارید. به همین جهت بهتر است از HttpRuntime.AppDomainAppPath استفاده کنید.
۹ سال و ۹ ماه قبل، سهشنبه ۲ دی ۱۳۹۳، ساعت ۰۴:۵۲
با فرمهای مودال بوت استرپ 3، در دو حالت in-line و remote آزمایش شد؛ مشکلی نبود.
مثال بررسی شده: MvcAppPersianDatePicker-2.zip
مثال بررسی شده: MvcAppPersianDatePicker-2.zip
۹ سال و ۹ ماه قبل، سهشنبه ۲ دی ۱۳۹۳، ساعت ۰۲:۵۰
متد AddOrUpdate مطابق توصیه تیم EF فقط برای متد Seed طراحی شدهاست و از آن در برنامه استفاده نکنید (چون برخلاف تصور، تمام خواص را به روز رسانی میکند و اگر در این بین اطلاعاتی مقدار دهی نشود، با نال جایگزین خواهد شد که علت بروز خطای فوق است). هدف اصلی آن هم صرفا عدم ثبت اطلاعات تکراری در حین فراخوانی متد Seed است. به همین جهت آنرا در فضای نام System.Data.Entity.Migrations قرار دادهاند. اطلاعات بیشتر
۹ سال و ۹ ماه قبل، دوشنبه ۱ دی ۱۳۹۳، ساعت ۱۸:۱۳
اگر از VS 2013 و EF 6 استفاده میکنید، حالت DB First آن در حقیقت مهندسی معکوس دیتابیس موجود به حالت Code first است. برای مثال اگر این فایل DbModel.edmx را تولید کند، ذیل آن فایل DbModel.Context.tt مشخص است که حاصل آن تولید خودکار یک چنین کلاسی است:
این کلاس دقیقا از DbContext حالت Code first استفاده میکند و کلا ObjectContext قدیمی را کنار گذاشتهاند (حتی برای حالت DB First).
بنابراین تمام نکات مطلب جاری در مورد حالت DB First موجود در VS 2013 صادق است. فقط باید فایل DbModel.Context.tt آنرا اصلاح کنید تا IUnitOfWork را به صورت خودکار به انتهای تعریف کلاس Context اضافه کند. مابقی مسایل آن یکی است.
//------------------------------------------------------------------------------ // <auto-generated> // This code was generated from a template. // // Manual changes to this file may cause unexpected behavior in your application. // Manual changes to this file will be overwritten if the code is regenerated. // </auto-generated> //------------------------------------------------------------------------------ namespace EFDbFirstDependencyInjection.DataLayer { using System; using System.Data.Entity; using System.Data.Entity.Infrastructure; public partial class TestDbIdentityEntities : DbContext { public TestDbIdentityEntities() : base("name=TestDbIdentityEntities") { } protected override void OnModelCreating(DbModelBuilder modelBuilder) { throw new UnintentionalCodeFirstException(); } public virtual DbSet<Category> Categories { get; set; } public virtual DbSet<Product> Products { get; set; } } }
بنابراین تمام نکات مطلب جاری در مورد حالت DB First موجود در VS 2013 صادق است. فقط باید فایل DbModel.Context.tt آنرا اصلاح کنید تا IUnitOfWork را به صورت خودکار به انتهای تعریف کلاس Context اضافه کند. مابقی مسایل آن یکی است.
۹ سال و ۹ ماه قبل، دوشنبه ۱ دی ۱۳۹۳، ساعت ۱۴:۳۰
- مراجعه کنید به نکته مطرح شده در مطلب «ساخت یک Form Generator ساده در MVC» زمانیکه قرار است یک آرایه از عناصر از کاربر دریافت شود. قسمتهای «ویوی نمایش فرم تولید شده برای کاربر نهایی» و ShowForm آن برای دریافت اطلاعات از کاربر، دقیقا یک لیست از شیء Value را دریافت میکنند.
- توضیحات تکمیلی آن در اینجا «ASP.NET Wire Format for Model Binding to Arrays, Lists, Collections, Dictionaries »
- توضیحات تکمیلی آن در اینجا «ASP.NET Wire Format for Model Binding to Arrays, Lists, Collections, Dictionaries »
۹ سال و ۹ ماه قبل، دوشنبه ۱ دی ۱۳۹۳، ساعت ۰۴:۱۹
- برای دریافت اطلاعات یک فرم مشخص:
- این پروژه از دیدگاه دریافت اطلاعات از کاربر و همچنین تولید فرم پویا جالب است (صرفا قسمت UI آن). به لطف نبود ViewState، طراحی فرمهای پویا در اینجا خیلی سادهتر است از وبفرمها.
- اما از دیدگاه ذخیره سازی این اطلاعات پویا ... مشکل دارد. در طراحی بانک اطلاعاتی آن فرض شدهاست که برنامه مثلا فرم یک را دارد. این فرم یک، 10 فیلد پویا یا بیشتر را دارد. این 10 فیلد فقط یکبار توسط کاربر پر میشوند. اگر کاربر قرار باشد بار دوم این فرم یک را پر کند، امکان پذیر نیست. در کلاس Value آن که فقط محتوای یک فیلد را ذخیره میکند، مفهومی به نام ردیف سند جاری وجود ندارد. به ازای هر فیلد یک ردیف مجزا داریم؛ اما مشخص نیست این ردیفها متعلق به کدام سند هستند (منظور از سند، شمار منحصربفرد پر کردن فرم جاری است؛ هر کاربر یک فرم را بیش از یکبار میتواند پر کند).
برای حل این نوع مشکلات (برای اینکه به ازای مقدار هر فیلد فرم پویا، یک ردیف مجزا تولید نشود و schemaless کار کرد) یا باید از یک بانک اطلاعاتی NoSQL استفاده کرد که مثلا کل فرم را در قالب یک شیء JSON سریالایز کند و آنرا داخل یک فیلد از یک ردیف (یک سند) ذخیره کند. یا اگر با SQL Server کار میکنید، فیلد XML آن چنین قابلیتی را دارد. کل اطلاعات دریافتی فرم را تبدیل به XML کنید و سپس ذخیره. به این صورت امکان تهیه کوئری و گزارش گرفتنهای پیشرفته و بهینه را به همراه تعریف ایندکس و مسایل دیگر نیز خواهید داشت. اینبار هر ردیف بانک اطلاعاتی، مفهوم یک سند کامل را پیدا میکند؛ بجای اینکه هر ردیف فقط یک مقدار از یک فیلد باشد. همچنین در این حالت هر ردیف میتواند محتوای فرمی را ذخیره کند که با ردیف بعدی کاملا متفاوت است (بر اساس طراحی پویای متفاوت هر فرم).
public IList<Value> GetValues(int formId) { return _values.Include(x => x.Field) .Where(value => value.FormId == formId) .ToList(); }
- اما از دیدگاه ذخیره سازی این اطلاعات پویا ... مشکل دارد. در طراحی بانک اطلاعاتی آن فرض شدهاست که برنامه مثلا فرم یک را دارد. این فرم یک، 10 فیلد پویا یا بیشتر را دارد. این 10 فیلد فقط یکبار توسط کاربر پر میشوند. اگر کاربر قرار باشد بار دوم این فرم یک را پر کند، امکان پذیر نیست. در کلاس Value آن که فقط محتوای یک فیلد را ذخیره میکند، مفهومی به نام ردیف سند جاری وجود ندارد. به ازای هر فیلد یک ردیف مجزا داریم؛ اما مشخص نیست این ردیفها متعلق به کدام سند هستند (منظور از سند، شمار منحصربفرد پر کردن فرم جاری است؛ هر کاربر یک فرم را بیش از یکبار میتواند پر کند).
برای حل این نوع مشکلات (برای اینکه به ازای مقدار هر فیلد فرم پویا، یک ردیف مجزا تولید نشود و schemaless کار کرد) یا باید از یک بانک اطلاعاتی NoSQL استفاده کرد که مثلا کل فرم را در قالب یک شیء JSON سریالایز کند و آنرا داخل یک فیلد از یک ردیف (یک سند) ذخیره کند. یا اگر با SQL Server کار میکنید، فیلد XML آن چنین قابلیتی را دارد. کل اطلاعات دریافتی فرم را تبدیل به XML کنید و سپس ذخیره. به این صورت امکان تهیه کوئری و گزارش گرفتنهای پیشرفته و بهینه را به همراه تعریف ایندکس و مسایل دیگر نیز خواهید داشت. اینبار هر ردیف بانک اطلاعاتی، مفهوم یک سند کامل را پیدا میکند؛ بجای اینکه هر ردیف فقط یک مقدار از یک فیلد باشد. همچنین در این حالت هر ردیف میتواند محتوای فرمی را ذخیره کند که با ردیف بعدی کاملا متفاوت است (بر اساس طراحی پویای متفاوت هر فرم).
۹ سال و ۹ ماه قبل، شنبه ۲۹ آذر ۱۳۹۳، ساعت ۱۸:۰۳
نیازی به مثال آنچنانی ندارد. ابتدا بستهی نیوگت این پروژه را نصب کنید:
بعد یکبار در ابتدای برنامه در اولین کوئری، متد InteractiveViews.SetViewCacheFactory آنرا فراخوانی کنید. البته بهتر است آنرا درون یک سینگلتون thread safe قرار دهید. بار اولی که فایل xml آن ایجاد میشود زمان خواهد برد. بار دوم اجرای برنامه سریع است.
PM> Install-Package EFInteractiveViews
private static bool _isPreGeneratedViewCacheSet; private void InitializationPreGeneratedViews() { if (_isPreGeneratedViewCacheSet) return; var precompiledViewsFilePath = new FileInfo(Assembly.GetExecutingAssembly().Location).DirectoryName + @”\EF6PrecompiledViews.xml”; InteractiveViews.SetViewCacheFactory(this, new FileViewCacheFactory(precompiledViewsFilePath)); _isPreGeneratedViewCacheSet = true; }