Asp.Net Core Web應用程式—探索

前言

作為一個Windows系統下的開發者，我對於Core的使用機會幾乎為0，但是考慮到微軟的戰略規劃，我覺得，Core還是有先瞭解起來的必要。

因為，目前微軟已經搞出了兩個框架了，一個是Net標準(.NetFramework)，一個是Net Core。

而新特性的更新幾乎都是在Net Core這個框架中。

所以，考慮到未來，一旦Core完善了，那微軟肯定會放棄現在的.NetFrameWork。

因此，.Net程式員集體改用Net Core，想來，一定是大趨勢。

所以讓我們懷著探索的精神來看看Asp.Net Core Web應用程式吧。

建立Asp.Net Core專案

首先，我們先來建立一個Asp.Net Core Web應用程式專案，然後一起探索。

開啟Visual Studio建立專案，選擇Asp.Net Core Web應用程式，如下圖：

然後選擇Asp.Net Core Web應用程如下圖：

然後我們得到了這樣一個佈局的專案，如下圖：

可以看到，專案中有四個檔案和兩個檔案夾（Page、wwwroot）。

其中wwwroot檔案夾很特別，圖示和其他的檔案夾不一樣，不過依然可以修改他的名稱，修改名稱後，檔案夾圖示會變回普通的圖示，不過既然是特殊圖示，想來一定有特殊意義，我們稍後再研究，先接著向下瀏覽Page檔案夾。

Page檔案夾展開後，發現裡面有很多頁面，因此，很明顯，它就是儲存頁面的地方了，頁面內容我們稍後再看，現在，我們先看看專案最外面的四個檔案。

Program.cs

看到這個檔案我也很奇怪，Web是依賴IIS部署，AspNet中是沒有Program的，那麼Core中為什麼多出了個Program檔案呢？我們調查一下。

原來AspNetCore有一個自帶的伺服器，叫做Kestrel 。

什麼是自帶伺服器呢？就好比我們建立了一個WCF服務，但又不想掛IIS上，就自己建一個ServiceHost來掛服務。

但Kestrel 明顯更高階，它還支援與反向代理伺服器（如 Internet Information Services (IIS)、Nginx 或 Apache）結合使用。

什麼是【反向代理伺服器】呢？就是由與IIS類似的伺服器，先接收來自網路的 HTTP 請求，然後再將這些請求轉發到 Kestrel，最後由Kestrel來實現呼叫，呼叫流程如下圖所示。

調查到這裡，我做大致可以猜出了Program.cs是乾什麼的了——它應該是用來啟動Kestrel 這個伺服器的。

現在我開啟Program.cs，發現如下程式碼。

public static IWebHost BuildWebHost(string[] args) =>            WebHost.CreateDefaultBuilder(args)                .UseStartup()                .Build();

個人認為這段程式碼很坑，這是一個函式的簡寫，但又沒起到簡寫的作用，還容易擾亂初學者，所以我們做一下修改，如下：

public static void Main(string[] args) {     BuildWebHost(args).Run(); } public static IWebHost BuildWebHost(string[] args) {     return WebHost.CreateDefaultBuilder(args)         .UseStartup()         .Build(); }

看修改後程式碼，我們就很明確了，Main函式啟動，呼叫BuildWebHost函式，故名思意，這是一個建立網站伺服器的函式，傳回值是IWebHost。

然後，我們看到了，在Main函式使用BuildWebHost函式傳回的IWebHost的實體，執行其下的Run方法。

到此，已經很明確了，Program就是啟動伺服器用的。

Startup.cs

這個檔案我們相對比較熟悉，它是專案啟動時便會呼叫的檔案，功能有很多，下麵看下系統為我們生成的程式碼。

public class Startup {     public Startup(IConfiguration configuration)     {         Configuration = configuration;     }     public IConfiguration Configuration { get; }     public void ConfigureServices(IServiceCollection services)     {         services.AddMvc();     }     public void Configure(IApplicationBuilder app, IHostingEnvironment env)     {         if (env.IsDevelopment())         {             app.UseBrowserLink();             app.UseDeveloperExceptionPage();         }         else         {             app.UseExceptionHandler("/Error");         }         app.UseStaticFiles();         app.UseMvc();     } }

我們看到了三個函式，現在，我們簡單的為三個函式打一下斷點，啟動一下網站。

很簡單的得出，三個函式的執行順序是Startup——>ConfigureServices——>Configure。

建構式是簡單的賦值，我們跳過它，來看ConfigureServices。

可以看到ConfigureServices裡只呼叫了services.AddMvc()，檢視官方介紹，原來這個方法是將Mvc服務新增到指定的服務集合中。

透過除錯，發現ConfigureServices函式的services.AddMvc()與Configure函式app.UseMvc()是成對的，即當我們把MVC服務新增到服務集合中，才能在後續的Configure方法裡使用Mvc服務。

那麼我們建立的是Web應用，為什麼要新增Mvc服務呢？我們吧Mvc服務刪除一下看看效果吧。

刪除了Mvc服務後，我們會發現，網站啟動起來了，但是並沒有正常訪問我們的主頁。

重新添加回Mvc服務，我們再啟動網站，檢視下網站連結路徑如下：

http://localhost:1234/Index

http://localhost:1234/About

可以發現，這些路徑是Mvc樣式的路徑，也就是說，Asp.Net Core Web應用程式也是用Mvc路由訪問網址，所以，Mvc的服務是必須新增的。

Configure中，我們看到還使用了其他IApplicationBuilder的方法，不過這些方法我們即便註釋掉，也不影響網站啟動，所以我們暫時忽略他們，等用到在學習吧。

bundleconfig.json

故名思意，捆配置檔案，感覺和mvc的BundleConfig.cs檔案很像，開啟看一下，可以確定了，就是mvc的捆配置檔案。那也就是說，這個是沒什麼用的檔案，因為大多數情況，我們不會進行捆配置。

appsettings.json

依然故名思意，應該是應用設定檔案，這個名字很像，webconfig裡的AppSetting節點，所以推斷，它應該是個配置專案固定值的檔案。

百度一下appsettings.json，發現有很多都是如何讀取該檔案內容的文章，那麼，現在可以確定了，它就是個變數配置檔案。

—————————————————————————————————-

檔案講解完了，下麵我們來看檔案夾裡的內容。

wwwroot

上門介紹過了，wwwroot是一個有特殊標記的檔案夾。

開啟wwwroot，我們會發現裡面儲存的是樣式和圖片。執行網站，在網站裡檢視下這些圖片，會發現圖片地址都很奇怪。

圖片路徑是/wwwroot/images/banner1.svg，但訪問起來，卻是http://localhost:1234/images/banner1.svg。

也就是說，wwwroot路徑會被省略，換一種說話，wwwroot會被放到網站根目錄下。

我們在做個實驗，新建個檔案夾儲存一些圖片，執行網站訪問，我們會發現，根本無法訪問這些圖片。

那麼，我們可以得出結論了，wwwroot是Asp.Net Core Web應用程式唯一可以訪問的資源檔案夾。

Pages

開啟Page檔案夾，我們可以看到4個可以展開的cshtml和4個不能展開的cshtml檔案。

開啟我們最眼熟的_ViewStart.cshtml，雙擊進入，發現程式碼如下：

可以看到，ViewStart程式碼和MVC的ViewStart一樣，那也就是說，這是個配置佈局的檔案了。

那麼相對應的_Layout.cshtml我們也可以確定了，它就是個佈局檔案，那麼，剩下兩個cshtml檔案，我們也可以推斷出了，他們也是配置檔案或者佈局檔案。

下麵我們來看那4個可以展開的cshtml檔案。

首先我們展開Index.cshtml檔案，如下圖：

接著，我們雙擊Index.cshtml檔案，發現裡面就是普通的html+razor標記。

然後，我們再雙擊Index.cshtml.cs檔案檢視內容，得到程式碼如下：

public class IndexModel : PageModel {     public void OnGet()     {     } }

透過專案結構我們可以判斷，Index.cshtml.cs是Index.cshtml的一個後臺檔案。

但檢視程式碼，卻發現裡面的類是個繼承PageModel類的IndexModel，那它到底和Index.cshtml檔案有什麼關係呢？

我們先透過命名推測，IndexModel中包含Model關鍵字，所以他應該是與Index.cshtml檔案有關的Model。

與Index.cshtml檔案有關的Model？那不就是ViewModel了嗎！！！

現在我們再回頭仔細的看下Index.cshtml檔案尋找線索。

我發現，該檔案的前兩行內容如下：

這是Mvc傳遞頁面物體的寫法，即IndexModel確實是Index.cshtml的物體。

那麼，我們上面的推測就被證實了，Index.cshtml.cs檔案就是Index.cshtml檔案的ViewModel。

但Onget是什麼呢？

我們依然透過命名推測，我推測它就是以前AspNet的PageLoad（頁面匯入時觸發的函式）？

下麵我們測試一下，修改程式碼如下：

public string title; public void OnGet() {     title = this.Request.Query["title"];     if (!string.IsNullOrWhiteSpace(title))     {         ViewData["Title"] = title;     } }

然後斷點Onget方法。

接著我們訪問http://localhost:1234/index?title=kiba網址。

結果，我們的斷點被命中了，標題也順利設定成功。因此，我們的推測又成功了，OnGet就是我們之前的PageLoad方法。

結語

綜上所述，我們對Asp.Net Core Web應用程式已經有了一定的瞭解，然後我得出了這樣一個結論：

[Asp.Net Core Web應用程式]在設計上，採用的了MVVM的設計理念（cshtml.cs檔案就是我們[服務端]頁面的ViewModel了），請求網址使用了Mvc的路徑訪問技術，整體上是一個更優秀的AspNet框架。

PS：喜歡MVVM的朋友有福音了：）。

—————————————————————————————————-

到此Asp.Net Core Web應用程式探索就結束了。

程式碼已經傳到Github上了，歡迎大家下載。

Github地址：https://github.com/kiba518/KibaAspNetCore

原文地址：https://www.cnblogs.com/kiba/p/10722574.html