مثلا در مثال inverse property، باید اسم فیلد معادل به صورت رشته ای ذکر بشه. حالا اگه این اسم تغییر کرد چطور باید ردیابی بشه. 

این مساله به فرض تو بایندینگ ها، مثلا برای dropdownlist ، هم یه مقدار آدم رو نگران میکنه و یکی از ویژگی‌های مثبت استفاده از Linq رو که وجود intelisence و بررسی در زمان کامپایل هست نقض میکنه.

من قبلا هم این نظر خودم رو عنوان کردم. ولی به دلیل رعایت همین نکته هشتم، شما حتی منتشرش هم نکردید!
کاملا قبول دارم که اینجا یک پایگاه کاملا فنی هستش و امتیاز مثبتش هم همینه. اما قبول کنید برای یک برنامه نویس ( یا هر حرفه دیگه ای) علاوه بر نکات فنی، یک سری نکات هم هست که شاید بشه بهش گفت اخلاقیات حرفه، یا ترفندهای حرفه یا ...هر اسم دیگه ای. مثل تجربیاتی که مثلا شما از کار در محیط‌های مختلف به دست آوردید، روش‌های به روز نگه داشتن خود، چگونگی طی کردن مراحل پیشرفت و ..

به نظر من شاید بشه  نکات فنی رو از کتاب‌ها دریافت کرد، ولی این نکات که من عنوان کردم حتی اگه نمونه خارج از کشوری هم داشته باشن، شاید کارایی لازم رو در داخل کشور نداشته باشن، یعنی بومی سازی نشدن! و البته این مطالب با مطالب بی فایده ای که بعضی وبلاگ‌ها منتشر می‌کنند و خاطرات و مسایل شخصی خودشون رو در محیط کار مطرح می‌کنند متفاوته.

امیدوارم تونسته باشم منظورم رو بیان کنم.

همونطور که خودتون مثال زدید مهاجم ممکنه به جای اسم فایل یک مسیر مثلا ~/web.config رو به کنترلر بفرسته، خب اگه با این مسیر به صورت یک اسم برخورد بشه مثلا میشه : 

 درسته؟ یعنی در این صورت هم باز از ریشه، فایل web.config برمیگرده؟

underlying connection was closed. the connection was closed unexpectedly

رو نمایش بدیم. چون user1 و user2 نامهای شفافی نیستن. 

2-  fluent api که فرمودین رو بررسی می‌کنم، ولی راستش متوجه نشدم که روشی که استفاده کردم درست هست یا نه. در واقع به جای استفاده از navigation property‌های خودکار، خودم با اضافه کردن یه property مثلا با نام InsertUsername، نام کاربر درج کننده رو برمیگردونم. ( همون که تو کد کامنت قبلی نوشتم).

اینجا هم به نظرم تا موقعی که از InsertUsername استفاده نشه، مراجعه به دیتابیس انجام نمیشه، درسته؟

وقتی جداول بزرگ باشند و تعداد navigation property‌ها زیاد، مخصوصا وقتی مراجعه به یک جدول چندبار اتفاق بیفتد ( مثلا فیلدهایی مثل InsertUserId و DeleteUserId داشته باشیم که هردو به جدول user مراجعه می‌کنند) EF نام‌های نامناسبی تولید میکنه که هنگام استفاده نمیشه تشخیص داد کدوم یکی مثلا به InsertUserId   و کدوم یکی به DeleteUserId مربوط میشه. اگر هم بخوایم دستی نامگذاری‌ها رو تغییر بدیم، علاوه بر وقتگیر بودن، با هربار تغییر مدل، دوباره باید اینکار رو تکرار کنیم. 

public string InsertUsername 
{
    get { return DB.Users.Where(x=>x.Id == InsertUserId).Select(x=>x.Username).FirstOr Default(); } 

     private set {}

};