Fast Lane Reader
抛弃EJB，加速只读数据的存取。
有些时候，高效地存取数据比获得最新的数据更重要。在Java Pet Store中，当一个用户浏览商店的目录时，屏幕与数据库内容吻合不是至关紧要的，相反，迅速显示和重新获得非常重要。FLR模式可以加速从资源中重新获得大型的列数据项的速度，它不用EJB，而是更直接地通过DAO来存取数据，从而消除EJB的经常开支（例如远程方法调用、事务管理和数据序列化等）。
在Java Pet Store这个例子中，当一个用户浏览目录时，通过CatalogDAO（而不是CatalogEJB）从数据库加载数据项，而CatalogDAO是一个Fast Lane Reader的实例，使得读访问变得迅速，如图4：
图4 Fast Lane Reader设计模式 （图片较大 请放大查看）
与DAO模式不同的是，FLR是一个优化的模式，但不是要替代原有的访问机制，而是作为补充使其完备。当你频繁地只读大型的列数据和不必存取最新的数据时，使用FLR将是非常合适的。
Page-by-Page Iterator
为了高效地存取大型的远程数据列，一下子通过重新获得其元素为一个子列的Value Object（提高远程传输效率的设计模式，这儿不详尽描述）。
分布式数据库的应用经常需要用户考虑一长列数据项，例如一个目录或一个搜索结果的集合。在这些情况下，立刻提供全列的数据经常不必要（用户并不是对所有的数据项感兴趣）或不可能（没有足够的空间）。此外，当重新获得一列数据项时，使用Entity Bean的代价将非常高昂，一个开销来自于使用远程探测器来收集Requested Bean，另外，更大的开销来自对每个Bean产生远程调用以从用户获得数据。
通过Iterator，客户机对象能一下子重新获得一个子列或者页的Value Object，每一页都刚好满足客户机的需求，因此，程序使用较少的资源满足了客户机的立刻需求。
在Java Pet Store这个例子中，JSP页面product.jsp任何时候只显示一个数据列的一部分，从ProductItemListTag（Page-by-Page Iterator）重新获得数据项，当客户机希望看到列中的别的数据项，product.jsp再次调用Iterator重新获得这些数据项，流程见图5：
图5 Page-by-Page Iterator设计模式 （放大查看）
以上设计模式的应用向我们表明，在某些特殊情况下，优化对数据库的访问模型，既可满足用户的需求又可提高访问数据库的效率。这给我们一个思路，就是：在你的硬件环境可能会产生瓶颈的情况下，可以通过对软件模型的优化来达到满足需求的目的。上述三种设计模式的应用情形为：
| Data Access Object | 需要将商业逻辑和数据存取逻辑分离； 在调度的时刻，需要支持选择数据源的类型； 使用的数据源的类型的变化，对商业对象或其它客户端完成数据存取没有影响。 |
| Fast Lane Reader | 面对大型的列数据，需要经常的只读访问； 访问最新的数据并不是至关紧要的事情。 |
| Page-by-Page Iterator | 存取大型的服务器端数据列； 任何时刻，用户只对列的一部分内容感兴趣； 整个列的数据不适合在客户端显示； 整个列的数据不适合在存储器中保存； 传输整个列的数据将耗费太多的时间。 |
在显示商品目录的时候，我们选择了DAO和FLR的结合，因为它们两者的条件都得到了满足（需要分离商业逻辑和数据存取逻辑，经常的只读访问和对即时性不敏感），此时应用将会大大发挥它们的优点。而在进行内容检索的时候，我们会选择PPI，因为也许检索出了上千条的记录，但是用户没有兴趣立即阅读全部内容，而是一次十条地阅读，或者他在阅读完前十条记录后发觉自己的目的已经达到，接下来浏览别的网页了，都不必我们一次性地传输上千条记录给他，所以也是PPI的应用条件得到了满足，结果则是此模式的优点得到了发挥，又不影响全局的数据访问。
在进行软件模型的设计时，整体的框架可以应用某些优秀的、通用的设计模式，这样既加快模型的建立速度，又能和其它系统集成。但是，碰到一些瓶颈问题的情况下，我们就需要对局部的设计模式做一些调整，以优化整个系统，上述三个模式就是对原有体系的补充，它们并没有对整体的框架做出巨大的改变，却突破了某些瓶颈（瓶颈往往是局部的）障碍，让我们的产品更好地服务于用户。
将深入研究的问题
开篇至今，我们主要探讨了软件层次上的解决问题，但是，必须肯定一点，如果你的硬件环境非常差（运行Java都有困难）或非常好（额外的存储空间、超快的运算速度和富裕的网络带宽），上述途径对你来说很难有大的帮助。前一种情况，我建议你升级硬件设备到软件厂商推荐的配置（强烈反对最小配置），以使应用服务器、数据库、Java等软件能够运行自如；后一种情况，我没什么话可说，花钱是解决这个问题最好的办法。
本文并未谈及线程池和告诉缓冲这两个非常重要的概念，因为笔者认为，它们是针对局部时间高访问量的瓶颈问题的解决，不能理解为简单的速度瓶颈问题，所以我会在下一篇文章中分析这种特殊的情况和提出解决问题的办法。也许你对这一点更关心一些，认为自己的问题就出在这个地方，这是非常好的思考问题的方式，你已经抓住了问题的关键。但是，我还是建议你通读一下本文，让自己对速度瓶颈问题有更好的理解，并掌握在解决问题的过程中，分辨常态和暂态，从而选择不同的思路入手。其实，本文谈及的就是速度瓶颈问题的常态，而下一篇文章讨论的将会是暂态，希望你能够渐入佳境。
JDO（Java Data Object）是需要我们关注的一个API，它定义了新的数据存取模型，直接借鉴了DAO设计模式。不同的数据源，有不同的数据存取技术，就有不同的API供开发人员使用。JDO正是为了解决这个问题而产生的，它实现了即插即用的数据存取的实现和持久信息（包括企业数据和本地存储的数据）以Java为中心的视图。因此，开发人员只关注创建那些实现商业逻辑的类和用它们来表现数据源的数据，而这些类和数据源之间的映射则由那些EIS领域的专家来完成。如果大家对JDO感兴趣的话，那么我会写第三篇文章把其详细介绍给大家，并给出示例应用。
文章来源于领测软件测试网 https://www.ltesting.net/
