工厂模式,一种抽象程序设计思想,面向接口(抽象)编程,降低模块间的耦合度、使程序有更好的扩展性,灵活变化。
开发程序的一种思想:“模块内高内聚,模块间低耦合”。
这里简单总结一下自己了解到的抽象工厂。
在我们最初接触到的三层架构,三层是紧紧的强耦合在一起的,UI->BLL->DAL,如:
public AccountDAO dao;
public AccountBLL()
{
this.dao = new AccountDAO();
}
在BLL的构造方法中,我们直接初始化了AccountDAL这个对象,然后再后面的方法中直接使用这个数据访问对象来进行数据的增删改查。
这里,BLL和DAL强耦合在一起了,程序必然的就难以扩展,牵一发动全身,如果AccountDAO改动了,对应的BLL里面全都得改动。
在生活中,也是这样,任何事物紧耦合在一起就容易出问题,而且还难以维护。
比如电脑主板,如果紧紧依赖硬件的品牌,如果硬件坏了,就很难维护,扩展。
面向接口编程,面向抽象,设计应该依赖抽象,而不应该依赖具体的实现,这样一个“零件”坏了,可以很容易维护,扩展。
面向抽象编程,就是在BLL和DAL中间加了一层,解耦他们强耦合(硬编码)的关系。
假设我之前用的ADO.NET方式来实现数据的操作,现在要改成EF的方式来操作数据库,那么在DAL全部都要改动。显然不可靠。
解耦模块间关系,通过接口,接口就是约束类的行为,规范。
1:建立数据访问层的接口(基础):IDAL,里面规范基本的增删改查操作。
2:两种数据库访问方式,方法都是一样,只是具体的实现不一样。ADONET_DAL,EF_DAL,都实现IDAL。
3:通过工厂,根据配置文件来生产对应的数据库操作方式,具体实现交给工厂,外部不用关心工厂内部是怎样实现的。
4:在BLL构造方法中,通过工厂来创建指定的对象,而不是new强依赖对象,当更换数据访问方式的时候直接更换对应的类库就好了,解耦。
UI->BLL->DALFactory->IDAL->IxxDAL->xxDAL
代码示例:
#region 接口规范
//数据访问基础,规范基本的增删改查操作方法
public interface IDAL
{
string GetUserName(string id);
}
//具体业务接口规范,实现基础数据访问接口
public interface IUserInfo : IDAL
{
//扩展
}
#endregion
#region 同样业务,不同实现方式
public class UserInfoADO_DAL : IUserInfo
{
public string GetUserName(string id)
{
return "ADO.NET方式获取数据";
}
}
public class UserInfoEF_DAL : IUserInfo
{
public string GetUserName(string id)
{
return "EF方式获取数据";
}
}
#endregion
#region 工厂 解耦模块间的耦合度
//DAL数据访问层生产工厂
public class DALFactory
{
//获取用户信息实例
public static IUserInfo GetUserInfo()
{
return CreateInstance();
}
//创建对应类的实例
private static IUserInfo CreateInstance()
{
//这里根据程序集去反射动态加载对应的数据库访问实现方式(EF还是ADO.NET)
return new UserInfoADO_DAL();
}
}
#endregion
#region 业务逻辑层
//业务逻辑层
public class UserInfoBLL
{
IUserInfo userDAL;
public UserInfoBLL()
{
//获取用户DAL的实例,交给工厂创建,具体怎样创建的不用关心
userDAL = DALFactory.GetUserInfo();
}
}
#endregion
这样BLL就不再强耦合DAL了,如果需要改动实现方式,只需要改动工厂具体的实现就好了。
这样就很容易维护了,也很容易扩展了。
如有不足之处还请大家多多指正。