SQL Server LocalDB 在 ASP.NET中的應用介紹

我相信世界總是會向更好的方向發(fā)展，今年的維也納新年音樂會沒有往年的明星級指揮，但是它通過回歸奧地利的本質(zhì)，以更傳統(tǒng)的聚合法則，讓過往的藝術(shù)家們一代代創(chuàng)造的燦爛，在新的指揮手中，迸發(fā)出更深邃的音節(jié)。在此，也祝大家新年快樂。
如同交響樂一樣，構(gòu)造軟件系統(tǒng)不一定必須某個強大的明星驅(qū)動，我們站在歷代ADO.NET的肩膀上，更好地回歸到SQL Server的核心開發(fā)：SQL Server LocalDB 在 ASP.NET中的應用。

使用SQL Server LocalDB的優(yōu)勢：

使用連接字符串：connectionString="Data Source=(LocalDb)\v11.0; Initial Catalog=xxx;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|\test666.mdf"。





我們把系統(tǒng)生成的數(shù)據(jù)庫文件，在管理工具中附加到SQL Server中，會看到程序自動創(chuàng)建了一個名為DBBases的表

以上幾點解決了基本的連接功能，Visual Studio 2012 與SQL Server 2012 Management Studio中調(diào)試通過。

但是，問題只解決了一半， 注意上面我用的是“vs2012”、“調(diào)試”這兩個詞語，目前我還沒說過在“IIS”中“運行”。

2：IIS中的用戶權(quán)限問題

在visual studio 中調(diào)試項目，使用的是windows 本地用戶進程，該進程具有比較高的權(quán)限（一般情況下與Administrator無異）。

而要在 IIS 中實際運行項目，執(zhí)行程序時windows7、2008、2008R2、Server 2012默認都是使用ApplicationPoolIdentity進程。

ApplicationPoolIdentity進程的權(quán)限在本篇中不過多解釋，在這里你只要把它理解為一個權(quán)限非常低的用戶進程（IIS_IUSRS組）即可。就算LocalDB是再怎么精簡的版本，它畢竟也是SQL Server，在最極端的情況下，需要經(jīng)歷“開啟sqlserver.exe進程”、“創(chuàng)建數(shù)據(jù)庫”兩個步驟，不是ApplicationPoolIdentity進程（IIS_IUSRS組）想做就做的。

解決辦法

1： 應用程序池 – 高級設(shè)置 – 標識， 以localsystem賬戶運行。Localsystem進程等同于本地administrator。



這樣的解決辦法最簡單，直接通過localSystem賬戶運行進程，一切煩惱瞬間化為烏有。但是隨之而來反面因素便是帶來了潛在安全威脅： 如果一個不懷善意的客戶端上傳了一段惡意代碼， 那么惡意代碼一旦獲得運行機會，那么將是以administrator的權(quán)限運行于服務(wù)器，這將意味著什么，不必多說。

2：通過AttachDBFile，掛接數(shù)據(jù)庫文件到更高的SQL Server版本解決問題。

LocalDB是真正的SQL Server，可以直接和其它版本SQL Server 無縫兼容，我們只需要把數(shù)據(jù)庫文件掛接到Express或更高版本SQL Server中，

僅僅是需要把：“Data Source=(LocalDb)\v11.0;”修改為: “Data Source=.\SQLExpress”，也可以解決一切煩惱了。這樣的做法雖然具備實際意義，但是與本文的主題關(guān)系不大，在此也不多描述了。

最后，基于安全因素的運行建議：

1：直接使用localsystem運行整個程序，只要不允許客戶端上傳文件，整套程序可以放心運行。但是大多數(shù)情況下一個有意義的web程序都是允許客戶端上傳文件的，所以列舉一個上傳文件的解決辦法：

在用戶上傳文件時，把文件放置到別的進程空間中，運行時，通過外鏈（upload.abc.com）文件的辦法，達到了讓用戶文件運行于絕對安全的進程中。



2：與建議1相反，把涉及到數(shù)據(jù)庫操作的代碼封裝為服務(wù)，通過WCF或Web API的自宿主功能，運行在另一個安全進程中（僅限本地連接），面向公眾的Web程序通過本地服務(wù)接口調(diào)用之，如此可以把一切安全因素最小化。（但是開發(fā)過程與維護會增加更高的復雜度）