Merge pull request #10469 from abpframework/auto-merge/rel-4-4/608

Merge branch rel-5.0 with rel-4.4

docs/en/CLI-New-Command-Samples.md

@@ -1,4 +1,4 @@
-# ABP CLI Create Solution Sample Commands 
+# ABP CLI - New Solution Sample Commands 
 
 The `abp new` command creates an ABP solution or other artifacts based on an ABP template. [ABP CLI](CLI.md) has several parameters to create a new ABP solution. In this document we will show you some sample commands to create a new solution. All the project names are `Acme.BookStore`. Currently, the only available mobile project is a `React Native` mobile app. Available database providers are `Entity Framework Core` and `MongoDB`. All the commands starts with `abp new`.
 
@@ -87,6 +87,28 @@ The following commands are for creating Blazor projects:
   abp new Acme.BookStore -u blazor --database-provider mongodb --mobile none -csf
   ```
 
+## Blazor Server
+
+The following commands are for creating Blazor projects:
+
+* **Entity Framework Core**, no mobile app:
+
+  ```bash
+  abp new Acme.BookStore -t app -u blazor-server --mobile none
+  ```
+
+* **Entity Framework Core**, **separate Identity Server**, **separate API Host**, mobile app included:
+  
+  ```bash
+  abp new Acme.BookStore -u blazor-server --tiered
+  ```
+
+* **MongoDB**, no mobile app, creates the project in a new folder:
+
+  ```bash
+  abp new Acme.BookStore -u blazor --database-provider mongodb --mobile none -csf
+  ```
+  
 ## No UI 
 
 In the default app template, there is always a frontend project. In this option there is no frontend project. It has a `HttpApi.Host` project to serve your HTTP WebAPIs. It's appropriate if you want to create a WebAPI service.
@@ -101,6 +123,8 @@ In the default app template, there is always a frontend project. In this option
     ```bash
     abp new Acme.BookStore -u none --mobile none --database-provider mongodb
     ```
+    
+
 
 ## Console application
 

docs/en/CLI.md

@@ -89,12 +89,14 @@ For more samples, go to [ABP CLI Create Solution Samples](CLI-New-Command-Sample
     * `--ui` or `-u`: Specifies the UI framework. Default framework is `mvc`. Available frameworks:
       * `mvc`: ASP.NET Core MVC. There are some additional options for this template:
         * `--tiered`: Creates a tiered solution where Web and Http API layers are physically separated. If not specified, it creates a layered solution which is less complex and suitable for most scenarios.
-      * `angular`: Angular. There are some additional options for this template:
-        * `--separate-identity-server`: Separates the identity server application from the API host application. If not specified, you will have a single endpoint in the server side.
-      * `blazor`: Blazor. There are some additional options for this template:
-        * `--separate-identity-server`: Separates the identity server application from the API host application. If not specified, you will have a single endpoint in the server side.
-      * `none`: Without UI. There are some additional options for this template:
-        * `--separate-identity-server`: Separates the identity server application from the API host application. If not specified, you will have a single endpoint in the server side.
+      * `angular`: Angular UI. There are some additional options for this template:
+        * `--separate-identity-server`: The Identity Server project comes as a separate project and runs at a different endpoint. It separates the Identity Server from the API Host application. If not specified, you will have a single endpoint in the server side.
+      * `blazor`: Blazor UI. There are some additional options for this template:
+        * `--separate-identity-server`The Identity Server project comes as a separate project and runs at a different endpoint. It separates the Identity Server from the API Host application. If not specified, you will have a single endpoint in the server side.
+      * `blazor-server`: Blazor Server UI. There are some additional options for this template:
+        * `--tiered`: The Identity Server and the API Host project comes as separate projects and run at different endpoints. It has 3 startup projects: *HttpApi.Host*, *IdentityServer* and *Blazor* and and each runs on different endpoints. If not specified, you will have a single endpoint for your web project.
+      * `none`: Without UI. No front-end layer will be created. There are some additional options for this template:
+        * `--separate-identity-server`: The Identity Server project comes as a separate project and runs at a different endpoint. It separates the Identity Server from the API Host application. If not specified, you will have a single endpoint in the server side.
     * `--mobile` or `-m`: Specifies the mobile application framework. If not specified, no mobile application will be created. Available options:
       * `react-native`: React Native.
     * `--database-provider` or `-d`: Specifies the database provider. Default provider is `ef`. Available providers:

docs/en/UI/AspNetCore/Client-Side-Package-Management.md

@@ -13,7 +13,7 @@ ABP is a modular platform. Every developer can create modules and the modules sh
 
 One challenge is the **versions of the dependant NPM packages**. What if two different modules use the same JavaScript library but its different (and potentially incompatible) versions.
 
-To solve the versioning problem, we created a **standard set of packages** those depends on some common third-party libraries. Some example packages are [@abp/jquery](https://www.npmjs.com/package/@abp/jquery), [@abp/bootstrap](https://www.npmjs.com/package/@abp/bootstrap) and [@abp/font-awesome](https://www.npmjs.com/package/@abp/font-awesome). You can see the **list of packages** from the [Github repository](https://github.com/volosoft/abp/tree/master/npm/packs).
+To solve the versioning problem, we created a **standard set of packages** those depends on some common third-party libraries. Some example packages are [@abp/jquery](https://www.npmjs.com/package/@abp/jquery), [@abp/bootstrap](https://www.npmjs.com/package/@abp/bootstrap) and [@abp/font-awesome](https://www.npmjs.com/package/@abp/font-awesome). You can see the **list of packages** from the [GitHub repository](https://github.com/volosoft/abp/tree/master/npm/packs).
 
 The benefit of a **standard package** is:
 
@@ -22,14 +22,14 @@ The benefit of a **standard package** is:
 
 Depending on a standard package is easy. Just add it to your **package.json** file like you normally do. Example:
 
-````
+```json
 {
   ...
   "dependencies": {
     "@abp/bootstrap": "^1.0.0"
   }
 }
-````
+```
 
 It's suggested to depend on a standard package instead of directly depending on a third-party package.
 
@@ -37,9 +37,9 @@ It's suggested to depend on a standard package instead of directly depending on
 
 After depending on a NPM package, all you should do is to run the **yarn** command from the command line to install all the packages and their dependencies:
 
-````
+```bash
 yarn
-````
+```
 
 Alternatively, you can use `npm install` but [Yarn](https://classic.yarnpkg.com/) is suggested as mentioned before.
 
@@ -69,7 +69,7 @@ The **startup templates** are already configured to work all these out of the bo
 
 A module should define a JavaScript file named `abp.resourcemapping.js` which is formatted as in the example below:
 
-````js
+```json
 module.exports = {
     aliases: {
         "@node_modules": "./node_modules",
@@ -83,7 +83,7 @@ module.exports = {
         
     }
 }
-````
+```
 
 * **aliases** section defines standard aliases (placeholders) that can be used in the mapping paths. **@node_modules** and **@libs** are required (by the standard packages), you can define your own aliases to reduce duplication.
 * **clean** section is a list of folders to clean before copying the files. Glob matching and negation is enabled, so you can fine-tune what to delete and keep. The example above will clean everything inside `./wwwroot/libs`, but keep any `foo.txt` files.
@@ -91,14 +91,14 @@ module.exports = {
 
 An example mapping configuration is shown below:
 
-````js
+```json
 mappings: {
     "@node_modules/bootstrap/dist/css/bootstrap.css": "@libs/bootstrap/css/",
     "@node_modules/bootstrap/dist/js/bootstrap.bundle.js": "@libs/bootstrap/js/",
     "@node_modules/bootstrap-datepicker/dist/locales/*.*": "@libs/bootstrap-datepicker/locales/",
     "@node_modules/bootstrap-v4-rtl/dist/**/*": "@libs/bootstrap-v4-rtl/dist/"
 }
-````
+```
 
 #### install-libs Command
 

docs/zh-Hans/Domain-Driven-Design-Implementation-Guide.md

@@ -1771,15 +1771,15 @@ public async Task ChangeTitleAsync(Issue issue, string title)
 
 领域逻辑是系统的*核心领域规则*组成,而应用逻辑则满足特定的*用例*.
 
-虽然定义很明确,但是实施起来缺并不容器.你可能无法确定哪些代码应该属于领域层,哪些代码应该属于应用层,本节会尝试解释差异.
+虽然定义很明确,但是实施起来却并不容易.你可能无法确定哪些代码应该属于领域层,哪些代码应该属于应用层,本节会尝试解释差异.
 
 ### 多应用层
 
 当你的系统很大时,DDD有助于**处理复杂问题**.尤其是,**单个领域**需要多个**应用程序运行**,那么**领域逻辑与应用逻辑分离**就变的非常重要.
 
-假设你正字构建一个具有多个应用程序的系统:
+假设你正在构建一个具有多个应用程序的系统:
 
-* 一个**公开的应用网站**,使用ASP.NET Core MVC构建,展示商品给来访者.这样的网站不选哟身份验证即可查看商品.来访者只有执行了某些操作(例如,将商品添加到购物车)后,才需要登录网站.
+* 一个**公开的应用网站**,使用ASP.NET Core MVC构建,展示商品给来访者.这样的网站不需要身份验证即可查看商品.来访者只有执行了某些操作(例如,将商品添加到购物车)后,才需要登录网站.
 * 一个**后台管理系统**,UI使用Angular,通过REST API请求数据.内部员工使用这个系统来维护数据(例如,编辑商品说明).
 * 一个**移动端应用程序**,它比公开的网站UI上更加简洁.它通过REST API或其它技术(例如,TCP sockets)请求数据.
 
@@ -1787,7 +1787,7 @@ public async Task ChangeTitleAsync(Issue issue, string title)
 
 每个应用程序都有不同的**需求**,不同的**用例**(应用服务方法),不同的DTO,不同的**验证**和**授权**规则等.
 
-将所有这些逻辑都集中到一个应用层中,会使你的服务包含太多的`if`条件分支及**复杂的业务逻辑**,从而使你的代码难道开发,**维护**,测试,引发各种问题.
+将所有这些逻辑都集中到一个应用层中,会使你的服务包含太多的`if`条件分支及**复杂的业务逻辑**,从而使你的代码开发,**维护**,测试,引发各种问题.
 
 如果你在一个领域中有多个应用程序