项目进行到现在遇到的阻滞越来越大，我个人认为，与我们采用的框架有关。
我们所采用的框架是参考于微软的PetShop3，该框架是一个五层的架构，从底至上为数据操作层DAL，数据操纵接口层IDAL，数据模型层Model，DAL工厂类DALFactory，业务处理层BLL。它是MVC模式的一个实现。
根据面向对象设计思想，每个model层的VO应该就是对应于数据库的一张表，然后再根据IDAL的接口在DAL完成该VO的SQL操作。在BLL层调用相应的方法获取VO的实例或实例列表。这个架构看起来是很合理的，但不使用与我们的系统。
我们要开发的是一套比较大的金融业务处理系统，这种系统最核心的操作是数据库操作，显示给用户看到是这些数据操作后的产生的报表，而表与表之间又存在着很复杂的关联，单纯的这种根据数据库来生成VO，然后对其实例进行操作的过程是可行的。举个简单的例子，我们有一张银行基本信息表BankBase，里面当然就存放bnk_id,bnk_na等等，然后我们的帐户表AccBase当然也会包括bnk_id在内，这两个表都有相应的VO，业务的要求是产生一个报表包括帐户的基本信息和相应的银行名称。这样的话我们就必须要在BLL层循环AccBase，根据每个bnk_id来查询其bnk_na。这样对系统的运行速度会造成影响，因为这个工作直接用一个join out SQL语句就可以完成的。若要改进，则可以在AccBase的VO里面加入bnk_na字段，然后再AccBase对应的DAL里用join out语句，但这种做法是很荒谬的，失去了PetShop3框架的意义了。
所以说，我们这个系统不应该采用PetShop3框架。
现在我们面临的问题主要有几个：
1.怎么方便、快速地访问数据库，采用什么样的数据结构来存放这些数据。
2.怎么实现B/S模式下数据大批量、频繁的数据访问。即怎么很好地实现数据缓存。
我们所采用的框架是参考于微软的PetShop3，该框架是一个五层的架构，从底至上为数据操作层DAL，数据操纵接口层IDAL，数据模型层Model，DAL工厂类DALFactory，业务处理层BLL。它是MVC模式的一个实现。
根据面向对象设计思想，每个model层的VO应该就是对应于数据库的一张表，然后再根据IDAL的接口在DAL完成该VO的SQL操作。在BLL层调用相应的方法获取VO的实例或实例列表。这个架构看起来是很合理的，但不使用与我们的系统。
我们要开发的是一套比较大的金融业务处理系统，这种系统最核心的操作是数据库操作，显示给用户看到是这些数据操作后的产生的报表，而表与表之间又存在着很复杂的关联，单纯的这种根据数据库来生成VO，然后对其实例进行操作的过程是可行的。举个简单的例子，我们有一张银行基本信息表BankBase，里面当然就存放bnk_id,bnk_na等等，然后我们的帐户表AccBase当然也会包括bnk_id在内，这两个表都有相应的VO，业务的要求是产生一个报表包括帐户的基本信息和相应的银行名称。这样的话我们就必须要在BLL层循环AccBase，根据每个bnk_id来查询其bnk_na。这样对系统的运行速度会造成影响，因为这个工作直接用一个join out SQL语句就可以完成的。若要改进，则可以在AccBase的VO里面加入bnk_na字段，然后再AccBase对应的DAL里用join out语句，但这种做法是很荒谬的，失去了PetShop3框架的意义了。
所以说，我们这个系统不应该采用PetShop3框架。
现在我们面临的问题主要有几个：
1.怎么方便、快速地访问数据库，采用什么样的数据结构来存放这些数据。
2.怎么实现B/S模式下数据大批量、频繁的数据访问。即怎么很好地实现数据缓存。
