记录我开发鞋服行业供应链软件的历程<设计系统技术架构>

系统架构我想把它分为两部分，一是技术架构，二是业务架构。

做任何一个系统，首先都要选择合适的技术来开发，这个要从两方面结合起来看，一是系统业务的特点，

二是团队成员的技术结构，这里面的权重比我觉的是业务>技术。在鞋服行业，由于它的组织结构的特殊性

(在全国各地都有分支结构)，采用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指定.