电脑桌面
添加小米粒文库到电脑桌面
安装后可以在桌面快捷访问

关于.NET的MVC工厂模式各层间调用关系VIP专享VIP免费

关于.NET的MVC工厂模式各层间调用关系_第1页
关于.NET的MVC工厂模式各层间调用关系_第2页
关于.NET的MVC工厂模式各层间调用关系_第3页
关于.NET的MVC工厂模式各层间调用关系就是连同工厂、接口、控制层、全部在一起的MVC模式。普通的三层结构:UI/BLL/DAL,数据实体使用Model封装。这种“三层结构”之间是顺序的调用关系,UI调用BLL,BLL将操作组织并安排DAL层,DAL层操作数据库,每层之间的关系都很紧密,所以协同开发时互相的依赖性较强,项目结构耦合度大。基于高内聚低耦合的原则,层和层之间的调用考虑引入接口IDAL进行规范和分割。BLL层要求DAL层实现的功能先定义好接口IDAL,BLL层就可以借用这些接口去完成业务流程,不必关心实现细节。而DAL层只需要按照IDAL接口中的定义的操作分别实现,就可以满足BLL的要求。这样,使用接口对层和层之间的调用实现分离,设计时都互相不需要了解细节,而在程序运行时,只需要让BLL层的接口引用指向对应的实际DAL对象,程序自然调用实现好的DAL中的功能。程序通过接口实现了更灵活的分层,但毕竟接口引用哪个DAL层对象还是要在BLL层进行管理。在数据库表很多,DAL对象也就会很多的情况下,BLL层中关于DAL的管理也需要很多工作,如何管理更方面?工厂模式。工厂模式,顾名思义,就是生产某件产品的场所,在程序中起到的也是类似的功能,作用就是生产各式各样的DAL对象。这样,BLL层在需要接口的引用指向对应的DAL对象的时候,只需要向工厂要就行了,具体是如何产生的那个对象,BLL不需要关心。这个框架中,DALFactory工厂起到的作用就是生产各种DAL产品,交给BLL层使用,如果需要修改某个DAL的应用,只需要在工厂中修改,BLL依旧还是向工厂要对应的产品即可。示例代码:·BLL层:publicclassUserService{privateIUserManagerium=DALFactory.CreateUserManager();}·DALFactory层:publicclassDataAccess{publicstaticIUserManagerCreateUserManager(){returnnewUserManager();}}·DAL层:publicclassUserManager{......}这样,工厂在程序当中就起到装配的作用,将DAL层的对象装备到BLL层中使用。以上是简单工厂的模型,如果考虑程序的数据库需要在SQLServer和Oracle之间切换的话,就很有可能需要SQLDAL和OracleDAL两套数据访问层。因为以前已经引入的接口,各种数据库无非就是不同的实现IDAL层的方式而已,对BLL层没有影响。如果切换数据库的话,工厂中的各个Create方法中需要返回的对象,就必须改成不同的SQL和Oracle对象。比如:returnnewSQLUserManager();或者returnnewOracleUserManager();切换数据库时,工厂中的所有DAL对象都需要变成另外一类,数量大的情况下,修改也是相当费力,所以,一般考虑数据库切换一个或多个的情况下,在设计工厂中Create方法时,会使用:publicclassDataAccess{privatestaticstringdbName="SQL";publicstaticIUserManagerCreateUserManager(){if(dbName=="SQL")returnnewSQLUserManager();if(dbName=="Oracle")returnnewOracleUserManager();}}通过一个字符串的判断,确定当前需要的DAL对象类型,维护时,只需要修改dbName就可以实现切换。这样做的好处显而易见,但问题也同样存在。如果现在需要另一种Access数据库的切换,肯定需要再加一条:if(dbName=="Access")returnnewAccessUserManager();DAL对象很多,需要加的就很多,还是很麻烦。这时大家可能发现,各种数据库对应的UserManager()的区别就在一个名字上,而且格式很规范,如何根据名字动态产生对应的数据库DAL对象呢?反射!反射的机制允许程序在编译时不知道某些代码的存在,而在运行时动态访问内存中的代码,灵活性可想而知。代码变成:publicclassDataAccess{privatestaticstringpath="UserMIS.SQLDAL";privatestaticstringdbName="SQL";publicstaticIUserManagerCreateUserManager(){return(IUserManager)Assembly.Load(path).CreateInstance(path+"."+dbName+"UserManager");}}所有的判断都是在运行时由反射机制实现的,其灵活性可谓无敌,某天需要加入Access数据库操作的DAL一系列对象,只需要在设计时实现IDAL接口,命名规范。切换数据库时,在DALFactory中修改path和dbName即可。其缺点1,反射的效率低,不过现在的电脑,这点可以忽略;缺点2,易出错,细心一点儿就行了。以上...

1、当您付费下载文档后,您只拥有了使用权限,并不意味着购买了版权,文档只能用于自身使用,不得用于其他商业用途(如 [转卖]进行直接盈利或[编辑后售卖]进行间接盈利)。
2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。
3、如文档内容存在违规,或者侵犯商业秘密、侵犯著作权等,请点击“违规举报”。

碎片内容

确认删除?
VIP
微信客服
  • 扫码咨询
会员Q群
  • 会员专属群点击这里加入QQ群
客服邮箱
回到顶部