学院项目的架构设计图&近期任务计划说明

考试告一段落，该忙乎院长交与的项目了。《学生信息管理系统》，准备用struts+iBatis+spring构建，今天算是考完试后小组的第一次开会，交代了近两个星期内的任务。我立刻将结构的想法画成简图，以及计划建议交给组长和各组员。以下是结构设计简图，精彩的工作由这里开始：

 

接下来是半个月左右的计划：
下星期完成数据层到服务层的详细类图，其间我将确定後的实体类图交与邓飞，让他们建表。
再下个星期开会+培训後组织第一阶段的编码，我打算这样的：首先我来建立工程，建立好包结构和服务层的所有接口、添加好所有需要的库，也就是搭个骨架。然后我将工程文件夹、开发工具（Eclipse）、JDK安装文件（统一JDK也很重要）、数据库一并打包传给每个参加编码的人。之后开始分配任务从右至左编码：从Sql查询语句开始至FacadeManagerImp类结束算是完成了这个阶段的任务，其间要注意代码同步，我担心subversion我们都没经验，硬要用上也不见得是好事。所以我觉得要避免代码版本冲突就要严格划分任务区域，各司其职就没事了。可以考虑在某个FTP中为每个人都指定一个代码文件夹，谁有新版本的代码就传到属于他自己的文件夹里，并放上一个名字为更新日期的文本文档，这样我们每隔一段时间就上这个FTP，去每个人的文件夹里下载最新的代码到本地覆盖就可以了。

如上计划完成了的话，我们几乎算是完成了一半的工作。剩下的工作分两种方案：一起作为一个阶段做完、分两个阶段做完。

1）：作为一个阶段做完：业务逻辑层就是struts框架的Action层，直接编写Action，并组织页面流程，完成之后整个项目也就差不多了。这样的话业务逻辑层和表现层就都交给struts来组织。
2）：分为两个阶段做完：先做我们自己定义的业务逻辑层的设计和实现（不跟任何struts的api耦合）（这一层的类多，但形式单一，属于劳动密集型，大概占总的20%的工作量），称为“业务逻辑组件”。；然后就是结合struts来摆纯的表现层，也就是最后30%的工作，其中“业务逻辑组件”中的方法要么返回某种计算结果，要么返回指示是否执行成功的true/false信息，也就是说跟struts达成“控制耦合”，Struts在这里就只管表现层。

方案1）其实属于一般常用做法，循规蹈矩；但方案2）由于实现了独立于任何框架的业务逻辑组件，今后如果要改表现层框架（如放弃struts用webwork或jsf），甚至想把本项目重做成C/S架构都是很方便的事情，只需要做最后30%的工作；但若是方案1）作出这样的改动的话就要做50%的工作（业务逻辑层以上均重新构建）。
也许方案2）有点画蛇添足，我们的项目或许做好后再也不需要做那么大的改动...这是鱼和熊掌的问题...
不过决定用那个方案起码是半个月之后的事情，现在不用着急，先完成最上面的计划吧。