[原創].NET 業務架構開發實戰之六 DAL的重構

.NET 業務架構開發實戰之六 DAL的重構
　　前言：其實這個系列還是之前的".NET 分布式架構開發實戰 ",之所以改了名字，主要是因為文章的標題帶來了不少的歧義：系列文章中本打算開發一個簡化業務發的流程的Framework,然後用這個Framework再來實戰，開發一個分布式的應用。改了名字。給大家帶來了不便，敬請見諒。

 　　本篇的議題如下：
 　　1. 確定DAL的介面的定義。

 

　　系列文章連結:

 [原創].NET 分布式架構開發實戰之一 故事起源

[原創].NET 分布式架構開發實戰之二 草稿設計

[原創].NET 分布式架構開發實戰之三 資料訪問深入一點的思考

[原創].NET 分布式架構開發實戰之四 構建從理想和實現之間的橋樑(前篇)

[原創].NET 分布式架構開發實戰五 Framework改進篇

[原創].NET 業務架構開發實戰之六 DAL的重構

[原創].NET 業務架構開發實戰之七 業務層初步構想

[原創].NET 業務架構開發實戰之八 業務層Mapping的選擇策略

[原創].NET 業務架構開發實戰之九 Mapping屬性原理和驗證規則的實現策略

[原創].NET 業務架構開發實戰之十 第一階段總結，深入淺出，水到渠成（前篇）

[原創].NET 業務架構開發實戰之十 第一階段總結，深入淺出，水到渠成（後篇）

 

 

 

 　　之前在開發DAL中，提出了一些思想，也設計了一些介面。現在就把DAL的一些設計完善起來。說是“完善”，並不是說把所有的代碼都實現，而是把該定義的介面，方法敲定下來。Richard認為，設計一個架構或者Framework的時候，開始是介面的定義，定義好各層之間互動的介面，然後才是具體代碼的實現。

 　　因為在設計Framework的時候，首先要考慮這個Framework的使用者是誰，希望他們怎麼樣來使用開發出來的這個Framework。在這裡，Richard很明白：Framework的使用者就是自己公司裡的開發人員。而且還要使得開發的使用盡量的方便，不要到處去配置一些文檔，最好就是把Framework引入進來，稍微配一下就使用。

 

　　在Richard設計的Framework中，就DAL而言，如果希望DAL返回DataTable,DataReader等給BLL，那麼需要配置的僅僅只是指明資料庫的連接字串；如果希望DAL返回的資料實體給BLL,那麼就得把一張張的表映射成為實體，然後讓這些實體繼承IDataEntity介面就行了(產生實體可以用ORM工具，或者自己手寫代碼)。

 Richard思考了之前對DAL的設計，在此他做了一些改進。

 　　首先就是對於IDataContext的重新設計和理解：之前的設計是定義了IDataContext,然後用不同的方式實現這個介面，如LinqDataContext.Provider就是用Linq的方法來返回結果(DataResult)。現在Richard認為IDataContext其實就是用來操作資料庫的，所以返回的結果就應該是操作資料之後的結果，如Update操作就返回受影響的行數或者是否更新成功。至於是否要把一些額外的資訊封裝返回給BLL，就不是IDataContext的實現者的事情了。而且Richard還考慮到了需要在一定程度上支援原生的ADO.NET，起碼給ADO.NET預留介面。

 

 　　基於此，Richard就把IDataContext定義為一個介面聲明，然後再定義了IDataEntityContext，和IDataTableContext來繼承IDataContext,他們的關係圖如下：

　　

　　

　　 其中IDataEntityContext使用Linq和Entity Framework來實現，而IDataTableContext就是用ADO.NET的方式來實現。

  　　IDataEntityContext介面的和系列文章中定義的一些方法差不多，但是做了修改。其中有一點要提的就是：ICriteria就是所有條件對象要實現的介面(查詢對象也是條件對象的一種)。例如，可以根據相應的條件刪除，更新資料。

 

代碼

 /// <summary>
    /// 所有的資料實體執行者實現這個借口
    /// </summary>
    public interface IDataEntityContext:IDataContext
    {
        TEntity Add<TEntity>(TEntity entity) where TEntity : IDataEntity;
        List<TEntity> Add<TEntity>(List<TEntity> entityList) where TEntity : IDataEntity;

        bool Update<TEntity>(TEntity entity) where TEntity : IDataEntity;
        bool Update<TEntity>(List<TEntity> entityList) where TEntity : IDataEntity;
        bool Update(ICriteria condiftion, object value);

        bool Delete<TEntity>(TEntity entity) where TEntity : IDataEntity;
        bool Delete<TEntity>(List<TEntity> entityList) where TEntity : IDataEntity;
        bool Delete(ICriteria condition);

        int GetCount(ICriteria condition);
        List<TEntity> Query<TEntity>(ICriteria condition);
        List<TEntity> Query<TEntity>(ICriteria condition, int pageIndex, int pageSize, ref int entityCount) where TEntity : IDataEntity;
        List<object> Query(ICriteria condiftion);
    }

 

 

 　　另外就是多了一個 List<object> Query(ICriteria condiftion);方法，之所以有這個方法，Richard考慮到，可能開發人員想要直接自己寫SQL語句去執行，如select avg(Count),sum(Name) from Customer...，開發人員可以寫任意的語句，所以返回一個實體類不現實，就返回一個List<object>。

 

 　　還有一點就是關於查詢對象的改進：以前僅僅只是定義了查詢對象的介面，現在用ICriteria 介面中定義來條件對象，而且還可以在條件對象聲明是在對資料操作是否採用事務或者緩衝。

代碼

 /// <summary>
    /// 所有的條件對象都要從這個介面繼承
    /// </summary>
    public interface ICriteria
    {
        string Name { get; set; }
        bool IsCache { get; set; }
        bool IsTransaction { get; set; }
    }

 

 　　

　　之後Richard又定義了一個IDataProvider，介面，聲明如下 ：

 

代碼

 /// <summary>
    /// 資料提供者要實現的借口
    /// </summary>
    public interface IDataProvider
    {
        DataResult<TEntity> Add<TEntity>(TEntity entity) where TEntity : IDataEntity;
        DataResult<TEntity> Add<TEntity>(List<TEntity> entityList) where TEntity : IDataEntity;

        DataResult<TEntity> Update<TEntity>(TEntity entity) where TEntity : IDataEntity;
        DataResult<TEntity> Update<TEntity>(List<TEntity> entityList) where TEntity : IDataEntity;
        bool Update(ICriteria condiftion, object value);

        DataResult<TEntity> Delete<TEntity>(TEntity entity) where TEntity : IDataEntity;
        DataResult<TEntity> Delete<TEntity>(List<TEntity> entityList) where TEntity : IDataEntity;
        bool Delete(ICriteria condiftion);

        int GetCount(ICriteria condition);

        DataResult<TEntity> GetOne<TEntity>(ICriteria condition) where TEntity : IDataEntity;
        DataResult<TEntity> GetList<TEntity>(ICriteria condition) where TEntity : IDataEntity;
        DataResult<TEntity> GetPageData<TEntity>(ICriteria condition, int pageIndex, int pageSize, ref int entityCount) where TEntity : IDataEntity;
        List<object> GetCustomData(ICriteria condiftion);
    }

 

 

　　 之所以要定義這個介面，其實 Richard就是想讓實現了IDataContext的類踏踏實實的去做底層的資料操作，至於資料操作之後的結果以什麼形式給BLL，不用IDataContext的實現者來關心，而是用IDataProvider的實現者來關心。

 　　在IDataProvider的實現者在底層就是調用了IDataContext的實現者的方法，然後在IDataProvider中，對外提供了一些更加友好和方便使用的方法，最後在BLL中直接依賴的就是IDataProvider，而不是IDataContext。

 　　另外，對於IDataProvider返回的DataResult也做了一些修改：如果返回的是資料實體，即 使用的是IDataEntityContext來提供底層的資料操作，那麼DataResult<TEntity>是沒有問題的；但是如果使用的是IDataTableContext，那麼返回DataResult<TEntity>就不行了，因為IDataTableContext查詢方法可能返回的DataTable,或者DataReader.所以，在設計中葉預留了一個介面：讓IDataProvider返回的結果實現IDataResult介面，那麼ataResult<TEntity>繼承這個介面，主要用來返回資料實體，如下：
 

 　　

　　DAL的設計就到這裡，下一篇文章就開始講述對業務層的一些思考。

　　著作權為小洋和部落格園所有，轉載請標明出處給作者。

　　  http://www.cnblogs.com/yanyangtian

　　 代碼下載