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

我相信世界總是會向更好的方向發展，今年的維也納新年音樂會沒有往年的明星級指揮，但是它通過迴歸奧地利的本質，以更傳統的彙總法則，讓過往的藝術家們一代代創造的燦爛，在新的指揮手中，迸發出更深邃的音節。在此，也祝大家新年快樂。
如同交響樂一樣，構造軟體系統不一定必須某個強大的明星驅動，我們站在曆代ADO.NET的肩膀上，更好地迴歸到SQL Server的核心開發：SQL Server LocalDB 在 ASP.NET中的應用。

使用SQL Server LocalDB的優勢：

快速部署完整的SQL Server。以後項目可以無縫升級到進階版本。 它是真正的SQL Server，直接使用到SQL Server 2012的所有功能。免費，對於初創企業和低設定管理員，可以節約前期的不少運營成本。
缺點與限制：

必須對伺服器有完全控制許可權，租用虛擬機器主機的使用者無法使用（但是目前一個VPS和虛擬機器主機的價錢差別也不大）。無法通過bin檔案夾中放置DLL進行綠色部署，伺服器必須安裝SQL Server Express LocalDB。

首先我們必須明白怎樣管理資料庫，在SQL Server 2012管理工具中：

使用 (LocalDb)\v11.0 字串來串連到當前原生 LocalDB運行時環境。

.net framework早於4.0.2的情況下，直接使用具名管道來串連 LocalDB，例如："Server=np:\\.\pipe\LOCALDB#F365A78E\tsql\query"

這一步與我們的開發環境設定關係不大，但是對於將來調試差錯，有很大協助。

下面通過兩個步驟設定在ASP.NET中運行LocalDB：

1：解決資料庫檔案定位

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

我們把系統產生的資料庫檔案，在管理工具中附加到SQL Server中，會看到程式自動建立了一個名為DBBases的表

以上幾點解決了基本的串連功能，Visual Studio 2012 與SQL Server 2012 Management Studio中調試通過。

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

2：IIS中的使用者權限問題

在visual studio 中調試項目，使用的是windows 本機使用者進程，該進程具有比較高的許可權（一般情況下與Administrator無異）。

而要在 IIS 中實際運行項目，執行程式時windows7、2008、2008R2、Server 2012預設都是使用ApplicationPoolIdentity進程。

ApplicationPoolIdentity進程的許可權在本篇中不過多解釋，在這裡你只要把它理解為一個許可權非常低的使用者進程（IIS_IUSRS組）即可。就算LocalDB是再怎麼精簡的版本，它畢竟也是SQL Server，在最極端的情況下，需要經曆“開啟sqlserver.exe進程”、“建立資料庫”兩個步驟，不是ApplicationPoolIdentity進程（IIS_IUSRS組）想做就做的。

解決辦法

1： 應用程式集區 – 進階設定 – 標識， 以localsystem賬戶運行。Localsystem進程等同於本地administrator。

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

2：通過AttachDBFile，掛接資料庫檔案到更高的SQL Server版本解決問題。

LocalDB是真正的SQL Server，可以直接和其它版本SQL Server 無縫相容，我們只需要把資料庫檔案掛接到Express或更高版本SQL Server中，

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

最後，基於安全因素的運行建議：

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

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

2：與建議1相反，把涉及到資料庫操作的代碼封裝為服務，通過WCF或Web API的自宿主功能，運行在另一個安全進程中（僅限本地串連），面向公眾的Web程式通過本地服務介面調用之，如此可以把一切安全因素最小化。（但是開發過程與維護會增加更高的複雜度）