我個人有習慣收集一些網路上別人整理的速查表，因為程式開發的細節真的太多了，要能全部背起來不太可能，也沒什麼意義，甚至於有人說程式設計就是一件查詢、複製、貼上的工作而已。對我來說，寫程式首重觀念與經驗，有了完整而正確的觀念，就算記不得要怎麼寫，查詢一下就馬上能寫了；而有了經驗，對於一些難解的 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 查詢後的結果做快取。
... 繼續閱讀 ...
身為一個程式設計師最討厭的就是被侷限在框框裡寫程式，我們唯一的限制應該是在我們的創意而非架構。像 LINQ 剛出來的時候我覺得超級好用，不過等用在專案上實做的時候才發現綁手綁腳的，想要動態組成一個 LINQ 語法難上加難，結果過沒多久就在 ScottGu's Blog 看到一篇 Dynamic LINQ (Part 1: Using the LINQ Dynamic Query Library)，看到的時候好像挖到寶一樣，以前在開發時卡住的問題全部都解決了，從今年 2 月份用到現在簡直是幾乎忘了它的存在，以致於這幾個月都沒有提及 Dynamic LINQ 這個好東西，直接上週一個朋友問我：『LINQ 的 Where 條件可以像以前組 SQL Command 一樣動態組裝嗎？』，我馬上跟他說有 Dynamic LINQ 這個東西，不用多說，他跟我剛看到 Dynamic LINQ 的時候一樣覺得：Bravo! ( 太棒了 )
... 繼續閱讀 ...
我們通常會使用 DetailsView 或 FormView 控制項進行資料的新增、編輯、刪除等動作，而通常我們會在裡面放置許多 Validator 控制項以驗證資料格式是否正確，不過當進行較大的專案時，開發人數通常會比較多，而且人員之間的分工也會比較明確，有的人做 SA、有的人做 DBA、有的人做 ASP.NET UI Process 開發...等等，在分層負責的情況下若能夠有效分割工作，不但專案品質會比較高，大家在寫程式的過程中也會比較專注。
... 繼續閱讀 ...