احتمالا فایل jquery.bootstrap-modal-ajax-form.js ارسال نشده. کلا بررسی کنید که آیا فایل‌های موجود در پوشه‌ی اسکریپت‌ها ارسال شده یا نه.

• اگر علاقمند به نوشتن یک OCR‌ هستید، این مطلب و نظرات آن‌را مطالعه کنید. حداقل یک دید کلی نسبت به روش کار آن و هوش مصنوعی بکار گرفته شده‌ی در OpenCV پیدا می‌کنید.
• همچنین این سری پردازش تصویر با پایتون هم مفید است که به همراه دو ویدیوی OCR هم هست: ^ و ^. با توجه به اینکه پایتون نیز در پشت صحنه از همین OpenCV استفاده می‌کند، پس از آشنایی با روش کار، امکان ترجمه‌ی کدهای آن به #C، یا هر زبان دیگری هم وجود دارد (پایتون در اینجا فقط یک اینترفیس است و کار اصلی را OpenCV انجام می‌دهد).

• هدف شما در اصل یافتن یک یا چند «شیء مشخص»، در یک جدول بانک اطلاعاتی است. اگر از EF استفاده می‌کنید، هر رکورد/شیء شما، قطعا یک Id منحصربفرد هم دارد (تا یک «شیء مشخص» را تشکیل دهد). فقط بر اساس این Id کوئری بگیرید (نه بر اساس لیست تمام ستون‌های موجود). نتیجه‌ی کار، شبیه به کوئری اولی می‌شود که نوشتید (که البته اینجا، List آن از نوع int است و یا کلا نوع Pk جدول کاربران) و فوق العاده هم سریع است.
• اگر Idهای اشیاء موجود در لیست فوق را ندارید، باید از PredicateBuilder استفاده کنید تا بتوانید کوئری‌های Or پویایی را به ازای هر شیء، تولید کنید. الان این PredicateBuilder، جزئی از کتابخانه‌ی Gridify هم هست.

var predicate = PredicateBuilder.False<User>();

foreach(var user in customUsers)
{
   predicate = predicate.Or(u => u.FullName == user.FullName && 
                                 u.EyeColor == user.EyeColor);
}

var specificUsers = _context.Users.Where(predicate).ToList();

• آیا سرعت ثبت و به‌روز رسانی اطلاعات، در حالت متداول کار با بانک‌های اطلاعاتی رابطه‌ای بیشتر است از کار با فیلدهای XML؟ بله. چون حداقل یک قسمت serialize و deserialize فیلدهای XML ای را به همراه ندارند؛ به همراه امکان ایندکس‌گذاری، کوئری‌های سریع و تمام مزایای دیگر به همراه این نوع بانک‌های اطلاعاتی که تمام آن‌ها در مورد فیلدهای NoSQL آن‌ها صادق نیست.
• آیا حجم بانک اطلاعاتی که به صورت متداولی، رابطه‌ای است، کمتر است از نمونه‌ی مشابه NoSQL آن؟ بله. هدف ابتدایی طراحی این نوع بانک‌های اطلاعاتی رابطه‌ای دقیقا همین مورد بوده تا بتوانند اطلاعات بیشتری را در حجم کمتری ذخیره کنند و هزینه‌های به شدت بالای سخت‌افزاری آن زمان را کاهش دهند.
• برای سیستم‌های بزرگ و داده‌های قابل توجه، شما به مباحثی مانند مقیاس‌پذیری و یا حتی روش‌های دیگری برای کار نیاز خواهید داشت.

یقینا سرعت کار با بانک‌های اطلاعاتی رابطه‌ای و امکانات توکار آن‌ها همیشه بیشتر از کار با XML و هر حالت مشابه دیگری در آن‌هاست و بنابراین ... بله. حالت دوم بهینه‌تر نیست، سریعتر نیست و همچنین کم‌حجم‌تر هم نیست. اساسا بانک‌های اطلاعاتی رابطه‌ای زمانی طراحی شدند که یک هارد دیسک 4 مگابایتی، چندهزار دلار قیمت داشت. به همین جهت در زمینه ذخیره سازی اطلاعات، بسیار بهینه و کم‌حجم عمل می‌کنند؛ با حداقل تکرار و سربار و با سرعت بالا. استفاده از XML و JSON امثال این‌ها زمانی باب شدند که قیمت هارد دیسک‌های حجیم کاهش یافته بود و همچنین بیشتر سرعت read مطرح بود و نه سرعت write. اطلاعات بیشتر

لطفا این موارد پیشنهادی و مشکلات را در issue tracker مخزن کد سایت ارسال کنید.

یک مثال در این مورد جهت نمایش نحوه‌ی کار با سرویس‌ها در حین پیاده سازی اعتبارسنج‌ها

مزیت وجود این همه فریم‌ورک‌های اعتبارسنجی، عدم واگذاری یکسری از کارها به خود بانک اطلاعاتی است؛ وگرنه، بله. اتفاقا خود بانک اطلاعاتی به خوبی می‌تواند (یکسری از قیود «ابتدایی» تعریف شده‌ی در آن‌را و نه ... بررسی‌های پیچیده‌ی ممکن توسط فریم‌ورک‌های اعتبارسنجی را) اعتبارسنجی کند و درخواست‌های insert/update/delete را راسا خاتمه داده و برگشت بزند. البته ... در نهایت با پیام‌هایی غیرکاربرپسند و به همراه استثناءهایی که هزینه‌ها و سربارهایی را به سیستم تحمیل می‌کنند. به همین جهت ترجیح داده می‌شود که برای بررسی‌های پیچیده‌تر و همچنین نمایش پیام‌های کاربرپسندتری، پیش از ارسال اطلاعات به بانک اطلاعاتی، اعتبارسنجی‌های پیچیده در سمت برنامه انجام شوند.

• انتقال پارامترهای آبشاری، نیاز به تعریف cascading value در سطحی بالاتر دارند؛ یک مثال:

<CascadingValue Value=this>

• بر اساس طراحی ذاتی Blazor، راه‌حلی برای نال نشدن HttpContext در تمام حالات رندر وجود ندارد. در SSR در دسترس است و در مابقی خیر (^ و ^).

این پیشنهادات بر اساس تگ‌های وارد شده توسط کاربران سایت است ...