.NET 分布式架構開發實戰之四 構建從理想和實現之間的橋梁（前篇）
核心提示：上一篇文章講述了一些實現DAL的理論，本篇主要是DAL實現的的初步的嘗試。
前言：
上一篇文章講述了一些實現DAL的理論，本篇主要是DAL實現的的初步的嘗試。
本篇的主要議題如下：
1). 設計DAL的基本操作
2). 對基本的操作的進一步的思考
3). 查詢對象的一些思考
1. 設計DAL的基本操作
Richard認為：在設計一個架構或者Framework的時候，有幾點很重要：
a. 總體把握的能力。
b. 抽象的能力。
c. 分析的能力
首先，從總體上來看，Richard認為DAL中最基本，而且最容易想到的方法就是CRUD四個操作。
于是Richard在草紙寫出了基本操作的名稱：
AddSingleDataEntity;
AddDataEntityList;
UpdateSingleDataEntity;
UpdateDataEntityList;
DeleteSingleDataEntity;
DeleteDataEntityList;
GetSingleDataEntiry;
GetDataEntityList;
上面列出的方法名字很長，其實Richard在思考這些方法的名稱的時候也參考了.NET設計規范中的一些建議：方法名稱要具有“自解釋性”，因為架構的設計最后還是給開發人員用的，所以方法的定義要一眼就看出它是干什么的，而且規范的命名也可以大大的減少維護的成本。
從總體出發，已經定義出了基本的操作，那么現在就開始一步步的分析，如何實現這些方法。
Richard開始思考第一個方法的實現，其實Richard心里也清楚：其實到底哪個方法作為第一個來考慮也許很重要，但是在一切都不清楚之前起碼要拿一個來入手，而且隨著思考的深入，很多的問題都會慢慢的浮現，到時候一切就會明晰起來。
對于AddSingleDataEntity這個方法，首先就要考慮這個方法到底要把什么添加到數據庫中，也就是說要考慮這個方法的參數，而且這個參數要足夠的“兼容”，因為之前Richard就是想設計出一個“以不變應萬變”的DAL。在考慮這個參數問題之前，首先Richard很清楚：在.NET數據訪問技術中，Linq，Entity Framework等ORM技術已經廣泛的應用，所以在設計DAL的時候要充分的考慮到現有的一些技術。
而且在數據是如何被存入到數據庫中的以及數據是如何從數據庫中取出的，這個工作是完全可以交給這些ORM的，最后的結果就是：在DAL中只是操作這些ORM的那些映射實體。基于這個想法， Richard就確定了：AddSingleDataEntity參數是一個數據實體。。因為這些方法最終是操作數據實體的，所以包含這些方法的接口名字就定義為IDataContext。
因為不同的表產生不同的數據實體，但是Richard還想使得AddSingleDataEntity這個方法可以接受任何的數據實體，所以此時很有必要對數據實體進行抽象。所以Richard想到了定義一個接口：IDataEntity,打算讓所有通過ORM生成的數據實體都繼承這個接口。而且Richard還想到：
1. 如果BLL直接引用DAL使用的，那么IDataEntity可能會在BLL中出現的。
2. 如果BLL通過repository去DAL中獲取數據，那么到時候BLL可能都不會直接引用DAL，但是BLL最終還是得使用數據做事情，所以IDataEntity還是會在BLL中出現，所以，IDataEntity接口最好定義在一個公共的地方。
Richard決定新建一個Common的類庫，加入IDataEntity接口的定義，現在這個接口里面什么都沒有，只是一個標記而已，表明繼承這個接口的類就是數據實體類。
AddSingleDataEntity;
還有一點就是盡量的使用類型安全的方法，于是Richard把方法改成了范型方法：
AddSingleDataEntity
至于T 的那些約束：T:IDataEntity,class,new，是考慮到了Linq和EF中對數據實體的一些要求。
没有评论:
发表评论