仅几条(非常有用)注释

Just a few (hopefully useful) comments

这种方法非常简单，仅适用于非常简单的应用程序(可能还有codeproject演示).为什么不好?

This approach is very simplistic and good for only very simple apps (and maybe codeproject demos). Why is it bad ?

服务器呈现的Razor视图中的
1. Vue.js代码(在这种情况下为模板).由于几个原因，这是一个非常糟糕的主意，维护对我来说是最重要的.这也很难调试-您需要重新编译并重新启动Core应用程序才能查看更改的结果(这会使SPA重新加载并释放状态)，没有源映射，没有热重新加载
2. Vue模板(看起来像HTML，但实际上已转换为 JavaScript代码生成虚拟DOM )是在运行时而不是在构建时编译的.这不仅使您的应用程序1st渲染花费更长的时间，而且迫使您使用包含模板编译器的Vue构建，从而增加了加载页面时需要下载和解析的Javascript浏览器的数量
3. 您的VueJS(Javascript)代码没有被最小化，您不使用翻译(Babel)或代码拆分(

1. Vue.js code (template in this case) in server rendered Razor view. This is very bad idea for a few reasons, maintenance being most important for me. Its also hard to debug - you need to recompile and restart your Core app to see the result of your change (which make your SPA to reload and loose a state), there are no source maps, no hot reloading
2. Vue template (which looks like HTML but in reality it's converted into JavaScript code generating Virtual DOM) is compiled at runtime instead of at build time. This not only makes your app 1st render take longer but also forces you to use Vue build with template compiler included thus increasing amount of Javascript browser needs to download and parse when loading the page
3. Your VueJS (Javascript) code is not minimized, you don't use transpilation (Babel) or code splitting (Async Components) or Vue single file components
4. Simply you don't have the power of Webpack and Vue CLI

选项3

使用npm/webpack/babel/eslint的方式更好，但是建议创建自己的配置.主要论点是

Option 3

Is better in the way it is using npm/webpack/babel/eslint but it recommends creating your own configs. Main argument being

JavaScript框架和库有一种依赖脚手架工具来设置和配置应用程序的趋势.虽然这样做确实可以使您更快地启动并运行，但同时也使您无法理解设置，并且常常使配置变得configuration肿.

There is a tendency for JavaScript frameworks and libraries to rely on scaffolding tools for setup and configuration of an application. While this does get you up and running more quickly, it also alleviates you of understanding the settings and often leaves you with a bloated configuration.

当只有Vue CLI 2.x从模板生成您的项目时，并且在初始生成后，维护配置的负担(连同更新许多 npm软件包用于构建时间)完全由开发人员负责.Vue CLI 3.x极大地改变了这一点-它不仅可以生成初始应用程序，还可以为您管理所有工具配置.

This was valid argument back when there was only Vue CLI 2.x which generated your project from a template and after initial generation the burden to maintain the configuration (together with updating many npm packages used at build time) was solely on developer. Vue CLI 3.x changed that dramatically - it not only generates initial app but also manages all the tooling configuration for you.

本文正确的一件事是将Vue应用程序(SPA)与服务器分开(ASP.NET此处仅用于提供静态文件)

One thing the article does right is keeping Vue app (SPA) separate from server (ASP.NET is here only to serve static files)

1. 单独的SPA和服务器-为SPA使用Vue CLI(只需在Core应用中创建子文件夹并在其中生成).仅使用Core来实施API SPA将会使用(可能还有一些Error后备路线).
2. 对于开发，您可以将VS设置为同时为Core Dev服务器和CLI开发服务器提供午餐，以及从SPA到Core dev服务器的代理API请求.灵感此处.这样，您无需重新启动SPA即可更改API，反之亦然...
3. 我强烈建议将Visual Studio Code用于SPA开发.与完整的VS(及其免费版本)相比，它与Vetur扩展一起提供了优越的Vue开发体验.
4. 对于生产而言，将Vue CLI构建命令合并到Core项目构建过程中并不困难

1. Separate SPA and server - use Vue CLI for your SPA (just make subfolder in your Core app and generate there). Use Core just to implement API SPA will be using (and maybe some Error fallback route).
2. For development you can setup VS to lunch both Core Dev server and CLI dev server and proxy API requests from your SPA to Core dev server. Inspiration here and here. That way you can change your API without restarting SPA and vice versa...
3. I highly recommend using Visual Studio Code for your SPA development. Together with Vetur extension it provides far superior Vue development experience compared to full VS (and its free!)
4. For production, its not hard to incorporate Vue CLI build command into Core project build process

要考虑

考虑服务器端渲染(s-s-r).对于许多类型的网站来说，这都是很麻烦的事情，而且在不使用Node作为服务器的情况下很难做到这一点

To consider

Think about Server side rendering (s-s-r). It's deal breaker for many types of sites and its very hard without using Node as your server