Day 3 ASP.NET Core生命週期

第 12 屆 iThome 鐵人賽

DAY 3

Modern Web

ASP.NET Core 入門實戰30天系列第 3 篇

12th鐵人賽 .net core 3.0

Zarekchung

團隊Outcome First

2020-09-16 12:18:46

3801 瀏覽

分享至

本篇重點

.NET Core CLi
.NET Core 的專案目錄結構
.NTE Core 生命週期

前言

上一篇概略性的提到 .NET Core的差異還有列出幾個類型的開發專案方式
以及簡單的示範個專案Hello World

今天來整理一下 .NET Core之後所支援的Cli, 並利用Cli 建立一個MVC專案, 以及了解整個生命週期

.NET CLI

CLI介紹

熟悉前端框架的朋友一定對CLI不陌生
Command-line Interface ：就是用Command-linen所設計的一個介面,可以讓使用者透過鍵盤輸入這些指令去執行以往需要用到滑鼠或是IDE裡面去執行的事情,並透過CLI可以建立一個現有的範本專案,並將相關需要的library一次載入,增加開發效率

來到2020的.NET也為了 .NET Core推出支援的CLI,在操作上又更加的方便,以下就會示範如何在Mac上使用 .NET CLI去建置一個MVC的專案

使用 cli建立一個MVC專案

.NET Cli 在安裝VS2019 for Mac 時就已經包含在 .NET Core裡面了
所以如果是使用VSCode的朋友,必需要安裝 .NET Core SDK才有辦法開發 .NET Core(已經包含Cli)

以下是使用Cli建立一個叫做DotnetMvc 專案的指令

Dotnet new mvc -n DotnetMvc 
//mvc為固定的專案範本名稱,註1
//-n 表示專案的名稱,也可以手動建立folder可直接省略這段

Dotnet build 

Dotnet run

在這裡筆者心裡有兩個疑問

cli有沒有可以同時build+run的指令
執行完Dotnet run 不會開啟預設瀏覽器

但目前看起來官網是沒有提供的這些功能,建議還是配合IDE使用會比較方便

註1.
關於專案類型的指令,可以參考官網說明

其他指令

使用Cli主要是可以透過指令快速的建立及執行處理專案的動作
目前微軟還是陸續在更新相關的指令,都可以在官網上找到更新的文件
(我想微軟最大的好處就是文件更新的算快了,也有一個龐大的資料庫在那邊)
詳細的Cli指令請點我

.NET Core 目錄結構

第一眼看到 .NET Core專案覺得差異最大的就是專案沒有web.config
取而代之的是appsettings.json,這邊針對幾個設定檔去做整理

appsettings.json

.net Core將以往的web.config拿掉,不再使用舊有的xml格式
組態設定改用json格式為基準

先來看一下以cli所建立的專案
預設的appsettings.json如下

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information"
    }
  },
  "AllowedHosts": "*"
}

Logging - 主要用來管理log的設定(再後面的章節會在整理loggin的部分)
AllowedHosts - 可以用來當作filiter,限制是request的URL必須符合特定字串
舉例來說,專案預設都會是*,表示沒有限制,如果將下列改成

 "AllowedHosts": "example.com"

啟動專案則會顯示400 Bad Request.

其中設定是可以用分號隔開的,如果新增一組localhost,是符合規定的
頁面則會成功顯示

"AllowedHosts": "example.com;localhost"

此外包含設定DB的connect string、config參數,也是在這裡新增
.NET Core 因為不再使用config的組態設定,意味者ConfigurationManager已經不能再使用了,必須透過DI的方式去管理
如何切換正式/測試環境設定
- 使用cli建立的mvc專案,除了appsettings.json,另一個是appsettings_appsettings.Development.json,這支檔案依附在appsettings.json的下方,讀取時都會一起讀取,如果要區分開發環境及正式環境,參數兩邊都要設定
- 使用cli執行,沒有特別設定在launchSettings,預設會是抓最上層的appsettings.json的設定,也就是production
- 在使用cli時同時也會建立下方的設定到launchSettings.json,執行時會去認commandName為project的參數,去決定只讀取哪一個設定檔

launchSettings.json

這個設定檔不是必要的檔案,只有在開發環境時才會需要使用到,部署到正式環境時並不需要這個設定,根據所使用的server去做相關的環境設定

.NET Core 生命週期

Program.cs 一切都從Main開始

.NET Core 調整了進入程式的起始點,不使用繼承方式而改用DI的方式注入,坦白說一開始看到還覺得很像console app,但整體程式碼個人覺得較簡潔

在所有介紹 .NET Core的文章都可能會有這一段程式碼
也就是整個應用程式的進入點
先來看看這一行程式碼

 CreateHostBuilder(args).Build().Run();

透過CreateHostBuilder()回傳的物件去實作IHostBuilder這個介面,去執行Build()和Run()的方法

接下來在CreateHostBuilder()裡面會去執行ConfigureWebHostDefaults,主要是去建立及初始化一個HostBuilder的實體,接下來透過UseStartup()方法去執行相關的類別,在這裡就是去執行Startup.cs這支程式

  Host.CreateDefaultBuilder(args)
                .ConfigureWebHostDefaults(webBuilder =>
                {
                    webBuilder.UseStartup<Startup>();
                });

Startup.cs

分成以下兩部分

ConfigureServices
透過Dependency Injection的方式,註冊相關的服務
比較一下個專案範本所使用的服務也不同
例如Razor pages專案裡所使用的服務就跟MVC下圖的不相同
Configure
在這個方法裡面,透過IApplicationBuilder使用pipeline的方式去將這些middleware components執行,不論事Razor pages或是MVC,初始所設定的middleware都相同,只差在最後UseEndpoint會針對特性去做調整

整個Configure直執行的順序如下,接下來也會針對Middleware去做整理,通常客製化的Middleware都會放在Endpoint前

(圖片來源：https://docs.microsoft.com/)