我發現許多人對使用 LINQ 執行 JOIN 查詢並不是那麼的熟悉，而且語法也不見得像 T-SQL 那樣直覺，但事實上只是我們比較熟悉 T-SQL 的語法與資料庫架構而已，當我們換成 ORM (Object-relational mapping) 技術後所有對資料的操作必須全部改以「物件」與「實體」來思考，所以在這轉換的過程經常轉不過去，連我自己也有時會忘記怎麼寫，也經常利用 Linq Samples and the Sample Query Explorer 幫我查出適當的寫法。
... 繼續閱讀 ...
ASP.NET MVC 的開發原則有個 SoC (Separation of Concern) 的觀念，我們在開發較大型的 ASP.NET MVC 應用程式時會特別將資料存取層(Data Access Layer) 再細分為兩個層次，分別是 Repository Layer (資料倉儲層) 負責資料存取與欄位格式驗證，與 Service Layer (服務提供層) 負責資料篩選與商業邏輯驗證，但分層之後遇到了一個之前沒想過的問題，進而導致 LINQ to SQL 查詢效能不彰。
... 繼續閱讀 ...
在使用 Model Binder 繫結資料模型時 (Entity Type) ，大部分情況都是非常方便的，可有效減少 Action 參數的用量，也可大幅降低程式複雜度。但是在我們之前的某個專案就採到一個 Model Binder 的地雷，這個地雷不是 ASP.NET MVC 的 Bug，而是一個開發時應注意的地方，採用標準的寫法準沒錯。
... 繼續閱讀 ...
熟悉 LINQ to SQL 的朋友應該很清楚如何透過 Skip 與 Take 方法來取得資料的部分集合，但各位可能不知道透過這種方式分頁時有個很有可能出錯的地方，而且這個錯誤可能會讓你覺得這是 LINQ to SQL 的 Bug，有在使用 LINQ to SQL 分頁的人必看此篇文章。
... 繼續閱讀 ...
最近有個專案很奇怪，我有個 Visual Studio 方案檔，開啟後會載入好幾個專案(Project)，其中有個專案負責所有與 Data Access Layer (DAL) 有關的工作，但我每次剛開啟 Visual Studio 2008 並載入專案後都無法直接按下 F6 直接建置方案( Build Solution )，都一定要先建置(Build)含有 DBML 的那個專案，才能再按下 F6 建置整個方案。
... 繼續閱讀 ...
我們今天遇到一個特殊的例子，當資料庫中的其中一個表格設定一個 AFTER INSERT 觸發程序(Trigger)時，竟然造成新增資料失敗，錯誤訊息如下：
... 繼續閱讀 ...
我們常用的 LINQ to SQL 就是一種簡單、易用的 ORM 技術。我們也都知道若是拿採用 ORM 技術與直接存取 Database 這兩件事來比較，ORM 因為多卡了一層一定會比較慢一些些，但是採用 ORM 技術有很多機會可以調校(Tuning)，例如資料快取(Caching)、定義查詢計畫(Query Plan)等。
... 繼續閱讀 ...
剛花了些時間靜下心來讀了些 Entity Framework 相關資料，終於對 Entity Framework 有了些清楚的輪廓，由於我之前 LINQ to SQL 還算有點瞭解，對 ORM ( Object-relational mapping ) 也還算有點概念，所以在這樣的基礎之下，我相信要上手 Entity Framework 應該不是什麼難事。
... 繼續閱讀 ...
我們通常在寫 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 查詢後的結果做快取。
... 繼續閱讀 ...
我們通常會使用 DetailsView 或 FormView 控制項進行資料的新增、編輯、刪除等動作，而通常我們會在裡面放置許多 Validator 控制項以驗證資料格式是否正確，不過當進行較大的專案時，開發人數通常會比較多，而且人員之間的分工也會比較明確，有的人做 SA、有的人做 DBA、有的人做 ASP.NET UI Process 開發...等等，在分層負責的情況下若能夠有效分割工作，不但專案品質會比較高，大家在寫程式的過程中也會比較專注。
... 繼續閱讀 ...