這也是之前在珠三角技術沙龍上的示例之一，解決的是在ASP.NET MVC使用dynamic類型Model時遇到的一個真實問題。C# 4編譯器支持dynamic類型，因此在編寫頁面模板的時候自然就可以把它作為視圖的Model類型。表現層的需求很容易改變，因此dynamic類型的Model可以減少我們反復修改強類型Model的麻煩，再配合匿名類型的使用，可謂是動靜相宜，如魚得水。不過，如果把一個匿名類型直接作為Model交給視圖去使用，在默認情況下會拋出異常。我們可以用Mono.Cecil來改變這一情況。

　　這個問題來源于Apworks應用開發框架的設計。由于命令與查詢職責的分離，使得基于CQRS體系結構風格的應用系統的外部存儲系統的結構變得簡單起來：在“命令”部分，簡單地說，只需要 Event Store和Snapshot Store來保存Domain Model；而“查詢”部分，則又是基于事件派送與偵聽的系統集成。之前我也提到過，“查詢”部分由于不牽涉到Domain Model，于是，它的設計應該隨意性很大：不需要受到Domain Model的牽制，例如，我們可以根據UI所需的數據源結構進行“查詢”庫的設計。Greg Young在他的“CQRS Documents”一文中也提到了這樣一些相關話題：就“查詢”部分而言，雖然也存在“阻抗失衡”效應，但是事件模型與關系模型之間的這種效應，要遠遠小于對象模型與關系模型之間的“阻抗失衡”效應。這是因為，事件模型本身沒有結構，它僅僅表述“該對關系模型做哪些操作”這樣的概念。在設計上，Greg Young建議，采用一種非正規的方式設計“查詢”數據庫，以便盡量減少讀取數據時所需的JOIN操作，比如可以選用基于第一范式（1NF）的關系模型。這是一種反范式模型，雖然Greg Young并沒有建議根據UI所需的數據源結構進行設計，但思想是相同的：基于事件而不拘泥于對象模型本身。由此引申出來的另一個好處就是外部存儲系統架構的隨意性：你可以選用任何存儲技術和存儲媒介，這又給基于系統架構的性能優化提供了便利。因為并非所有的存儲架構都支持“表”、“字段”、“存儲過程”、“JOIN”這些概念。

系列文章導航：

C#多線程學習(一) 多線程的相關概念

在前一篇文章中，我提出了在使用LINQ to SQL進行更新操作時可能會遇到的幾種問題。其實這并不是我一個人遇到的問題，當我在互聯網上尋找答案時，我發現很多人都對這個話題發表過類似文章。但另我無法滿足的是，他們盡管提出了問題，卻沒有進行詳細的剖析，只給出了解決方案（如添加RowVersion列、去除關聯等），但卻沒有說明為什么必須這么做。這也是我寫上篇的初衷，希望通過對LINQ to SQL源代碼的分析，來一步一步找出解決問題的辦法。本文將對這些方法一一進行討論。

　　在上一篇文章中，介紹了如何訪問 DataContext 對象，下面接著來講解一下如何訪問設計器中的表對象，并生成生體類代碼。從 Northwind 數據庫中拖一個表到設計器中。拖出來后，記得保存 dbml 文件，否則是無法訪問到這個表的。 在這里拖的是 Catories 表，如下圖所示：

這個工具，是在一個項目中提取出來的，現在免費提供給大家使用。

　　緣起: 在數據驅動的web開發中，經常要重復從數據庫中取出相同的數據，這種重復極大的增加了數據庫負載。緩存是解決這個問題的好辦法。但是ASP.NET中的雖然已經可以實現對頁面局部進行緩存，但還是不夠靈活。此時Memcached或許是你想要的。

系列文章導航：

memcached完全剖析–1. memcached的基礎