标签：style blog class code java tar
使用了4年的IRepository数据仓储接口,今天要改变了,对于这个数据仓储操作接口,它提倡的是简洁,单纯,就是对数据上下文的操作,而直正的数据上下文本身我们却把它忽略了,在我的IRepository接口里根本没有数据上下文对象,这是不完整的,也许你会说,我使用了基类,数据基类里有数据上下文,是的,我也是那样用的,但有时,这种方法有些死板了,真的,当你碰到IOC时,这种方式的短板就出来了,即,每个反射出来的Repository对象都是独立的,每个对象里的上下文也都是独立的,这是重点,由于上下文是独立的,所以,很多事我们都没法干,这包括<JOIN关联查询,非MSDTC的事务>,看了上面的这么多原因,所以,才决定,扩展我的IRepository接口,当然,严格说,这违背了面向对象的原则,接口不提倡扩展,只提倡新建,呵呵.
全新的IRepository接口
/// <summary> /// 基础的数据操作规范 /// </summary> /// <typeparam name="TEntity"></typeparam> public interface IRepository<TEntity> where TEntity : class { /// <summary> /// 设定数据上下文,它一般由构架方法注入 /// </summary> /// <param name="unitOfWork"></param> void SetDbContext(IUnitOfWork unitOfWork); /// <summary> /// 添加实体并提交到数据服务器 /// </summary> /// <param name="item">Item to add to repository</param> void Insert(TEntity item); /// <summary> /// 移除实体并提交到数据服务器 /// 如果表存在约束，需要先删除子表信息 /// </summary> /// <param name="item">Item to delete</param> void Delete(TEntity item); /// <summary> /// 修改实体并提交到数据服务器 /// </summary> /// <param name="item"></param> void Update(TEntity item); /// <summary> /// 得到指定的实体集合（延时结果集） /// Get all elements of type {T} in repository /// </summary> /// <returns>List of selected elements</returns> IQueryable<TEntity> GetModel(); /// <summary> /// 根据主键得到实体 /// </summary> /// <param name="id"></param> /// <returns></returns> TEntity Find(params object[] id); }
在 DbContext数据基类中的实现
public void SetDbContext(IUnitOfWork unitOfWork) { this.Db = (DbContext)unitOfWork; this.UnitWork = unitOfWork; }
在IOC中的使用
IUnitOfWork db; IRepository<Question_Info> question_InfoRepository; public EFController() { //反射出仓储对象 db = ServiceLocator.Instance.GetService<IUnitOfWork>(); question_InfoRepository = ServiceLocator.Instance.GetService<IRepository<Question_Info>>(); //为仓储对象设置上下文 question_InfoRepository.SetDbContext(db); }
在写JOIN查询时,它是被支持的,因为它的数据上下文是同一个
EF架构~豁出去了,为了IOC,为了扩展,改变以前的IRepository接口,布布扣,bubuko.com
EF架构~豁出去了,为了IOC,为了扩展,改变以前的IRepository接口
标签：style blog class code java tar
原文地址：http://www.cnblogs.com/lori/p/3716374.html
