赶着潮流听着歌，学着.net玩着Core
竹子学Core，目前主要看老A（http://www.cnblogs.com/artech/）和tom大叔的博客（/），当然还有我们博客园的Core中国学习小组啦（/），只是笔记作用，所以很多图片，文字都是来源于他们~
中间件（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。现在想来，这是个必要的步骤。