شاید دیگر قدرت فریم ورک AngularJS برای همه آشکار شده باشد. اما وقت و حوصله‌ی خواندن چند صد صفحه کتاب و مستندات برای یادگیری آن ندارید؟

دو نوع پیاده سازی سمت کلاینت برای این مطلب تهیه شده؛ مثال صفحه‌ی HTML آن در پوشه‌ی wwwroot و همچنین مثال کامل و جامع Angular آن. مثال صفحه‌ی HTML آن یک مثال ساده‌است برای توضیح مفاهیم و فاقد تایمری برای فعالسازی خودکار refresh token؛ درحالیکه مثال Angular آن دارای تایمر مخصوصی برای اینکار است و پیش از رسیدن به زمان انقضای access token، یک توکن جدید را درخواست می‌کند. همچنین در مثال HTML آن توکن‌ها در local storage مرورگر ذخیره نمی‌شوند و با refresh صفحه، متغیرهای موقتی جاوا اسکریپتی که توکن‌ها را ذخیره کرده بودند، پاک خواهند شد. اما در مثال Angular آن بحث ذخیره سازی در local storage پیاده سازی شده‌است و خیلی جزئیات دیگر.

هستند یکسری پروژه‌ی افزونه پذیر برای ASP.NET Core که این مفاهیم را پیاده سازی کرده‌اند (و وابستگی به StructureMap هم ندارند):

Accord.NET در حقیقت یک توسعه ای برای AForge.NET است. و چنانچه می‌خواهید از آکورد استفاده کنید بایستی ابتدا AForge.NET نصب نمایید.
AForge.NET یک کتابخانه بسیار عالی است اما در هر کدام از فضای نام هایش نقص هایی وجود دارد که در آکورد دات نت به آن افزوده شده است؛ به عنوان مثال در درختواره فضای نام MachineLearning مستندات دو پروژه مشاهده می‌کنیم که بسیاری از مفاهیم یادگیری ماشین از جمله : دسته بند نیو بیز، بوستینگ، بگینگ، درخت تصمیم، انواع مختلف اعتبارسنجی‌ها و ... در Accord.NET گنجانده شده است.

- هیچ الزامی ندارد که ساختار serialization مورد نیاز jstree، با ساختار جدول بانک اطلاعاتی شما یکی باشد.
- جدولی را که طراحی کردید، صرفا با JsTreeOperationData تطابق دارد.
- این جدول اصول شیء‌گرایی مدل‌های خود ارجاع دهنده را لحاظ نکرده‌است و صرفا یک ساختار ساده‌ی دریافت اطلاعات از کاربر هست و نه بیشتر.
- اگر قرار است با این نوع جداول و کلاس‌های غیر شیءگرا کار کنید، نیاز است SQL خام بنویسید و از مفاهیم CTE استفاده کنید.

نتیجه گیری؟
مدل خودتان را با مدلی که در مقاله‌ی مدل‌های خود ارجاع دهنده عنوان شده، تطبیق دهید تا بتوانید از قابلیت‌های شیء‌گرای EF استفاده کنید.

این سوال خوبی است. اما گمان نمی‌کنم بشود پاسخ دقیقی به بخش کدام مناسب‌تر است به طور کلی داد. شاید بتوانید بر اساس علاقه به MVC یا MVVM یکی را برگزینید. برای کسانی هم که می‌خواهند یکی را شروع کنند شاید Knockout برای شروع با توجه به داکیومنت و بخش آموزش جالب آن بهتر باشد. همچنین مقایسه هایی مانند این یا بحث هایی مانند این کمک کننده است برای انتخاب بین این فریم ورک ها. البته هر دو فریم ورک مدرن و مناسب برای بسیاری موارد هستند. نظر شخصی من این است اگر ASP.NET MVC کار می‌کنید Angular را به صورت راه حل کلی دنبال کنید چون کمی کسب مهارت و آشنایی با تمام مفاهیم آن نسبت به Knockout بیشتر طول می‌کشد. و زمانی که صرف یافتن گزینه بهتر بین این دو می‌کنید را برای مطالعه  Knockout با استفاده از مقالات همین سایت یا بخش آموزش سایت رسمی آن اختصاص دهید. گمان نمی‌کنم از صرف وقت برای این دو پشیمان شوید. هر کدام شیرینی خاص خود را دارند.

با تشکر از نویسنده مقاله و اهتمام ایشان به بررسی دقیق مفاهیم ،
 از آنجا که flexible و  reusable  بودن برنامه‌ها را نمی‌توان نادیده گرفت تا آنجا که این تفکیک پذیری خود به مسئله ای بغرنج تبدیل نشده و تکرر داده‌ها و پاس دادن غیر ضرور آنها را موجب نشود تلاش در این باره مفید خواهد بود .
امروزه توسعه دهنده گان به سمت کم کردن لایه‌های فرسایشی و حذف پیچیدگی‌های غیر ضرور قدم بر می‌دارند.  خلق عبارات لامبادا در دات نت و delegate   ها  نمونه هایی از تلاش بشر برنامه نویس در این باره است .

سلام و ممنون از نظر شما.
اتفاق جالبی افتاد و آن این بود که هم اکنون داشتم در OneNote بخشی برای مطلب بعدی می‌نوشتم. دقیقاً داشتم پاراگرافی را می‌نوشتم که جلوی این که ذهن خواننده به سمتی برود که گویی "الزاماً هر مورد در مهندسی نرم افزار را باید پس از یافتن مصداق آن در محیط اطراف یاد گرفت" را بگیرم.
دقیقاً صحیح است. تاکید بر این تناظر در این بخش به دلیل یافتن درک عمیق‌تر از شیء گرایی و علت مفید بودن آن و چگونگی شکل گیری ایده آن است. این درک عمیق‌تر امکان استفاده بهتر و صحیح‌تر این مفاهیم در برنامه را فراهم می‌کند. و سبب می‌شود برنامه نویس شیءگرایی را ابزاری برای حل مسئله بیاد نه راه و روشی که همه میگن خوبه پس باید رعایت کرد. حال آنکه چون درک دقیقی از آن ندارد در حقیقت مسئله را با آن روشی که بهتر بلد است حل می‌کنند و فقط تعدادی کلاس و شیء در برنامه وجود دارد.