در کل برنامه، یک IoC Container‌ بیشتر وجود ندارد. تفاوت ApplicationServices با RequestServices در اصل به وجود یا نبود Scope بر می‌گردد. زمانیکه سرویسی را از ApplicationServices درخواست می‌کنید، مطلقا Scope ای برای آن ایجاد نمی‌شود و اگر مجددا درخواست شود، طول عمر Singleton را مشاهده می‌کنید (مباحث قسمت سوم)، صرف نظر از طول عمر تعریف شده‌ی برای آن سرویس؛ مگر اینکه خودتان به نحوی که توضیح داده شد، یک Scope سفارشی را برای آن ایجاد کنید. اما چون HttpContext.RequestServices داخل یک Scope پیش‌فرض درخواست جاری وب قرار دارد، نیازی به ایجاد صریح Scope را ندارد. البته Scope Validation توضیح داده شده‌ی در مطلب جاری که به ASP.NET Core 2.0 اضافه شده‌است، جلوی اینگونه اشتباهات را با صدور یک استثناء در زمان اجرا می‌گیرد.

با سلام منظور از اندازه سرویس‌ها در معماری SOA  مثلا سیستم فروش که شامل فروش -خرید تخفیف -موجودی انبار -هشدار در مورد تعداد کالای x  در انبارو Logger    و نوع فروش  و ... اما در معماری مایکرو سرویس این‌ها به سرویس‌های جدا گانه مثل هشدار یا همون notification  سرویس Logger و ... این طوری تقسیم می‌شن درست مثل تقسیم یک تابع بزرگ به تابع‌های کوچک‌تر با تفاوت اینکه این تقسیم‌ها باید در فضای Rest  اتفاق بیفته یعنی هیچ یک از سرویس‌ها ارتباط bınary رو ندارد و هر کدام به صورت خود مختار عمل می‌کنند مثال دیتابیس فروش Sql  هستش اما Logger مثلا mongo هستش و همشون با پروتکل http  در ارتباط هستند

در واقع دلیل حذف live و delegate و bind همه برای این بود که در یک متد on جمع آوری بشن. در حال حاضر on کار هر سه مورد رو انجام میده.
اگر به تستی که گقتم دقت کنید موجه میشین که بایند کردن یک رویداد به یک هندلر مستقیم اونقدر در سرعت تاثیری نداره که بخوایم اون رو فدای مصرف حافظه کنیم.
شما اگر بخواین در یک صفحه که کلی لینک مشابه هم داره و به ازای هر لینک که همه یک کار خاص انجام میدن یک هندلر داشته باشی به هیچ عنوان کار منطقی نیست.
تستی رو گفتم حتما انجام بدین تا متوجه بشین تفاوت بکارگرفتن و نگرفتن این دو روش در چی هست.

فکر میکنم عموما  پرس‌وجوی بازگشتی اگر ساپورت بشه توسط دیتابیس بهترین روش همان لیست مجاورت هستش که مدیریت درخت رو برامون ساده میکنه و دیتابیس کنترل بشتری رو هر نود ما داره. البته به غیر از مواردی خاص...

سلام من واقعا متوجه نحوه استفاده یا عدم استفاده از Session‌ها نشدم!
در Asp.net برای نگهداری یکسری از اطلاعات کاربر و یا هرگونه  اطلاعات مربوط به یک کاربر خاص از Session‌ها استفاده می‌کردیم.
حال در Mvc  برای نگهداری هر گونه اطلاعات کاربر Login شده از چی باید استفاده کرد. اگر جواب کوکی هاست این کوکی‌ها در سمت کلاینت ثبت می‌شود و نیاز است که اطلاعات در سمت سرور باشد.
کدم بهتره است : بخشی از حافظه برای اطلاعات کاربر جاری مصرف شود و درعوض در هر درخواستی از آن استفاده شود و یا خیر هربار این اطلاعات واکشی شود (البته بدون درنظر گرفتن سطح دوم کش).
همچنین Session‌ها در Mvc با Session در Asp.net چه تفاوت هایی دارد؟
ممنون میشم ابهام بنده را برطرف بفرمایید. 

سلام اقای نصیری . من دقیقا همین مشکل و خطا رو دارم  با این تفاوت که نمیخوام CasCade delete رو غیر فعال کنم . در واقع من یه کلاس دارم  که یکی از properties هاش یه لیستی از خود همین کلاس هست . یعنی به صورت تو در تو با خودش رابطه داره . مثله یه tree View  . حالا من میخوام با حذف پدر تمام فرزندان و فزندان فرزندان و ... تا پایین همشون دیلیت بشن . یعنی همون    on delete cascade خودمون . ولی خب اینجا میشه همونی که گفتین . حذف ابشاری حلقوی . این کار بخوام بکنم باید چیکار کنم . ؟ ممنون از لطفتون . منتظر پاسخم...

تشکر از شما و توضیحات ارزشمند دوستان گرامی.
پروپرتی و پروپرتی اتوماتیک امکانی است که در زبان سی شارپ و ... قرار داده شده است. پروپرتی‌ها نیز در حقیقت متدهای مشابهی دارند که همان اکسسورها هستند. تفاوت میزان بیشتر کپسوله سازی و مخفی کردن منطق پیاده سازی، و مهم‌تر سازگاری بیشتر با مفهوم ویژگی است. که البته در هنگام استفاده از پروپرتی سهولت بیشتری را نیز فراهم می‌کند.
همان که دوست عزیزم اشاره فرمودند به دلیل عدم سازگاری ذات زبان‌های مبتنی بر دات فریمورک از اکسسور، به صورت داخلی به متد تبدیل خواهند شد.
همچنین در مورد جاوا هم پروژه هایی وجود دارند که سعی کرده اند این امکان را به کمک یک سری Annotaion به آن بیافزایند.
در مورد سی شارپ استفاده از پروپرتی روش توصیه شده است.

سلام