說說IUnitOfWork~DbContext對象的創建應該向BLL層公開
第一講 認識IUnitOfWork,為什么要出現IUnitOfWork接口第二講 Linq to Sql與EntityFrameworks中的SubmtChanges()發生了什么事第三講 方法完整性與統一提交不沖突第四講 DbContext對象的創建應該向BLL層公開第五講 我的IUnitOfWork+Repository架構
在EF中,數據上下文通常是DbContext或者ObjectContext,而在linq to sql中數據上下文則是DataContext,它們的作用是建立一個數據庫映射對象ORM,以更加方便的操作數據庫,而它們的創建工作,我在很長一段時間將它約束在DAL層,對BLL層不公開創建方法,但當我對.net了解更多之后,覺得將數據上下文的創建工作公開到BLL層是很有必要的,最起碼在程序性能上及原子化操作上很有必要。
原來我們在BLL層調用一個添加操作時,需要在DAL層先去定義這個實現,即使這個實體只存在一個添加操作,你也要去實現一下,這無疑加大了代碼量,像這樣:
public class ProductRepository : TestBase<Product> { #region Constructors public ProductRepository() { } public ProductRepository(IUnitOfWork db) : base((TestDataContext)db) { } #endregion /// <summary> /// 一個方法,也要建立這個repository,有點壞味道 /// </summary> /// <param name="entity"></param> public override void Insert(Product entity) { base.Insert(entity); } }
而,如果我們將數據上下文創建的工作公開到BLL層,那結果就不一樣了,再配合IUnitOfWork思想,實現在BLL層對DAL方法的整合,實現向數據庫發送一次連接請求,這種感覺,酷D了,呵呵。
public abstract class BLLBase { protected IUnitOfWork IUnitOfWork { get; private set; } public BLLBase() : this(null) { } public BLLBase(IUnitOfWork iUnitOfWork) { IUnitOfWork = iUnitOfWork; } protected ICompleteRepository<T> LoadRepository<T>() where T : class { return IUnitOfWork == null ? new TestBase<T>() : new TestBase<T>(IUnitOfWork); } }
對于BLL層的祖宗,呵呵,BLLBas,它將數據上下文的創建工作在架造方法中注入,然后傳遞給LoadRepository這generic method,在BLL層的業務類中可以
繼承它并為數據上下文進行實例化,再使用LoadRepository直接對數據表進行CURD操作,一切就是這樣簡單,看代碼:
#region BLLBase中直接調用公用方法 IUnitOfWork.IsNotSubmit = true; new OrderRepository(IUnitOfWork).Insert(order); if (product != null) LoadRepository<Product>().Insert(product); IUnitOfWork.SaveChanges(); #endregion
OK,UI層直接調用BLL層的具體業務方法即可,下面我們再來看一個我DAL層的類結構,有時,我越得類結構圖比代碼更能說明問題:
CURD操作規范:
DAL層Repository模式實現:
IUnitOfWork工作單元規范:
浙公網安備 33010602011771號