zend framework 中数据库的多表联查问题

 首先说说废话（不想看废话直接跳到第 5 段）：这次做着项目，开始的时候队友说这简单的系统用什么框架啊!于是也就放着zend没用，直接开始写几乎没设计的代码！项目前期进展速度极慢，一是因为队里没有一个人对PHP很熟。最开始阶段配置PHP运行调试环境就搞了两天（可能也是大家有些拖吧）。两天后，终于配置好了环境，然后按老师的要求，根据敏捷开发方法，进行测试驱动，持续集成，结对编程。也写了backlog。   

       前期的东西都搞的差不多了终于开始写代码了，写啊写，PHP不熟，sql不熟，一个sql写十几次总算勉强成功取出数据，PHP里面超级简单的函数也要依赖Google。队长看到如此速度，很是纠结，于是放话：测试个毛啊！直接写了，这速度。这样我们就放弃了测试驱动。之后还剩下，结对编程，结对编程这东西，确实要结对，不是一个人说结对就能结对的，所以由于奇数原因，结对也很失败，个人来看吧！还是很喜欢结对编程的，不是因为可以偷懒，是因为它真的能省时（写程序大部分时间用在调试上，结对bug少很多）。有的东西不是喜欢就可以做的，无奈结对编程失败。持续集成呢！因为PHP直接运行不需要部署，我们成天都在集成。还有那个backlog，认真想想，如果要管理项目的进度，还是很有用的，还是因为我们的项目不大的原因，项目进度看看代码就知道了。那个也就是应付式的搞搞。 

      经过我们对开发过程的‘个性化’和‘精化’,最终第一个迭代周期到了，拿去给老师评审，老师看到代码结构，严重批评了我们项目的设计，看出来了我们都没设计，没对数据库进行封装，没reuse，应对变更的能力很弱，可维护性低，如此对于现在的需求做起来貌似不难，但是以后系统变复杂以后会变得不可维护。虽然老师一般都是抱着批判的态度来评审的，但是这里也确实说到我们几个很严重的问题，特别是对数据库的封装（嗯。。貌似这里要接近今天讲的主题了）。 

       由于上面的问题，我们决定对代码进行重构，既然重构，那我们还是回到zend的怀抱吧（开始我和yongxiu同学准备用zend）！于是我们在项目中期进行学习，学习zend，因为项目中各部分的逻辑在前期已经做的差不多，重构的主要任务就是把以前的东西和zend的框架融合一下，使得它更加MVC一点，使用zend的提供的数据库相关类，把封装数据库的重任交给了zend。如此，我就开始zend啊zend，最后在zend的多表联查哪里卡住，到网上搜