- من تمام مطالبی رو که اینجا عنوان کردم در مورد سی شارپ بود و الان در کارهای خودم دارم ازش استفاده می‌کنم. نمونه قابل کامپایل هم در سایت گذاشتم که لینکش رو دادم.
- این متد SaveChanges آخری با امضای جدید آن، دیگر متد SaveChanges کلاس پایه رو مخفی نمی‌کنه. به همین جهت نیازی به override نداره. بحث من در این مورد بود. نهایتا شما قراره با IUnitOfWork کار کنید. نام این متد رو اصلا تغییر بدید به ApplyChanges بعد هم داخل آن کارهای خودتون رو قرار بدید و دست آخر return base.SaveChanges بازگشت داده شود. ضرورتی ندارد حتما در این اینترفیس از نام SaveChanges استفاده شود. این یک انتخاب بود، بر اساس قسمت 12 جاری که ترکیبی نیست از چند قسمت دیگر. به این صورت می‌شد مبحث رو ساده‌تر و طبیعی‌تر توضیح داد.

اگر این متد، return base.SaveChanges را بر می‌گرداند نیازی به ذکر override نیست و می‌تونید برای متد SaveChanges حتی پارامتر هم تعریف کنید (البته اینترفیس هم باید به همین شکل اصلاح شود):
این شکلی است که من خودم ازش استفاده می‌کنم.

بله. اگر این‌ها رو بخواهید با هم ترکیب کنید همین شکلی است.

کدهای کامل و قابل کامپایل مورد نظر این قسمت از این آدرس قابل دریافت است. می‌تونید وقت بذارید و با کدهای خودتون مقایسه‌اش کنید.

- پیاده سازی متد SaveChanges در کلاس پایه DbContext که توسط تیم EF ارائه شده، انجام شده و وجود دارد.
- ذکر یک متد در اینترفیس (یک قرار داد) به جهت امکان استفاده از آن است. شما نهایتا با متدهای تعریف شده در طراحی IUnitOfWork در لایه سرویس قرار است کار کنید نه مستقیما با کلاس مشتق شده از DbContext.
زمانیکه می‌نویسید:
چند کار با هم انجام می‌شود:
MyContext به صورت خودکار امکان دسترسی به متد SaveChanges موجود در DbContext را پیدا می‌کند. کتابخانه StructureMap می‌تونه زمانیکه نیازی به یک وهله پیاده ساز IUnitOfWork بود، از MyContext استفاده کنه. همچنین چون الان SaveChanges با امضایی که در اینترفیس IUnitOfWork وجود دارد در کلاس MyContext هم قابل دسترسی است، نیازی به پیاده سازی مجدد آن نیست.

جمله «در هر رابطه‌ای که نیاز به تعریف کلید خارجی داشته باشد، بهتر است استفاده شود.» نسبتا جامع و مانع است. چون در رابطه 1:1 خودبخود کلید اصلی، کلید خارجی اشتراکی هم هست و نیازی به تعریف مجدد آن نیست.

در هر رابطه‌ای که نیاز به تعریف کلید خارجی داشته باشد، بهتر است استفاده شود.
مثلا رابطه many-to-many نیازی به این تعریف ندارد چون مدیریت جدول واسط بین دو موجودیت مرتبط که حاوی کلیدهای خارجی به این دو جدول است، خودکار می‌باشد.

روش اول بهتره. در کلاس Context نهایی و اصلی فقط باید تعاریف DbSet و حداکثر تحریف متد OnModelCreating وجود داشته باشد. مابقی کد تکراری است (و پایه انجام پروژه‌های دیگر) که می‌شود به MyDbContextBase انتقالشون داد. کل هدف این کلاس پایه، مدیریت کدهای تکراری بین پروژه‌های مختلف است.

هدف الگوی واحد کار این است که یک سری اعمال مرتبط با موجودیت‌های مختلف در یک تراکنش انجام شوند. در اینجا هم این مورد (مثلا یکی کردن ی و ک) در طی تراکنش جاری انجام خواهد شد. ضمن اینکه زمانیکه با IUnitOfWork کار می‌کنید هیچ وقت به صورت مستقیم با کلاس‌های مشتق شده از DbContext کار نخواهید کرد. وهله سازی و dispose این‌ها کار مثلا StructureMap و امثال آن خواهد بود.  
MyDbContextBase فقط برای مدیریت کدهای تکراری بین برنامه‌های مختلف ایجاد شده است. اصلا می‌تواند وجود خارجی هم نداشته باشد. اگر کل سیستم شما یک پروژه است و از این کدها نمی‌خواهید در پروژه دیگری استفاده کنید، یک کلاس مشتق شده از DbContext کفایت می‌کند. بنابراین اگر قصد استفاده مجدد از کدهای زیرساخت پروژه جاری خودتون رو در پروژه‌های دیگر دارید، می‌تونید به غنی سازی MyDbContextBase بیشتر بپردازید.

ارث بری رو به صورت «is a» معرفی می‌کنند و می‌خونند. یعنی هر دو حالتی که نام بردید یکی است و فرقی نمی‌کنه.