上一篇中，我們分析了實體類的基類Entity，這一篇中，我們就分析一下基于該類的實體類。
這兩個檔案中，BlogClass.designer.cs包含所有的生成代碼：成員、屬性等，而BlogClass.cs則隻包含一個類的定義，供我們填寫代碼使用。
BlogClass.designer.cs的代碼如下。
從代碼裡可以看到，完全就是對實體XML的翻譯，需要特别指出的是，其中實作了Entity定義的ID和TimeStamp這兩個抽象屬性。
BlogClass.cs的代碼如下：
呃……這個更簡單了，完全就是個空的。因為它的用處就是讓我們填寫自己的代碼，現在假設我們有這麼一個功能“設定日志分類名稱時，如果分類的描述為空，則将分類的描述設定為其名稱”，那麼我們可以這麼幹：從BlogClass.desinger.cs檔案中，将Name屬性的定義Ctrl+X，Ctrl+V過來，然後改改，修改後的代碼如下：
這個代碼很好了解，值得一提的是，當描述實體的XML修改後，重新生成實體代碼時，代碼生成器會判斷BlogClass.cs中是否包含了Name屬性，如果包含了該屬性，則在BlogClass.designer.cs中，就不會再生成了。這是自己寫代碼生成而不用通用代碼生成器的好處——我的地盤我做主。:)
另外一個和實體相關的類是Extension類，顧名思義，該類包含的都是對已有類型的擴充方法，利用C#3.0的擴充方法，可以寫出非常優雅的代碼。例如，我們需要查詢某一個分類的所有Blog，給出的是該分類的ID，我們就可以在BlogExtension類中這麼寫（代碼位于\DongBlog.Business\Blogs\Blog.cs）：
上面的查詢方法使用Linq實作的，我們還順手做了一個根據更新時間的排序。有了這個方法，我們以後就可以用這樣的方式取得某一個分類的Blog：database.GetDataAccess<Blog>().GetBlogByClassID(1)；該方式以後還會進一步簡化為：database.Blogs.GetBlogByClassID(1)。
最後說明一點，以上代碼都是可以測試的，因為我們所有的方法都是使用接口作為參數的，是以我們可以用腳手架（Mock類）僞實作相應的接口，以便對不同輸入和環境下的代碼進行自動化測試，具體方法就不展開了。
下一篇文章我們将分析資料通路的設計與實作。
<a href="http://files.cnblogs.com/yuandong/20080509DongBlog.rar">代碼下載下傳</a>
本文轉自冬冬部落格園部落格，原文連結：http://www.cnblogs.com/yuandong/archive/2008/05/09/1190563.html，如需轉載請自行聯系原作者