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

关于.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，易出错，细心一点儿就行了。以上...