1. ASP.NET MVC 4框架：ASP.NET MVC上的Web應用
建立在 迷你版 ASP NET MVC上的Web應用
在正式介紹我們自己創建的 迷你版 ASP NET MVC的實現原理之前 不妨來看看建立在該框架之上的Web應用如何定義 通過Visual Studio創建一個空的ASP NET Web應用（注意不是ASP NET MVC應用）並不會引用System Web Mvc dll這個程序集 所以在接下來的程序中看到的所謂MVC的組件都是我們自行定義的
首先定義了如下一個SimpleModel類型 它表示最終需要綁定到View上的數據 為了驗證針對Controller和Action的解析機制 SimpleModel定義的兩個屬性分別表示當前請求的目標Controller和Action
public class SimpleModel
{
public string Controller { get; set; }
public string Action { get; set; }
}
與真正的ASP NET MVC應用開發一樣 我們需要定義Controller類 按照約定的命名方式（以字元 Controller 作為後綴） 我們定義了如下一個HomeController HomeController實現的抽象類型ControllerBase是我們自行定義的 以自定義的ActionResult作為返回類型的Index方法表示Controller的Action 它接受一個SimpleModel類型的對象作為參數 該Action方法返回的ActionResult是一個RawContextResult對象 顧名思義 RawContextResult就是將指定的內容進行原樣返回 在這里我們將作為參數的SimpleModel對象的Controller和Action屬性顯示出來
public class HomeController: ControllerBase
{
public ActionResult Index（SimpleModel model）
{
string content = string Format（ Controller: { }<br/>Action:{ }
model Controller model Action）
return new RawContentResult（content）
}
}
ASP NET MVC根據請求地址來解析出用於處理該請求的Controller的類型和Action方法名稱 具體來說 我們預注冊一些包含Controller和Action名稱作為佔位符的（相對）地址模板 如果請求地址符合相應地址模板的模式 Controller和Action名稱就可以正確地解析出來 和ASP NET MVC應用類似 我們在Global asax中注冊了如下一個地址讓脊模板（{controller}/{action}） 我們還注冊了一個用於創建Controller對象的工廠 RouteTable ControllerBuilder和DefaultControllerFactory都是我們自定義的類型
public class Global : System Web HttpApplication
{
protected void Application_Start（object sender EventArgs e）
{
RouteTable Routes Add（ default
new Route{Url = {controller}/{action} }）
ControllerBuilder Current SetControllerFactory（
new DefaultControllerFactory（））
}
}
正如上洞滑旅面所說的 ASP NET MVC是通過一個自定義的HttpMole實現的 在這個 迷你版 ASP NET MVC框架中我納凳們也將其起名為UrlRoutingMole 在運行Web應用之前 我們需要通過配置對該自定義HttpMole進行注冊 下面是相關的配置
<configuration>
<system webServer>
<moles>
<add name= UrlRoutingMole
type= WebApp UrlRoutingMole WebApp />
</moles>
</system webServer>
</configuration>
到目前為止 所有的編程和配置工作已經完成 為了讓定義在HomeController中的Action方法Index來處理針對該Web應用的訪問請求 我們需要指定與之匹配的地址（符合定義在注冊地址模板的URL模式） 如圖 所示 由於在瀏覽器中輸入地址（//…/Home/Index）正好對應著HomeController的Action方法Index 所以對應的方法會被執行 而執行的結果就是將當前請求的目標Controller和Action的名稱顯示出來 （S ）
圖 採用符合注冊的路由地址模板的地址訪問Web應用
上面演示了如何在我們自己創建的 迷你版 ASP NET MVC框架中創建一個Web應用 從中可以看到和創建一個真正的ASP NET MVC應用別無二致 接下來我們就來逐步地分析這個自定義的ASP NET MVC框架是如何建立起來的 而它也代表了真正的ASP NET MVC框架的工作原理
返回目錄 ASP NET MVC 框架揭秘
編輯推薦
ASP NET開發培訓視頻教程
Microsoft NET框架程序設計視頻教程
Java程序性能優化 讓你的Java程序更快 更穩定
Visual C++音頻/視頻技術開發與實戰
lishixin/Article/program/net/201311/16113
2. .net web api實例應該如何寫
由於我機器裝的是win8企業版操作系統，VS版本是2012，因此我們選擇使用VS自帶的MVC4模版中的Web API來創建一個項目。
點擊確定後，VS會自動為我們創建一個完整的可運行的ASP.NET Web API的項目。
從項目的目錄結構可以看出，ASP.NET Web API與ASP.NET MVC項目的結構幾乎一致。我們刪除為我們默認創建並打開的ValuesController文件（示例性文件，可以參考）。
既然要打造一個IP地址查詢服務介面，為了跟上文的服務形式一致，我們還是使用GET請求方式的服務，不過我們這次使用MVC中的Web API來實現。
首先在Models文件夾中建立一個Address模型類。
?
1
2
3
4
5
6
7
8
9
namespace MvcWebApi.Models
{
public class Address
{
public string IPAddress { get; set; }
public string Province { get; set; }
public string City { get; set; }
}
}
接著我們在Controllers文件夾下建立一個IPAddressController控制器，需要注意的是，這個IPAddressController一定要繼承自ApiController類，這樣服務才能暴露出來。
?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
namespace MvcWebApi.Controllers
{
public class IPAddressController : ApiController
{
private static IList addresses = new List
{
new Address(){ IPAddress="1.91.38.31", Province="北京市", City="北京市" },
new Address(){ IPAddress = "210.75.225.254", Province = "上海市", City = "上海市" },
};
public IEnumerable GetIPAddresses()
{
return addresses;
}
public Address GetIPAddressByIP(string IP)
{
return addresses.FirstOrDefault(x => x.IPAddress == IP);
}
}
}</address></address></address>
只要做上面兩步就可以運行這個項目了，我們按Ctrl+F5運行整個項目，出現了如下的頁面。
我們點擊右上角的API鏈接。
可以看到我們定義的Web API的介面的使用方法以及說明。
既然是服務，能夠被其它程序調用就需要一個持續保障它運行的環境，我們可以將這個寫好的Web API的項目發布到IIS當中。
我們可以使用VS自帶的發布功能進行發布，並映射到IIS應用程序目錄當中。
我們點擊IIS右側的瀏覽，看看服務有沒有能夠正常運行。
我們按照文檔的提示，我們在地址欄輸入http://192.168.0.2/webapi/api/ipaddress。
可以看到，我們收到了Web API定義的服務提供的數據。同樣的我們試一下另外一個介面方法。
OK，這樣就好了。
但是如果我們需要返回JSON格式怎麼辦呢？有個簡便的方法，在Global.asax.cs文件中，添加一個方法即可。
關於這段代碼的原因，可以參考：http://blog.miniasp.com/post/2012/10/12/ASPNET-Web-API-Force-return-JSON-format-instead-of-XML-for-Google-Chrome-Firefox-Safari.aspx，這里不重復。
我們運行這個項目後，重復發布。
當我們再次在瀏覽器中運行時，就可以看到默認返回的是JSON格式了（IE默認就是JSON）。
ASP.NET Web API就開發好了，至於在C#程序中怎麼調用，可以參考我上篇博客中的代碼。如果要在頁面中調用，可以通過jQuery等JS庫請求URL即可。
3. .net中MVC web項目和webapi有啥區別
首先要重點說的是，Web API是一種無限接近於RESTful風格的輕型框架，且不是微軟提出來的，微軟在.NET上實現了這中框架—http://Asp.Net
Web API，所以「微軟包裝」是一個極大的偏見。
就應用市場時間而論，MVC普及市場的時間比Web API時間早。為什麼MVC提出來了，且都被大家公認是一種經典的web站點實現架構，為什麼還要搞Web API呢？
這兩年什麼炒得最火熱？互聯網。在網路技術不斷更新和替代的過程，網路不斷普及。互聯網產品只要你有技術，就可以做。但要說明的是，互聯網產品的用戶不再是一小部分人群，除了潛在用戶，你需要面對的是龐大的上網人群和開發者。這時候你要考慮你的WEB伺服器是否能夠支持這么多的用戶，節省一點點傳輸數據的帶寬都能夠讓你的伺服器輕松不少，除此之外，你還要考慮你的潛在用戶變成你的真實用戶的某刻時刻，你的伺服器是否能夠順利支撐。
面對用戶，你要考慮你的產品是否能夠讓用戶使用起來感覺很「爽」，你要把用戶體驗放在首位，那麼你的產品首先功能上必須穩定，不然即使有再好的創意，再耐心的用戶總會使用其它產品替代你的產品。
面對開發者，你想要把某些功能開放，這時候你必須要開放某些介面。有人會說，我也可以使用MVC來開放這些介面，沒錯是可以，但是繞遠道給你帶來的是更大的代價。
Web API 和 MVC可以說是兩個不同的東西。Web API更傾向於基於HTTP協議的服務，直接返回用戶的數據請求。MVC是建站的一種框架，傾向於返回用戶的頁面請求。
我總結了以下 http://ASP.NET Web API 的特性，更能說明Web API是一種數據請求框架：
http://ASP.NET
Web API 可以根據請求報文來返回的相應數據格式。包括JSON和XML。http://ASP.NET
Web API 單獨做數據請求和MVC做頁面請求可以讓Web前端和後台更好的解耦，減少開發難度。Web API 可以更好地用在移動端網頁、桌面端網頁或者桌面程序。
Web API 的宿主可以選擇多樣：WebHost,，ConsoleHost，甚至是windows Services。
類似可以理解成ashx和webform的區別
4. asp.net mvc3 項目怎麼開發API介面
Visual Studio為我們提供了專門用於創建ASP.NET Web API應用的項目模板，藉助於此項目模板提供的向導，我們可以「一鍵式」創建一個完整的ASP.NET Web API項目。在項目創建過程中，Visual Studio會自動為我們添加必要的程序集引用和配置，甚至會為我們自動生成相關的代碼，總之一句話：這種通過向導生成的項目在被創建之後其本身就是一個可執行的應用。
對於IDE提供的這種旨在提高生產效率的自動化機制，我個人自然是推崇的，但是我更推薦讀者朋友們去了解一下這些自動化機制具體為我們做了什麼？做這些的目的何在？哪些是必需的，哪些又是不必要的？正是基於這樣的目的，在接下來演示的實例中，我們將摒棄Visual Studio為我們提供的向導，完全在創建的空項目中編寫我們的程序。這些空項目體現在如右圖所示的解決方案結構中。
如右圖所示，整個解決方案一共包含6個項目，上面介紹的作為「聯系人管理器」的單頁Web應用對應著項目WebApp，下面的列表給出了包括它在內的所有項目的類型和扮演的角色。
·Common：這是一個空的類庫項目，僅僅定義了表示聯系人的數據類型而已。之所以將數據類型定義在獨立的項目中，只要是考慮到它會被多個項目（WebApi和ConsoleApp）所使用。
WebApi：這是一個空的類庫項目，表現為HttpController類型的Web API就定義在此項目中，它具有對Common的項目引用。
WebHost：這是一個空的ASP.NET Web應用，它實現了針對ASP.NET Web API的Web Host寄宿，該項目具有針對WebApi的項目引用。
SelfHost：這是一個空的控制台應用，旨在模擬ASP.NET Web API的Self Host寄宿模式，它同樣具有針對WebApi的項目引用。
WebApp：這是一個空的ASP.NET Web應用，代表「聯系人管理器」的網頁就存在於該項目之中，至於具體的聯系人管理功能，自然通過以Ajax的形式調用Web API來完成。
ConsoleApp：這是一個空的控制台應用，我們用它來模擬如何利用客戶端代理來實現對Web API的遠程調用，它具有針對Common的項目引用。
二、定義Web API
在正式定義Web API之前，我們需要在項目Common中定義代表聯系人的數據類型Contact。簡單起見，我們僅僅為Contact定義了如下幾個簡單的屬性，它們分別代表聯系人的ID、姓名、聯系電話、電子郵箱和聯系地址。
1: public class Contact
2: {
3: public string Id { get; set; }
4: public string Name { get; set; }
5: public string PhoneNo { get; set; }
6: public string EmailAddress { get; set; }
7: public string Address { get; set; }
8: }
表現為HttpController的Web API定義在WebApi項目之中，我們一般將ApiController作為繼承的基類。ApiController定義在「System.Web.Http.dll」程序集中，我們可以在目錄「%ProgramFiles%\Microsoft ASP.NET\ASP.NET Web Stack 5\Packages\」中找到這個程序集。具體來說，該程序集存在於子目錄「Microsoft.AspNet.WebApi.Core.5.0.0\lib\net45」中。
Web API體現在如下所示的ContactsController類型中。在該類型中，我們定義了Get、Post、Put和Delete這4個Action方法，它們分別實現了針對聯系人的查詢、添加、修改和刪除操作。Action方法Get具有一個表示聯系人ID的可預設參數，如果該參數存在則返回對應的聯系人，否則返回整個聯系人列表。由於ASP.NET Web API默認實現了Action方法與HTTP方法的映射，所以方法名也體現了它們各自所能處理請求必須採用的HTTP方法。
1: public class ContactsController: ApiController
2: {
3: static List<Contact> contacts;
4: static int counter = 2;
5:
6: static ContactsController()
7: {
8: contacts = new List<Contact>();
9: contacts.Add(new Contact { Id = "001", Name = "張三",
10: PhoneNo = "0512-12345678", EmailAddress = "[email protected]",
11: Address = "江蘇省蘇州市星湖街328號" });
12: contacts.Add(new Contact { Id = "002", Name = "李四",
13: PhoneNo = "0512-23456789", EmailAddress = "[email protected]",
14: Address = "江蘇省蘇州市金雞湖大道328號" });
15: }
16:
17: public IEnumerable<Contact> Get(string id = null)
18: {
19: return from contact in contacts
20: where contact.Id == id || string.IsNullOrEmpty(id)
21: select contact;
22: }
23:
24: public void Post(Contact contact)
25: {
26: Interlocked.Increment(ref counter);
27: contact.Id = counter.ToString("D3");
28: contacts.Add(contact);
29: }
30:
31: public void Put(Contact contact)
32: {
33: contacts.Remove(contacts.First(c => c.Id == contact.Id));
34: contacts.Add(contact);
35: }
36:
37: public void Delete(string id)
38: {
39: contacts.Remove(contacts.First(c => c.Id == id));
40: }
41: }
簡單起見，我們利用一個靜態欄位（contacts）表示存儲的聯系人列表。當ContactsController類型被載入的時候，我們添加了兩個ID分別為「001」和「002」的聯系人記錄。至於實現聯系人CRUD操作的Action方法，我們也省略了必要的驗證，對於本書後續的演示的實例，我們基本上也會採用這種「簡寫」的風格。
5. Web Api及MVC性能提升的幾個小技巧
一、緩存
為了避免每次請求都去訪問後台的資源，我們一般會考慮將一些更新不是很頻繁的，可以重用的數據，通過一定的方式臨時地保存起來，後續的請求根據情況可以直接訪問這些保存起來的數據，這種機制就是所謂的緩存機制。緩存分為頁面輸出緩存，內存數據緩存和緩存依賴等。從設計原則來說，易變性、敏感性的信息不適合進行緩存，同時緩存的內容也是易丟失的，在代碼中不能完全依賴於緩存的數據，需要保證在緩存的數據丟失後也能進行正確的處理。
1、頁面輸出緩存
通過對輸出的頁面進行緩存，每次新的用戶請求調用相同的 Action 時，相同的內容不需要重新創建一次而直接輸出。頁面輸出緩存的使用非常簡單，在 Action 上使用 [OutputCache] 特性標記即可生效。頁面輸出緩存可控制緩存的內容所存儲的位置，例如是在伺服器端存儲緩存的頁面內容還是在客戶端存儲緩存的頁面內容；也可使用 Duration 參數控制緩存的失效絕對時間和間隔時間，甚至能使用 VaryByParam 參數對不同的請求參數分別進行緩存。頁面輸出緩存非常適合於內容比較固定的前端頁面的緩存。
2、內存數據緩存
通常情況下，數據是保存在資料庫、磁碟文件等存儲介質中的，而應用程序訪問這些資源是一項很費時的操作。如果先將這些資源中的數據緩存到內存緩存區中，當應用程序需要這些數據時，直接從緩存區中提取，就可以減少系統開銷，顯著提高可使用的用戶並發數等。內存數據緩存需考慮緩存的內容更改失效後如何清空其他已經被緩存的相關聯的數據問題。
3、EFCache
眾所周知，NHiberate 提供了二級緩存功能。現在，如果你使用的是 Entity Framework 6 或更高版本的 Entity Framework ，你也可考慮使用 EFCache 組件來為 Entity Framework 提供二級緩存支持，其實質上也是屬於內存數據緩存。EFCache 的特點是使用上非常方便，僅需定義如下的代碼無需其他復雜的額外的配置即可實現二級緩存。如需定義特定的緩存策略，如緩存的過期時間，控制數據緩存的范圍，也僅需繼承 CachingPolicy 類並 override 其部分方法即可。你甚至可以通過實現 ICache 介面來實現自定義的緩存模型以替換默認的 InMemoryCache 。
二、Stream壓縮
對響應流進行壓縮，其作用是減少網路開銷，提高系統的響應速度。目前的瀏覽器通常都支持 gzip 和 deflate 壓縮解壓功能，因此你通常無效考慮瀏覽器的兼容性問題。啟用 gzip 和 deflate ，既可通過 IIS 配置實現，在 MVC 中也可通過編寫自定義的 ActionFilter 實現。在壓縮之前和壓縮之後 Stream 的大小差異通常都是驚人的，其壓縮率通常都在5-10倍以上。
三、js和css文件的壓縮和打包
1、js 和 css 文件的壓縮
其實質就是生成較小的文件，減小下載這些文件的網路開銷，提供系統的響應速度。壓縮 js 和 css 文件還有個好處是通常還可以起到代碼混淆的作用。在 YbSoftwareFactory 的 MVC 解決方案中，使用的是 Microsoft Ajax Minifier 組件，可在代碼編譯的過程中自動對所配置的 js 和 css 進行壓縮，基本上文件的大小都可減少一半以上
2、js、css文件的打包
其目的是進行 js 文件和 css 文件的合並，當前主流瀏覽器的並發連接數默認情況下通常都是 6 個，如果前端頁面同時請求的伺服器資源（如 img 文件、js 文件、css 文件以及各類 url 請求等）超過6個，通常就需要進行排隊下載。進行 js 文件、css 文件的打包合並，通常可以在一次請求中就完成未打包之前需多次請求才能完成的工作，通過減少前端瀏覽器的連接請求，在某種意義上也是可提高系統的響應速度的。
6. 基於ASP.NET MVC框架開發Web論壇應用程序[1]
我想通過本系列文章從頭到尾構建一個完整的ASP NET MVC論壇應用程序 最終的目的是探討和推動使用ASP NET MVC框架構建應用程序的最佳實踐友局
簡介
在本篇中 我想先從全局方面介紹一下論壇應用程序的總體目標 在本篇中 我將討論一下避免代碼壞味道的重要性 還將討論如何利用軟體設計原則和模式來幫助你編寫適合未來改變的富有彈性的代碼 最後 我還將論證一下為什麼我選擇使用測試驅動開發方式構建本系列文章中的論壇應用程序
什麼樣的軟體是好的軟體
我不想僅僅為了構建論壇應用程序而任意構建此論壇應用程序 我的目標是盡可能構建最棒的論壇應用程序
這個目標立即引發這樣一個問題 什麼樣的軟體是好的軟體？是什麼導致一個應用程序比另一個應用程序更好一些或更差一些呢？在事先沒有一個關於 好軟體 的定義之前 我無法聲明我構建了一個完美的論壇應用程序
因此 下面是我對於 好軟體 的定義
好軟體是設計得易於修改的軟體
存在多種原因可能需要你改變軟體
)你可能需要在一個現有軟體上添加新的特徵 )你可能需要修改一個現有軟體中的錯誤 )你可能需要優化現有軟體 )你可能需要改進現有軟體的設計
一般說來 設計糟糕的軟體是難於改變的 有些軟體設計得如此糟糕 以致於每個人都害怕碰一碰它 我們大家應該都使用過設計得糟糕的軟體 當軟體不好時 你很希望它乾脆走開 甚至如果有機會的話 你可能想從頭開始重新編寫這款軟體
避免代碼壞味道
Robert和Micah Martin把糟糕的軟體部分描述為代碼壞味道 下列代碼壞味道意味著此軟體的書寫是相當糟糕的
)僵化性（Rigidity）—僵化的軟體是這樣的軟體 當你在某個位置作一改動時即要求對系統作出相應的一系列的更改 )脆弱性（Fragility）—脆弱的軟體是這樣的軟體 你在某個好鋒讓位置作一改動時即打斷另外多處的正常運行 )不必要的復雜性—不必要的復雜軟體是指過度設計的軟體 其目的是為了處理任何可能的改變 )不必要的重復—不必要的重復軟體中包含大量的重復性代碼 )晦澀性—晦澀的軟體是指難於理解的軟體
【注意】上述這些代碼味道在Micah和Robert Martin的著名《Agile Principles Patterns and Practices in C#》中得到充分的描述 在此 強烈建議讀者讀一下這本書 注意 上述這些代碼味道都與所有的代碼改變相關聯 每一個這些代碼味道都將妨礙代碼的改變
軟體設計原則
遵循良好的軟體設計原則 將有助於編寫軟體易於適應未來更改的軟體 軟體設計原則有若干 也不盡相同 例如 Cunningham和Cunningham Wiki描述面向對象設計的 個原則 //c /cgi/wiki?
其中提到的面向對象設計的前五個原則與Robert Martin及他的兒子Micah Martin編著的《Agile Principles Patterns and Practices in C#》中所基激主張的軟體設計原則是一致的 此外 Robert Martin還在Object Mentor開辟的博客上討論了這些原則 // objectmentor /resources/publishedArticles
此外 我還發現有另外兩本書中也提供了有關軟體設計原則的極其有用的信息 第一本是Eric Freeman Elisabeth Freeman Kathy Sierra Bert Bates編著的《Head First Design Patterns》 第二本是Brett McLaughlin Gary Pollice和David West編著的《Head First Object Oriented Analysis and Design》 盡管這些書所討論的原則與Robert Martin的提法並不十分相同 但是它們卻十分相近
lishixin/Article/program/net/201311/14493
7. 如何使用mvc實現webapi的增刪改查
1.創建項目：visual C# —> ASP.NET MVC 4 web應用程序 模板—>web api;
2.注冊路由:
路由表中的每一個條目都包含一個路由模板。這個Web API默認的路由模版是"api/{controller}/{id}"。在這個模版中，「api」是一個文字式路徑片段，而{controller}和{id}則是佔位符變數。
當Web API框架接收一個HTTP請求時，它會試圖根據路由表中的一個路由模板來匹配其URI。如果無路由匹配，客戶端會接收到一個404（未找到）錯誤。
3.linq to sql連接資料庫
1.建立資料庫建表
2.在models文件夾裡面新建linq to sql類文件
3.工具->連接到資料庫
4.將要用的表拖入設計區
5.獲取資料庫Getway。"linq to sql class"文件名+Datacontext實例化這個對象，數據表就會映射到一個集合屬性中，personDataDataContext db = new personDataDataContext();
6.增刪改查
增：
public Boolean Post([FromBody]UserInfo userInfo) {
personDataDataContext db = new personDataDataContext();
var s1 = new test2
{
UserName =userInfo.UserName, Id=userInfo.Id, Age=userInfo.Age
};
if (db.test2.SingleOrDefault<test2>(s => s.Id == userInfo.Id) == null)
{
db.test2.InsertOnSubmit(s1);
db.SubmitChanges();
return true;
} else {
return false;
}
}
刪:
public bool Delete(int id)
{
personDataDataContext db = new personDataDataContext();
var deleteperson = db.test2.SingleOrDefault<test2>(s => s.Id == id);
if (deleteperson == null)
{
return false;
} else {
db.test2.DeleteOnSubmit(deleteperson);
db.SubmitChanges();
return true;
}
}
改:
public Boolean Put(int id, [FromBody]UserInfo userInfo)
{
personDataDataContext db = new personDataDataContext();
var editperson = db.test2.SingleOrDefault<test2>(s => s.Id == userInfo.Id);
if (editperson == null)
{
return false;
} else {
editperson.Age = userInfo.Age;
editperson.UserName = userInfo.UserName;
db.SubmitChanges();
return true;
}
查:
public IEnumerable<test2> Get()
{
personDataDataContext db = new personDataDataContext();
var query = from s in db.test2
orderby s.UserName
select s;
return query;
}
// GET api/values/5
public string Get(int id)
{
return "value";
}
這里我新建了一個userinfo類
public class UserInfo { public string UserName { get; set; } public int Id { get; set; } public int Age { get; set; } }
用來接收前端頁面ajax請求中的data數據，s => s.Id == userInfo.Id是lamda表達式創建委託方法意思是在db.test2的person集合中查找某個person的Id與userinfo接收到的id相等的person對象
8. 如何看待asp.netweb開發技術
先簡單回顧下asp.net過去十年
mvc流行前
asp.net的服務端控制項，將html和js一起封裝，很多客戶端事件自動通過生成的js將數據重新post回服務端。而對於很多剛入門的小夥伴來說，僅僅靠拖放控制項和寫C#代碼就可以實現一個可用的Web項目，大大降低了入門門檻。相應的，服務端控制項這種過度耦合的設計帶來了很多缺點：自定義控制難，難以純粹將前後端分離，導致asp.net從業人員既不能精通困神前段技術，又不能涉獵更多的後端技術（生態問題）。
這個年代，.net被貼上了「拖放控制項」的標簽。
mvc流行後
微軟推出了asp.netmvc，很多公司已經開始嘗試前後端分離。就模式上面來說，已經和其它語言平台基於mvc的web項目開發模式無異。
但是asp.net本身的服務框架太雜亂，尤其是艱難（如果你留意過，甚至可以說難產）支持asyncawait非同步編程後，他的同步上下文模型缺點太大：首先是源碼的結構混亂，其次是使用過程很多人容易造成死鎖，非同步方法使用不當導致請求已返回上下文已釋放然後找不到同步對象導致的異常。問題的根源是大部分程序員對線程了解不深，如果項目有正確的規范用法還好，一旦沒有，產生異常很多人根本不知道問題出在哪裡。博客園改造過程中就嘩尺桐出現過的死鎖，有興趣的可以去看看博客園官方博客寫過。
aspnetcore
新應用程序模型設計和代碼實現，我非常喜歡。其它的不說，看看那簡潔的Reqeust和Response對象，是不是就會讓你欣喜？再看看中間件管道，上下文（Context）通過委託鏈鏈一路傳遞，再也不用晦澀的同步上下文，也移除了和Windows安全相關的特徵。
整個架構更加清晰，喜歡做擴展的人絕對會有一日看盡長安花的快感。
自然性能也不用說，可以關注github上亂坦微軟之前做過的除了mvc之外的性能測試對比。
net生態
擁抱開源後，netcore，standard，aspnetcore，efcore等一系列實現全部都有了，明年的netcore3.0還會包含客戶端模型（wpf和winform，只能在windows下使用）。
github上面aspnet，dotnet，dotnet-architecture等分支包含大量微軟直接維護的開源項目。
開源社區大部分的項目已經跟進將三方組件基於standard標准打包。
微軟也久違地把散亂的文檔匯集到docs子域名下
萬事劇本，就欠生態！如果apache基金會下面的重要項目都有.net的分支，相信依靠netcore必定可以再次搶占不少的份額。
前景
微服務流行後，其實內部可以混合多種平台提供服務，用aspnetcore做對三方組件需求不太大的業務服務是完全的可以的，基於微軟一貫的作風，開發效率是很高的。
其實現在很多內部系統在用.net，只是面向互聯網相關的項目，更加需求豐富的三方資源，採用.net的比較少。不過很多大的公司都有.net的分支團隊。畢竟在桌面和開發效率上的優勢，還是有他存在的價值。
aspnet到底會如何發展，個人感覺還是要看社區的反應，要看生態是否能逐步豐富起來。
看在微軟這么努力的份上，個人挺希望他能夠扳回一局。
所以？
眼光放長遠一點，平台只是我們的工具，一個IT人不應當把自己的技術范圍限定到某一個平台。多學多積累，實際項目中應該針對需求、架構以及團隊做出選擇。
比如Java和.net同時掌握，各取所長，基於他們重疊性較高的原因，學習成本並不高。何況絕大部分的知識和平台並無關系。
個人見解純手打，歡迎大家評論或者提出意見。