阜新市违章查询,广州二本大学排名,海边发现奇石 伸手触摸瞬间悲剧
最近刚学了些关于asp.net mvc方面的知识,于是了要拿个小项目来练练手,提高下自己的code能力跟思维能力.在此之前做东西都很简单,直接用动软那一套生成代码,生成一个简单的三层架构作为项目整体的框架,数据库访问层用的是ado.net.这么做了感觉挺麻烦,如果要项目要换数据库,要给数据库增加表或者给表增加某个字段,或者不使用ado.net用个orm框架来访问数据库等等,这样整体项目该动起来就提别的麻烦,为了解决这一些问题我们需要重新思考怎么搭建.
关于数据库访问层
数据库访问驱动层--大家都知道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();
}
好困,把这几天学习的东西总结了下还是收获不少,虽然对里面有些东西不是非常的理解,慢慢看看就领悟了,分享给大学一同学习~
如对本文有疑问，请在下面进行留言讨论，广大热心网友会与你互动！！
点击进行留言回复
我要评论
网友评论