我們常用的 LINQ to SQL 就是一種簡單、易用的 ORM 技術。我們也都知道若是拿採用 ORM 技術與直接存取 Database 這兩件事來比較，ORM 因為多卡了一層一定會比較慢一些些，但是採用 ORM 技術有很多機會可以調校(Tuning)，例如資料快取(Caching)、定義查詢計畫(Query Plan)等。
... 繼續閱讀 ...
我個人有習慣收集一些網路上別人整理的速查表，因為程式開發的細節真的太多了，要能全部背起來不太可能，也沒什麼意義，甚至於有人說程式設計就是一件查詢、複製、貼上的工作而已。對我來說，寫程式首重觀念與經驗，有了完整而正確的觀念，就算記不得要怎麼寫，查詢一下就馬上能寫了；而有了經驗，對於一些難解的 Bug 自然能夠迅速解開。
... 繼續閱讀 ...
在這 Web 2.0 的時代，JSON 這個資料傳輸格式已經越來越多人在使用了，今年 5 月份 Json.NET 才剛發佈 2.0 版，在前幾天(8/25)又發佈 3.0 版，這個新版本除了修正許多所有已知的 Bugs 之外，還添加了許多新功能與特性，其中包括：
... 繼續閱讀 ...
我們通常在寫 LINQ to SQL 專案時，都會利用 Visual Studio 2008 內建的 LINQ to SQL DBML Designer 讓我們透過視覺化的介面將資料庫表格、檢視表或預儲程序從 Server Explorer 拖曳到設計視窗中，不過缺點就是當資料庫結構(DB Schema)改變了之後就需要跟著修正，我通常有以下選擇：
... 繼續閱讀 ...
如果你用 LINQ to SQL 開發系統的話，若兩個關連的表格需要更新資料，但需要更新的資料是 Foreign Key 的值的話，就有些地方需要特別注意，由於透過 LINQ to SQL 讀取或寫入資料都是透過 ORM ( Object-relational mapping ) 的方式儲存，讓原本在資料庫中的資料改以物件的方式表達，因此對這種包含關連的物件，就不能像用 T-SQL 的方式一樣改變關連的鍵值。
... 繼續閱讀 ...
之前我曾經寫過一篇【解決 LINQ to SQL 資料庫更新衝突的情形】，主要是講解在寫 LINQ to SQL 程式的時候(Code Behind)若發生衝突的解決辦法，但我最近遇到的問題是，當我的頁面用的是 DetailsView + LinqDataSource 且完全是用宣告(Declarative)的方式寫成的，也就是改頁並沒有寫任何程式碼，這時發生了衝突的狀況的錯誤訊息是 Row not found or changed （如下圖示），不過卻完全看不出哪裡錯了，只知道新增資料的時候不會出錯，但每次更新或刪除的時候都會出錯，而從堆疊追蹤(Stack Trace)所顯示的訊息來看，也沒地方讓我修改，遇到這種問題先不要驚慌，因為這應該只能用我文章中說明的第三種方法進行設定了。
... 繼續閱讀 ...
在 ADO.NET 2.0 有個 Query notifications (SqlDependency) 機制，讓 SQL Server 2005 能夠主動通知你的應用程式(Application)來源資料是否變更，尤其是在做資料快取(Cache)的時候特別有效率。但自從改用了 LINQ to SQL 好像就很少人提到如何利用 SqlCacheDependency 類別進行 LINQ to SQL 查詢後的結果做快取。
... 繼續閱讀 ...