系统架构我想把它分为两部分，一是技术架构，二是业务架构。
做任何一个系统，首先都要选择合适的技术来开发，这个要从两方面结合起来看，一是系统业务的特点，
二是团队成员的技术结构，这里面的权重比我觉的是业务>技术。在鞋服行业，由于它的组织结构的特殊性
(在全国各地都有分支结构)，采用b/s结构为首选，技术方面我们团队只对Java熟悉，所以这次技术的选型
很快就确定了.
Java的流行框架目前很多，可以说是眼花缭乱,我们用的还是最普通的架构，SSH(struts+spring+hibernate)
,但是我们经过了自已的改写，形成了自已的一套技术框架.(改写重要参考的是springside).
[总的思想]
1：以业务层为核心.
2:低耦合.尽量降低每层之间的联系.
[特点]
1:整个系统只有一个Dao,Dao置于每个业务对象里面.
2:整个系统只有一个Action,Action只起一个承上起来的作用.
3:普通的增加，修改，删除，使用Hibernate,复杂的查询直接使用原生SQL
4:显示层支持JSON,Freemark,Velocity，Ecxel,PDF等
5:学习简单，开发速度快。只需要开发业务逻辑就可以。
[分层MVC]
显示层--->业务层--->数据库层
显示层：struts1.1实现，把一些常用的功能封装成tag.
业务层：实现最基本的单表CRUD接口和主子表CRUD接口
数据层：Dao接口的实现，分为读接口和写接口。写接口有事务控制.
[业务层和数据库层之间的关系]
数据库层服务于业务层，每个业务对象拥有一个Dao属性，业务层不控制事务，但业务层可以决定哪些操作
需要用事务，哪些不用。数据库层支持单表操作的事务，多表操作的事务，混合操作的事务，具体含义是：
1：单表操作事务控制：当前操作只有一个对象。
2：多表操作事务控制：当前操作有N(N>=1)个对象.
3:混合操作事务控制：当前的操作对象很多，操作的方式也很多，比如：保存一条记录，删除一条记录，执行
一个sql脚本，执行一个储值过程
[依赖关系]
显示层Action是独立的，业务层依赖于数据库层，数据库层是独立的。那显示层如何绑定找到对应的业务对
象呢，strutsForm里默认一个spring中定义的业务对象，或者通过参数service指定,业务方法是参数method指定.
