摘要:為什麼需要LINQ to SQL ? 關於 SQL 的 Like 子句
很多人，包含我自已在內，一開始的時候，總是在想，LINQ to SQL 到底想要幹麻，SQL還不夠用嗎，搜尋功能一應俱全，是呀，的確夠用，如果對於純粹的資料庫本身來說，反觀LINQ to SQL，就那幾個子句，select、from、where、in …連個Like模糊比對功能都找不到，到底 LINQ to SQL 要幹麻?
LINQ to SQL 要幹麻，為什麼要用它 ? 從去年到現在，我一直嘗試想要回答這個問題，不只是說服讀者，更得說服我自已，否則，年後要出版的 LINQ 新書，到底想賣誰?
今天先提一個簡單概念，就是物件，大家可能習慣了SQL，覺得沒什麼不好，當你需要查詢一些特定資料的時候，例如，某個書籍資料表裡面的書籍資料，我們會寫下這樣的語法：
SELECT * FROM Book
其中，Book是資料表，「*」代表回傳所有的資料欄位，這一段SQL被送回伺服器作解譯，然後回傳取得的資料內容，一切都很美好。
好，現在我要進一步的萃取其中某些資料，例如，代表書籍名稱的 BookTitle 欄位，語法如下：
SELECT BookTitle FROM Book
很快的，我又搞定了，不止如此，如果我要查詢BookTitle欄位所儲存的書籍名稱中，有 ASP.NET 的，很簡單，再來一段：
SELECT BookTitle FROM Book WHERE BookTitle LIKE '%ASP.NET%'
搞定了，我用了LIKE。
SQL這麼好用，為什麼再搞一個LINQ to SQL 出來?先來看看上述LIKE，轉換成為LINQ to SQL怎麼寫：
var enumQuery =
from book in db.Book
where book.BookTitle.Contains("ASP.NET")
select book
今天，我還不打算詳細介紹語法，我們來看其中的重點，這段語法可以讓我們萃取出等同於上述LIKE語法的所回傳的內容資料，它的好處，至少有兩點：
- 物件化導向的寫法，db代表資料庫實體，book為其屬性，它回傳一個對應底層Book資料表的Entity類別，然後資料表的欄位，直接透過book這個變數進行引用即可存取。
- 完全整合進C#，如你所見，不用去拼湊SQL，只要透過C#，就能萃取所要的資料內容，聰明的讀者可能想到了，即然可以這樣玩，是否代表著我們可以利用字串本身的功能，作單一欄位內容的資料萃取?答案是對的。
看 到它的好處了嗎，上述的語法，.NET會自動轉換成為對應的SQL，有了LINQ to SQL ，你將不需要再去拼湊SQL，所有的資料表都是物件，所有的資料表欄位，都是物件的屬性，你甚至可以直接寫一個欄位驗證函式，再將這個函式嵌入LINQ語 法中，例如以下的程式片段：
var enumQuery =
from book in db.Book
where Check(book)
select book
其中的Check是一個自訂函式，你想寫一個多複雜的邏輯函式都沒人管你，反正LINQ to SQL會幫你搞定它。
最 後，我要說的是，LINQ之前，SQL是SQL，程式語言是程式語言，它們只能溝通，但無法整合，充其量只是你玩你的，我玩我的，最後再將結果整理出來， 而LINQ本身就是言語的一部份，資料庫存取技術在SQL出現多年之後，現在真正的被融入了語言當中，最重要的，它被物件化了，以物件導向設計詮釋資料存 取技術，這一點，絕對是資料存取技術發展的一個里程碑，下一篇，我們繼續來談這個所謂的里程碑，待續 …
相關閱讀：「為什麼需要LINQ ? 我的一些想法 」:)
