- NuGet فقط یک ابزار دریافت و افزودن خودکار اسمبلی‌ها به پروژه است. کاری به برنامه وب یا ویندوز ندارد. حتی نیازی به ویژوال استودیو هم ندارد. از طریق خط فرمان هم قابل اجرا است: (^)
- فایل CHM سایت در دسترس هست. بالای سایت قسمت گزیده‌ها. خلاصه وبلاگ.

- بله. تعاریف کلاس رو که دارید. این‌ها رو هم باید دستی اضافه کنید. 
- در قسمت اول اشاره کردم به db.Blogs.Local . این خاصیت Local از نوع ObservableCollection است که در برنامه‌های WPF و Silverlight می‌تونه جذاب باشه.

- بله. استثنای زیر را دریافت خواهید کرد:
Entities may have been modified or deleted since entities were loaded
- اونجا هم وجود داره. در طراح EF در VS.NET یک فیلد رو می‌تونید انتخاب کنید. بعد در برگه خواص، ConcurrencyMode رو تعیین کنید.

نه. همانطوری که کوئری را صادر کردید اجرا می‌شود. یعنی فقط بر اساس primary key کار آپدیت یا delete را انجام می‌دهد.

بله. بحث DB Migration روی همین مورد تمرکز دارد. جزئیات آن مفصل است. بسیار کاملتر است از نمونه NHibernate و طراحی مهندسی قابل توجهی دارد. شاید توضیحش نیاز به دو جلسه داشته باشد.

من در قسمت «««««««««««««««دوم»»»»»»»»»»»»»»»»»»»»»» از «ارث بری» و مباحث Table-per-Type Inheritance و Table-per-Hierarchy strategy صحبتی نکردم. این‌ها در قسمت‌های «««««««««««««««««««««««««««««««بعد»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»» بررسی می‌شوند.

- می‌تونید SetInitializer رو به null مقدار دهی کنید تا کاری به بانک اطلاعاتی نداشته باشد.
و در حالت کلی، بله. مبحثی هست که اخیرا اضافه شده به نام DB Migration که در چند قسمت بعد به آن خواهیم رسید.

در SQL Server برای کار با بانک اطلاعاتی یک سری سطوح امنیتی وجود دارد. عنوان کردید که من یک نام کاربری دارم و پسود و از آن در رشته اتصالی استفاده می‌کنیم. بله. این درسته. اما این فقط ابتدای کار است. زمانیکه کاربری در SQL Server تعریف می‌شود یک سری سطح دسترسی را می‌شود به آن داد یا از آن گرفت. مثلا دسترسی اجرای SPها را نداشته باشد؛ دسترسی drop بانک اطلاعاتی را نداشته باشد؛ یا امکان فراخوانی delete را نداشته باشد. برای اینکه این موارد را بهتر مدیریت کنند یک schema تعریف می‌شود که در حقیقت قالبی است جهت مشخص سازی این سطوح دسترسی. dbo یکی از این قالب‌ها است که جزو مجموعه بالاترین سطوح دسترسی است. در هاست‌های اشتراکی که به مسایل امنیتی اهمیت می‌دهند امکان نداره به شما دسترسی dbo بدن. بله شما نام کاربری و کلمه عبور دارید اما schema سفارشی شما ممکن است دسترسی drop یا create بانک اطلاعاتی رو نداشته باشه (که در هاست‌های خوب ندارید).
این مساله چه مشکلی رو ایجاد می‌کنه؟
اگر کوئری پیش فرض شما select * from dbo.table1 باشد، در یک هاست اشتراکی با سطح دسترسی بالا که به شما دسترسی drop و create یک بانک اطلاعاتی رو نداده، دیگر اجرا نخواهد شد چون dbo نیستید. ضمنا روش صحیح و توصیه شده کار با SQL Server نیز ذکر schema در کوئری‌ها است زیرا سرعت اجرا را بالا می‌برد از این لحاظ که اگر آن‌را ذکر نکنید، SQL Server مجبور خواهد شد دست به سعی و خطا بزند. اما با ذکر آن یک راست از سطح دسترسی صحیح استفاده می‌شود. EF هم از همین روش استفاده می‌کنه. بنابراین لازم است schema رو اینجا در صورت مساوی نبودن با dbo حتما ذکر کرد و گرنه کوئری‌های شما دیگر اجرا نخواهند شد، چون دسترسی dbo رو ندارید.

- این‌ها مباحث پایه‌ای SQL Server است. در مورد schema ایی که از آن صحبت شد می‌تونید اینجا بیشتر مطالعه کنید: (^)
- شما در ASP.NET MVC می‌تونید این موارد رو سفارشی کنید و از پیاده سازی خودتون استفاده کنید. در یک قسمت مجزا به این مورد پرداختم که در سایت هست (^). به علاوه پروژه‌هایی مانند این هم وجود دارند: (^)

بله؛ این امکان وجود دارد که سیستم را افزونه پذیر کرد و مدل‌ها رو در زمان اجرا به DbContext اضافه کرد.
جزئیات آن خارج است از بحث «قسمت دوم» ما.