ASP.NET Core學習零散記錄

趕着潮流聽着歌，學着.net玩着Core

 竹子學Core，目前主要看老A（http://www.cnblogs.com/artech/）和tom大叔的博客（http://www.cnblogs.com/TomXu/），固然還有咱們博客園的Core中國學習小組啦（http://www.cnblogs.com/dotNETCoreSG/），只是筆記做用，因此不少圖片，文字都是來源於他們~

中間件（middleware）：

　　原文：隨着WebHost的Start方法的調用，按照具體需求進行定製的請求處理管道被構建出來，做爲第一個節點的服務器會綁定到一個預設的端口（好比KestrelServer默認採用5000做爲監聽端口）開始監聽來自客戶端的HTTP請求。一旦請求抵達，服務器會接收請求並將其標準化後向管道後續的節點進行轉發，咱們將管道中位於服務器以後的請求處理節點成爲「中間件（Middleware）」。每一箇中間件都具備各自獨立的功能，好比咱們有專門實現路由功能的中間件，由專門實施用戶認證的中間，所謂的對請求處理管道的定製體如今根據具體的需求選擇對應的中間件組成最終處理請求的管道。左圖揭示了由一個服務器和一組中間件構成的請求處理管道。

　　

　　一個創建在ASP.NET Core之上的應用通常都是根據某個框架開發的，開發框架基本上是創建在某個特殊的中間件上。以ASP.NET Core MVC這個最著名的框架爲例，它其實是利用一個叫作 「路由」 的中間件實現了請求地址與Controller/Action之間的映射，並在此基礎實現了激活Controller、執行Action以及呈現View等一系列的功能。因此應用程序能夠視爲某個中間件的一部分，若是必定要將它獨立出來，整個請求處理管道將呈現出如右圖所示的結構。

這裏的一個ASP.NET Core MVC應用中咱們除了調用擴展方法UseMvc註冊了支撐MVC框架的中間件（其實是一個實現路由的中間件）以外，咱們還經過調用其它的擴展方法註冊了相應的中間件實現了對靜態文件的訪問（UseStaticFiles）、錯誤頁面的呈現（UseExceptionHandler）以及基於ASP.NET Identity Framework的認證（UseIdentity）。

   1: public class Startup
   2: {
   3:     public void Configure(IApplicationBuilder app)
   4:     {
   5:         app.UseExceptionHandler("/Home/Error");
   6:         app.UseStaticFiles();
   7:         app.UseIdentity();           
   8:  
   9:         app.UseMvc();
  10:     }
  11: }

 

ViewModel

最後，咱們其實應該跳出來，從架構的角度來思考這個問題。ViewModel到底是什麼？它說承載的職責應該是什麼？應該由誰來構建它？……

我認爲：ViewModel本質上就是一個用於頁面呈現的數據容器（DTO），因此他不該該具備任何內在邏輯，並且應該由前端開發人員來構建它。前端開發人員應該完全的擺脫業務層中的Entity的束縛，根據頁面的呈現規律，大膽的進行各類抽象組合，使得ViewModel真正的綻開它的光彩！——http://www.cnblogs.com/freeflying/p/5009663.html

跟我想的同樣，以前在MVC中也是在UI層創建一個Model，即上文提到的ViewModel。如今想來，這是個必要的步驟。