- خیر. این مورد توسط بانک اطلاعاتی بررسی می‌شود و EF در آن نقشی ندارد و در نهایت در صورت شکست، استثنای مرتبط را از بانک اطلاعاتی به برنامه منتقل می‌کند.
- روش مناسب اعتبار سنجی آن، استفاده از Remote validation است (مثلا در حین ثبت نام بررسی کند که آیا ایمیل وارد شده در بانک اطلاعاتی موجود است یا خیر).

برای نگاشت خواص می‌توان از AutoMapper استفاده کرد (^ و ^).

«برخی» همان ویژگی «JsonIgnore» مطلب «بررسی مقدمات کتابخانه‌ی JSON.NET» است. 

هیچ دلیل دیگری. اگر این نکته را اعمال کرده بودید، دقیقا آدرس یافت نشده را در استثنای حاصل می‌توانستید مشاهده کنید.

«Application_End» ذکر شده در مطلب که فقط یکبار در پایان کار برنامه فراخوانی خواهد شد، متفاوت هست با «Application_EndRequest» ایی که در انتهای هر درخواست اجرا می‌شود.

زمانیکه از یک IoC Container استفاده می‌کنید، بجای new MyClass می‌توانید بنویسید:
در حالت اول، تمام وابستگی‌ها را هم خودتان باید به همراه new ارائه کنید. در حالت دوم تا n سطح وابستگی هم بر اساس تنظیمات اولیه‌ی IoC Container به صورت خودکار وهله سازی می‌شوند.

- «ساده‌ترین روش کار با Github در ویندوز»
- «مراحل ارسال یک پروژه‌ی Visual Studio به GitHub»
و ...    

این نکته‌ای را که عنوان کردید با استفاده از DNTProfiler بررسی کردم و اصلا چنین چیزی (28 بار فراخوانی) نیست. در پشت صحنه از نسخه‌ی Async متد Find استفاده می‌شود (در stack trace موجود هست) و حذف آن با متد ساده‌ای که نوشته شده، یک سری از سازوکارهای داخلی ASP.NET Identity را حذف می‌کند و به صلاح نیست.

- مثال‌های متفرقه را در این سایت مطرح نکنید. مثال بررسی و اصلاح شده در اینجا قرار دارد.
- زمانیکه یک شیء وهله سازی می‌شود، فقط بر اساس یکی از سازنده‌های آن وهله سازی خواهد شد و نه تمام آن‌ها. این‌ها اصول اولیه‌ی کار با سی شارپ هست.
- در مثال متفرقه‌ای که مطرح کردید، نیازی به تعریف همزمان DbContext و همچنین IdentityDbContext نیست و کار اضافی انجام دادید؛ چون در اصل یکی هستند و بر اساس نیاز کلاسی که از آن ارث بری شده باید IdentityDbContext متفرقه باشد و نه DbContext خام.

برای توضیحات بیشتر در مورد IIdentity مراجعه کنید به مطلب «تزریق وابستگی‌های رایج ASP.NET MVC به برنامه»