Web项目解决方案框架
1.0版本
目录
5.2 确定界面布局(layerout)和风格(style)... 4
1 解决方案框架
设计页面对象组件ActionForm
|
设计操作流
|
设计业务逻辑组件组件
|
收集和分析应用需求
|
设计数据库
|
设计客户UI
|
收集基本用例:基本用例即系统功能。每个功能都是独立的或基本独立。这里的独立是指某个功能一旦实现并运作起来,那么就与系统的其它功能耦合系数很低,一般的讲,只有入的关系而无出的关系,那么该功能就可以算是个独立的功能,否则,就是一个功能的子功能而非独立功能,不算基本用例。
每个功能都是一个用例,包含细节和逻辑流程。
2 用例文档
一般的讲,大型系统采用UML UserCase表达客户需求。UML建模
除了UML图,还需要文档描述,文档描述建议以下格式:
前置条件:开始使用这个用例之前,必须满足的条件。非必需
主事件流:用例的正常流程。必需
其它事件流:用例的非正常流,如:错误流
后置条件:用例执行结果“必须”为真的条件,也称为“附加条件”,非必需
举例:“安全登入”就是一个用例。
Ø 前置条件:无
Ø 主事件流:用户输入正确的用户名和密码,安全登入到Web应用中。向用户返回欢迎页,包括可操作的菜单,提示登陆成功。
Ø 其它事件流1:未输入用户名或密码,显示出错信息:用户名或密码不可为空
Ø 其它事件流2:用户名和密码不匹配,显示出错信息:用户名或口令错误
Ø 后置条件:该用例不是必须为真,无
3 设计数据库
数据库设计的最终目标是完整的回答:“数据从何处来,保存在什么地方”。
在这一步,应该给出数据库表的UML描述和XML文档示例。UML描述的文档说明格式建议如下(举例说明):
/*
设计说明
设计人:Sun Duction
时间:2004-12-22
目标数据库:Oracle 9i
表名:ADDR_TABLE
*/
字段 | 类型 | 说明 |
ID | Int(4) | 记录的ID,自动增长 |
NAME | Char(25) | 姓名 |
PHONE | Char(10) | 电话 |
ADDRESS | Char(50) | 地址 |
XML文档示例为:
<?xml version="1.0" encoding="UTF-8"?>
<Table TableName="ADDR_TABLE">
<item ID="1" NAME="小强" PHONE="02483992100" ADDRESS="北京市海淀区9号(110000)"/>
<item ID="2" NAME="王小花" PHONE="02483992100" ADDRESS="北京市海淀区9号(110000)"/>
<item ID="3" NAME="Jim Green" PHONE="02483992100" ADDRESS="北京市海淀区9号(110000)"/>
</Table>
4 业务逻辑
业务逻辑是独立于系统实现的。采用JAVA,还是采用.NET,那时实现的体系结构问题。业务逻辑描述系统中各个数据实体之间的关系。
MVC框架下:Model实现业务逻辑。
在JAVA中,它们是:JavaBean,EJB,实用工具类,辅助类。
在.NET中,它们是:自定义数据对象,结构,工具类,辅助类。
一般的,在业务层都采用了DAO模式,实现的方式有多种。JAVA中,比较流行的解决方案是Hibernate,JDO。
.NET下,一般采用Data Access Application Block。
关于如何根据需求为系统建模,是个专题,这里就不详细描述。
5 设计UI
UI由需求分析而定,但必须独立于业务逻辑的实现,即:UI不在意界面上显示的数据从何而来(但必须有一种实现的方式)。设计UI时,最终要完成以下任务:确定界面的总体布局和风格、文档描述各个UI元素、各个子UI元素(可复用元素)之间的关联图。
5.1 UI文档描述
UI由用例而来,包括用户界面的功能描述,与用户交互的信息,UI切换关系几个要素。
举例:
界面 | 字段 | 字段类型 | 说明 |
欢迎界面index | 无 | 无 | 显示欢迎信息,提供登陆入口 |
登入logon | username,password | String | 字段可编辑 |
添加记录界面insert. | Name,phone,address | String | 可编辑 |
主菜单界面mainMenu | 无 | 无 | 提供所有操作菜单 |
添加数据确认confirm | 无 | 无 | 向用户显示添加成功或失败信息。 |
5.2 确定界面布局(layerout)和风格(style)
由美工确定符合该项目的总体页面布局和配色方案,给出基础CSS文件。
5.3 页面复用技术
如果采用.NET技术,那么建议采用模版页+自定义控件的方式,动态载入生成HTML页面。
如果采用JSP技术,那么,可以使用Tiles框架。
其实,两个体系的解决方案在内部实现上,几乎是相同的,只不过JAVA领域成熟的开源框架多的多而已。
这一步应该确定页面关联,即每个功能页面与其它片断页面的关系。这是为了达到页面级别的最大程度复用而做的。这是值得的,因为这一步做的好,会大大缩短开发,测试的时间。
对于JSP项目,建议将申明标签库的语句方在一个文件中,如taglibs.jsp,其它文件引用它,并对特定应用使用定制标签。
6 设计页面处理组件
对于Struts而言,每个页面对应一个ActionForm,对于ASP.NET而言,每个页面关联一个代码隐藏类。由于ASP.NET技术,微软的IDE给予的大量的自动化支持,且ASP.NET运行库给予了大量的底层支持,天生的支持MVC框架。这里就不详细描述如何实现ASP.NET的代码隐藏类。
ActionForm Bean用于在视图组件和控制器组件之间传递HTML Form数据。通常,每个HTML Form对应一个ActionForm Bean,HTML Form中的字段和ActionForm Bean中的属性一一对应。
对于Struts应用,请采用如下表格:
ActionForm 名 | 属性 | Validate方法 |
LogonForm | username,password | 二者不可为空 |
InsertForm | Name,phone,address | 三者不可为空 |
注意,这里要保证validate方法不访问Model层,即:它不执行业务逻辑验证。比如,口令不匹配这个逻辑所代表的代码决不可以放在该方法中。
7 设计操作流
在需求阶段确定了事件的流,为了实现这个流控制,需要在各个页面之间切换。对于ASP.NET,由于代码隐藏类给予了对页面和逻辑完全的控制,并提供了类似于面向对象的编程方法,故界面切换直接根据业务的事件流处理即可。
如何在.NET下将控制流在外配置,有什么好的解决方案,希望大家讨论啊!
对于Struts应用,这是由Action 和struts-config.xm文件联合完成。所以必须在这一步就确定好Action和Action之间的映射关系。
Action负责单个事件的流程控制。那么,一个事件,就必然对应一个Action。
Action映射决定了Action与其它Web组件之间的关联。在实际应用中,最好提供下表:
Action | 入口 | Action Form | 出口 |
LogonAction | Logon.jsp | LogonForm | mainMenu.jsp |
LogoffAction | mainMenu.jsp | 无 | Index.jsp |
InsertAction | Insert.jsp | InsertForm | Confirm.jsp |
DisplayAllAction | mainMenu.jsp | 无 | Display.jsp |
该表如果使用图的方式给出,将更加完美。