歡迎光臨
每天分享高質量文章

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

已同步到看一看
赞(0)

分享創造快樂