asp.net 项目整体框架简单的搭建

关于数据库访问层

数据库访问驱动层--大家都知道EF,NH跟Ado.net或者你自己实现的,这些都是为我们访问数据库或对数据库操作建立了桥梁,当然数据库也可能是不同的数据库,这些都是根据项目需求来定的,至于选择哪个则要视情况而定了.这里我就用了EF--model-first.我是直接在edmx里面设计模型,然后生成实体跟数据库,具体如下,做了个简单的权限管理(还没完全实现)..

 

复制代码 代码如下: public class BaseRepository<T>:IDAL.IBaseRepository<T> where T:class { private DbContext container = EFContentFactory.GetCurrentContext(); #region 增加 public T AddEntity(T entity) { container.Set<T>().Add(entity); return entity; } #endregion #region 删除 public bool DeleteEntity(T entity) { container.Set<T>().Attach(entity); container.Entry(entity).State = EntityState.Deleted; return true; } #endregion #region 修改 public bool UpdateEntity(T entity) { container.Set<T>().Attach(entity); container.Entry(entity).State = EntityState.Modified; return true; } #endregion #region 查询 public IQueryable<T> GetEntities(Func<T, bool> lambdaWhere) { IQueryable<T> entities = container.Set<T>().Where(lambdaWhere).AsQueryable(); return entities; } #endregion #region 分页 public IQueryable<T> GetEntitiesByPageIndex<TS>(int pageIndex, int pageSize, out int totalCount, Func<T, bool> lambdaWhere, Func<T, TS> orderByRole, bool descending) { var temp = container.Set<T>().Where(lambdaWhere).AsQueryable(); totalCount = temp.Count(); if (descending) { temp = temp.OrderByDescending(orderByRole) .Skip(pageSize * (pageIndex - 1)) .Take(pageSize).AsQueryable(); } else { temp = temp.OrderBy(orderByRole) .Skip(pageSize * (pageIndex - 1)) .Take(pageSize).AsQueryable(); } return temp; } #endregion }

到这一步我以为自己的数据库访问层写完了,然后可以去写业务逻辑层的东西了,实则不然,想想看,如果你要换数据库,或者换成ef或者ado.net 如果按老一套,则整个项目的每一个层都需要去替换,大大的增加了工作量,这里我们可以做个手脚,把数据访问层再给它抽象出一层来,这就需要用到接口了. IDAL.IBaseRepository<T>大体想想看我们的bll层如果没有接口我们直接这么写 dal.xxrepository=new xxrepository();老一套的写法,则跟我前面说的一样,可维护性替换性大大降低..我们现在可以这么写 IDAL.xxrepository=new xxrepository().这样我们替换DAL层时候 BLL层根部不需要关心你到底是怎么实现的.这一点非常的重要.接口就相当于一个契约,约束了你必须实现哪些功能,我们如果要增加功能可直接在接口中增添,接口需要为部分接口,如我给出的上面代码一样,基类需要一个接口,子类也需要.这样我们就抽象出一个数据库接口层.

抽象工厂与简单工厂

我们还可以对业务层跟数据库访问层再读的抽象出来,这里我们就需要用到工厂--其实很简单,从工厂类里面取出来的dal层的类并返回IDAL的接口 复制代码 代码如下: public static class ShopDaoFactory { public static IUserInfoRepository UserInfoRepository { get{return new UserInfoRepository();} } public static IRoleRepository RoleRepository { get{return new RoleRepository();} } }

那么业务层拿到接口时也不需要关心到底怎么实现的,这样又是一层的抽象,当然你也可以用抽象工厂,利用反射跟配置外加缓存来实现,不过一般情况下简单工厂足够了,这里就相当于一个数据库访问层的入口了.

业务逻辑层的基类与子类　

当我们实体模型多了的时候我们如果没有基类,则要写一堆重复性的东西,我们现在就要把这些重复的性的东西放到基类里面给我们实现,如同Dal层,我们定义了一个基类,但是在BLL层我们会遇到一个问题,IDAL.IBaseRepository<T>怎么获取从工厂获得接口了......思考一下.....我们的子类可以知道自己所需要的接口------我们可以做个手脚,让父类为抽象类,定义一个抽象方法,然后让子类重写改方法,并且在构造函数里面调用,因为我们必须用到这个接口,所以必须在构造函数里面 复制代码 代码如下: public abstract class BaseService<T> :IBLL.IBaseService<T> where T:class, new () { public BaseService() { GetInstance(); } protected IDAL.IDbSession _DbSession = DbSeesionFactory.GetSession(); protected IDAL.IBaseRepository<T> CurrentRepository { get; set; } public abstract void GetInstance(); public IQueryable<T> GetEntities(Func<T, bool> lambdaWhere) { //_DbSession.SavaChanges(); return CurrentRepository.GetEntities(lambdaWhere); } public bool DeleteEntity(T entity) { CurrentRepository.DeleteEntity(entity); return _DbSession.SaveChanges() > 0; } public bool UpdateEntity(T entity) { CurrentRepository.UpdateEntity(entity); return _DbSession.SaveChanges() > 0; } public T AddEntity(T entity) { var en = CurrentRepository.AddEntity(entity); _DbSession.SaveChanges(); return en; } public IQueryable<T> GetEntitiesByPageIndex<TS>(int pageIndex, int pageSize, out int totalCount, Func<T, bool> lambdaWhere, Func<T, TS> orderByRole, bool descending) { return CurrentRepository.GetEntitiesByPageIndex(pageIndex, pageSize, out totalCount, lambdaWhere, orderByRole, descending); } } }

其他的业务层也需要接口抽象出一层出来来作为约束,这样ui层也不需要关心你业务层怎么实现... 另外一种实现数据库入口的方试DBSession

我们先看一个类,dbsession里面有属性,为接口,对应的该接口所对应的实现类,两个方法SaveChanges(),与exesql(EF用的5.0+),里面返回的是当前EF线程类上下文的savechange()与执行sql语句的放回值,怎么才能确保当前进程内EF上下文只有一个了,我们看另外一个类. 复制代码 代码如下: public partial class DbSession:IDAL.IDbSession { #region 代码生成器生成 //public IDAL.IRoleRepository RoleRepository //{ // get { return new RoleRepository();} //} //public IDAL.IUserInfoRepository UserInfoRepository //{ // get { return new UserInfoRepository();} //} #endregion public int SaveChanges() { return EFContentFactory.GetCurrentContext().SaveChanges(); } public int ExcuteSql(string strSql, System.Data.Objects.ObjectParameter[] parameters) { return EFContentFactory.GetCurrentContext().Database.ExecuteSqlCommand(strSql, parameters); } } public class EFContentFactory { public static DbContext GetCurrentContext() { DbContext obj = CallContext.GetData("DbContext") as DbContext; if (obj==null) { obj = new Model.DataContainer(); CallContext.SetData("DbContext",obj); } return obj; } }

CallContext 是类似于方法调用的线程本地存储区的专用集合对象，并提供对每个逻辑执行线程都唯一的数据槽。数据槽不在其他逻辑线程上的调用上下文之间共享,这是从msdn上截取的一段话,它有几个方法,这里面我们用到setdata跟getdata,来确保上下文线程内唯一,同样的我们让他接口化,与工厂内实现下-- 复制代码 代码如下: public class DbSeesionFactory { /// <summary> /// 保证线程内dbsession唯一 /// </summary> /// <returns></returns> public static IDAL.IDbSession GetSession() { IDAL.IDbSession _dbSession = CallContext.GetData("DbSession") as IDbSession; if (_dbSession == null) { _dbSession = new DbSession(); CallContext.SetData("DbSession", _dbSession); } return _dbSession; } }

业务层的子类重写方法时这么来实现,同样基类加个: protected IDAL.IDbSession _DbSession = DbSeesionFactory.GetSession(); 复制代码 代码如下: public partial class ActionInfoService:BaseService<ActionInfo>,IBLL.IActionInfoService { public override void GetInstance() { CurrentRepository = _DbSession.ActionInfoRepository; } }

public partial class R_UserInfo_ActionInfoService:BaseService<R_UserInfo_ActionInfo>,IBLL.IR_UserInfo_ActionInfoService { public override void GetInstance() { CurrentRepository = _DbSession.R_UserInfo_ActionInfoRepository; } }

public partial class RoleService:BaseService<Role>,IBLL.IRoleService { public override void GetInstance() { CurrentRepository = _DbSession.RoleRepository; } }

为什么要这么做了?当我们用EF的时候比如一个方法里面要操作多个表,就不断的需要用到上下文,这样可以帮我们剩不少事最后直接来个_dbsession.savechange().可以达到批量删除修改等等操作.具体看我,今天做了个批量删除的 复制代码 代码如下: public int DeleteUsers(List<int> list) { foreach (var i in list) { _DbSession.UserInfoRepository.DeleteEntity(new UserInfo() {ID = i}); } return _DbSession.SaveChanges(); }