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<Startup>()
                .Build();

我的認爲這段代碼很坑，這是一個函數的簡寫，但又沒起到簡寫的做用，還容易擾亂初學者，因此咱們作一下修改，以下：

public static void Main(string[] args)
{
    BuildWebHost(args).Run();
}
public static IWebHost BuildWebHost(string[] args)
{
    return WebHost.CreateDefaultBuilder(args)
        .UseStartup<Startup>()
        .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，雙擊進入，發現代碼以下：

@{
    Layout = "_Layout";
}

能夠看到，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文件尋找線索。

我發現，該文件的前兩行內容以下：

@page
@model IndexModel

這是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

----------------------------------------------------------------------------------------------------

注：此文章爲原創，歡迎轉載，請在文章頁面明顯位置給出此文連接！
若您以爲這篇文章還不錯，請點擊下方的【推薦】，很是感謝！