在图表6的设计中，表示层不通过facade而直接调用域对象，Spring AOP仍然提供服务，例如事务处理管理和安全。
用这种实现途径的一个重要的好处是，业务层不需要知道哪些对象需要调用，也不用知道那些需要返回给表示层。尽管这挺起来很简单，但是你会发现一些缺点。这会增加表示层的复杂度，因为你必须处理对数据库的连接。而且在基于Web的应用程序中，事务处理管理也要非常小心，因为在表示层将数据反馈给浏览器之前，事务处理的数据必须保持正确。
决策3：访问数据库
无论你怎样对业务逻辑怎样的组织和封装，最终你还是要从数据库中取数据出来。在经典的J2EE应用程序中，你有2个选择：JDBC——这个需要很多的底层代码;或者实体Bean——这个用起来非常困难，而且缺少重要特征。相比来说，使用轻量级构架令人高兴的事情之一就是：你有一些新的而且更有力的方法去访问数据库，而且这种方法可以显著的减少访问数据库的代码。让咱们来进一步研究。
直接用JDBC会有什么问题
最近突然出现了对象/关系 映射构架(比如JDO和Hibernate) 和SQL映射构架(比如iBATIS)这些不是凭空出现的。相反，他们是在JAVA 联盟在JDBC屡造挫折之后才出现的。为了了解新构架出现的原因，这里咱们回顾一下直接使用JDBC会出现的问题。在许多程序中直接使用JDBC不是一个好的选择，主要有以下三个原因：。 开发和维护SQL非常的困难而且耗费时间——一些开发者发现要写庞大而且复杂的SQL语句非常的困难。反映数据库变化的SQL语句会变得非常耗时。你必须小心的考虑牺牲可维护性是否值得。。 用SQL会使移植性变的很差——因为需要数据库的特殊SQL语句。如果一个程序和多个数据库有关系，那么你就要写多个版本的SQL语句，这使得可维护性变变成噩梦。。 直接写JDBC代码要会非常耗时，而且容易出错。你必须写很多的样板代码去获得连接，创建和初始化适当的声明，还要用精确的声明去清理连接。而且你还要写代码去将JAVA 对象映射到SQL声明。由于要无奈的去写，JDBC代码很容易出错。
如果你的程序必须直接运行SQL语句的话，那前面两个问题是无法避免的。有时候为了获得好的性能，必须要全力的写SQL语句，包括供应商提供的那些特殊东西。由于许多业务上的原因，持久层可能会产生混乱的SQL语句，为了防止这种情况，DBA可能要求你的程序来完全控制SQL语句的执行。通常，团队买进的关系型数据库过于庞大，以至于应用程序工作时会出现一些和数据库有关的琐碎事务。根据“iBATIS in Action”的作者说这里会有一种情况出现：“数据库或者SQL语句本身存在的时间比程序代码存在的时间还要长，或者同一段SQL语句或数据库有多个程序的版本。有些情况下，程序已经用另外一种语言重写了，但是SQL语句和数据库却没有太大的改变。” 如果直接使用SQL弄的你筋疲力尽，那么很幸运，这里有一种直接执行SQL语句的构架，它可比用JDBC要容易多了。当然了，这就是iBATIS.
使用iBATIS
我开发过的所有企业JAVA应用程序，都是直接执行SQL语句的。早期的程序是执行特定的SQL语句的，后来是用持久层构架再用少量的SQL语句构成的。一开始我直接用JDBC来执行SQL语句，但是后来，我经常写一些小的构架去完成JDBC中那些比较无聊的部分。我也用过一段Spring的JDBC类，这些类除去了JDBC中的许多样板代码。但是无论是我自己写的构架还是使用Spring的类，在Java类映射到SQL语句的时候都会存在问题，这就是我为什么那么高兴的加入iTATIS 那边的原因了。
iBATIS 不仅将应用程序完全的与“数据库连接”、具体的SQL语句隔绝开来，更实现了通过XML描述文档来将JavaBean 映射到SQL语句。它用Java bean 内省机制来将“道具bean(bean properties)”映射为相应的数据库语句占位符，而且它可以将ResultSet后的结果构造为bean.它还可以通过数据库生成主键，自动加载相关的对象、实现缓存和lazy loading.这样，iBATIS 就除去了许多执行SQL语句带来的苦差。通过编辑XML描述文档和调用少量的iBATIS的API，代替了写大量的JDBC底层代码。
文章来源于领测软件测试网 https://www.ltesting.net/
