传统MVC开发模式中的强耦合性问题
在传统的mvc开发模式中,自顶向下会分为:表现层,业务层和持久层。
在类中存在相互的调用关系,比如:表现层调用业务层的对象,业务层会调用持久层的对象。
如下图所示:
如图所示,我们在表现层 new 了一个业务层的对象,在业务层 new 了一个持久层的对象。
这样使得这3个类之间拥有很强的依赖关系(耦合性),没有AccountDaoImpl类或者没有AccoutServiceImpl类都无法使得程序编译成功。
在类之间使用new的方式创建对象,使得他们有极强的耦合性。我们需要降低这种耦合性,提高程序的灵活性。
那么不通过new的方式创建对象,如何创建呢?
我们希望当我们告知了被调用类的全限定类名后,可以获取它的实例化对象,那么我们就可以通过java的反射机制来达到我们的目的。
使用工厂模式降低程序的耦合性
我们实现一个BeanFactory工厂类,来为我们创建我们需要的 AccoutDaoImpl对象和AccountServiceImpl对象。
Bean在计算机英语中,有可重用组件的含义。
JavaBean: 用java语言编写的可重用组件。
javaBean > 实体类
在工厂类中如何创建我们需要的类对象实例呢?
1:需要一个配置文件来配置我们的service和dao。 配置的内容:唯一标识=权限定类名(key=value)
我们创建一个名为bean.properties的配置文件,使用键值对的方式存储数据信息。
2:通过读取配置文件的内容,使用反射机制创建类对象。
我们在BeanFactory类中实现了一个静态getBean函数,通过调用该方法我们就可以得到我们需要的实例对象。
修改表现层和业务层的实现方式,使用工厂模式降低程序将的耦合性
工厂模式的优化:使用单例模式
问题:在上述的实现方式中,当我们每次重新调用BeanFactory.getBean()方法时,工厂都会重新为我们创建一个新的对象。例如运行下列代码,会生成两个对象,结果如下:
但我们其实只需要一直使用一个ServiceImpl和DaoImpl对象即可。
所以我们可以将工厂类的实现改为单例模式。我们在读取到配置文件中的信息后,首先一次性的将所有需要的对象创建出来,将创建好的对象存在一个Map集合中,然后在需要时,只需要从Map在取值即可。
再次运行上面的测试代码,对得到如下结果。
传统方式和工厂模式方法的对比图
在传统模式中:应用程序和资源之间是直接的关联关系。应用程序需要自己创建(new 对象)资源。主动的
在工厂模式中:应用程序不在直接和资源相关联,而是只用工厂提供的资源。被动的