如何规划跟设计web应用程序，其开发周期有那几个阶段

下面用我开发的一个办公系统来说明一下如何规划跟设计WEB应用系统，及其开发几个阶段。

第一步：需求分析

我召集他们所有业务相关部门开了几次会议，将各部门的功能需求进行了整理和统一，写成的功能需求说明书，文中详细列出了软件要解决的实际问题及要达到的目标。他们要求软件要能解决他们的实际问题，带来真正的价值。比如直接给他们带来更多订单，帮助他们寻找客户并留森汪住，同时在经营中节省人力成本及防止不必要的浪费，最终实现公司利润的增长。我认为，如果一个软件不能带来实质性的经济价值，仅仅只是用来装点公司门面，提高一点工作效率，那还不如不要。这也是他们为什么看不上有些成品软件，而要选择定制开发的原因。每个公司情况均不一样，成品软件商往往无法知道每个客户的痛处，所以做出来的产品无法真正适合客户。只有自己针对性的开发，才能真正解决问题。客户才知道他们公司最需要什么，他们的客户应如何获得和留住，业务流程应如何设计等等。有针对性开发一些实用功能，才是最适合的软件。

通过这个项目，我认识到编写软件需求说明书的过程非常重要，这决定了以后的开发过程是不是会走弯路，是否因为开发了不必要的功能浪费时间和金钱，是不是存在程序功能模块上的冲突。我在需求说明编写上花了较大精力，有种磨刀不误砍柴工的感觉。最后在所有人员一致通过这个需求说明书后才决定走下一步。

第二步：开发方案书

开发方案书是将功能需求说明书转化为可开发的具体行动方案，我根据开发平台的开发规则进行编写的，将软件需求说明书中的功能模块进行组合优化，分析出各个模块的数据结构及数据关系、运算逻辑，理清各模块之间的业务流程，最后根据各业务部门人员的实际情况规划各模块的界面样式。

我的开发方案书也写得很详细，不过相比功能需求说明书，感觉容易些，毕竟大方向已有了。开发方案书中我将数据答卜结构中的表及字段全部规划好，并命名好，包括其数据类型、长度等，做成表格，并将各字段数据来源及编辑方式等均做好说明。前面忘记说明了，我虽然对编程不懂，但由于以前有过管理软件 *** 作方面经验，对数据库还是有一定了解的，但也只是懂一些皮毛，不过用天纵快速开发平台开发，这点数据库方面的知识够用了，以后使用过程中如果需要更复杂的一些SQL语句再网上搜索一下吧。

开发方案书对后期的系统开发非常重要，下面的开发过程其实就是将开发方案书的内容在快速开发平台进行配置的过程。

第三步：开发及测试

有开发方案书，接下来的开发就非常容易了，其实就是将开发方案书的内容配置到开发平台上的过程，这就是我前面说的为什么找这样一个开发平台开发这个系统的原因。

用配置型开发平台开发软件相当简单快速，一般的模块三步就可以搞定了，第一步设置模块信息，第二步设置表单属性，第三步设置表中每个字段。也许我这样说你还是不太相信，那好吧。上图！

天纵快速开发平台分开发后台和应用前台。顾名思义，开发后台是供开发者使用的，应用前台是开发好的系统进行使用的地方。好了，进入开发后台吧，如下图：

点击模块设计，就可以开始配置模块了。

选择模块类型是这一步的关健，就是你要开发的功能模块属性什么类型的模块，开发平台内置了很多功能模板，你要做的是分析你要开发的模块属于哪种模板，选中模板就可以将你的模块界面及功能实现了。模块类型有很多，包括了常用管理软件的方方面面，有专门的模块功能模板介绍及 *** 作手册，你在开发时看下 *** 作手册就知道了。模块定义好后，就可以定义模块中的表了，一个模块可能有多个表，一一定义下来，并建立好他们之间的关系。如下图：

表单定义过程中会要求设置表单编辑界面样式，及一些数据规则。表单设置好后，就是设置每清春穗个表的字段了。如下图：

通过这三步的配置，一个功能模块基本完成了。是不是非常简单快速！整体开发过程是不是全部是通过配置来完成的。当然上面提到的是一些最基本的配置，对于复杂功能要求的模块，可能还要进行更详细的配置。

配置型开发平台由于省去代码编写，开发速度大大提高，由于界面是由开发平台中间件根据配置的业务参数自动生成，不用每个界面均去编写一套代码，因此出错率大大降低，软件的性能和稳定性自然也就有了保障。

第四步：编写 *** 作手册

系统开发好后，有一个收尾工作是不能省的，那就是编写 *** 作手册。好在我平时没事就喜欢写点博客，对写作没有畏惧心。 *** 作手册是供使用者学习和 *** 作时用的，在 *** 作手册中我将系统 *** 作过程及其注意事项详细列出，事后我才知道， *** 作手册也是这个系统正式能使用起来的重要因素之一，因为我写的 *** 作手册有声有色，条理清晰， *** 作这个系统的同事很快就能理解并上手了。

我得出的经验是： *** 作手册越早编写越好，最好是在开发的同时就进行编写，开发过程中一些重点内容要立即记录下来，提醒以后的使用者，时间一长了，就算是开发者本人也可能都忘记了，最后导致使用者走弯路。

第五步：上线试运行

折腾了半个多月，一个共有50多个模块的内部管理系统基本算是大功告成了，请客户的几个部门领导一起演示 *** 作走了一遍，大家十分满意，总算没辜负老他们板的期望。他们老板一高兴，批准买一台服务器专门运行这个系统。我花了一天时间，部署到服务器上，开始上线试运行。

第六步：正式运行

经过了半个月的试运行，调整了其中出现一些小问题，就开始召集所有部门相关人员进行几天的 *** 作培训，开始正式在公司内全面运行。

同任何事物一样,一个软件产品或软件系统运闷也要经历孕育、诞生、成长、成熟、衰郑碰亡等阶段，一般称为软件生存周期（喊悄谈软件生命周期）。把整个软件生存周期划分为若干阶段，使得每个阶段有明确的任务，使规模大，结构复杂和管理复杂的软件开发变的容易控

以前实现数据的缓存有很多种方法，有客户端的Cookie，有服务器端的Session和Application。

其中Cookie是保存在客户端的一组数据，主要用来保存用户名等个人信息。

Session则保存对话信息。Application则是保存在整个应用程序范围内的信息，相当于全局变量。

Session

Session用来保存每一个用户的专有信息

Session的生存期是用户持续请求时间加上一段时间（一般是20分钟左右）

Session信息是保存在Web服务器内存中的，保存数据量可大可小

由于用户停止使用应用程序之后它仍在内存中存留一段时间，因此这种方法效率较低

代码：

Session[“UserID”]=”test”

String UserName=Session[“UserID”].ToString()

Cookie

Cookie用来保存客户浏览器请求服务器页面的请求信息

我们可以存放非敏感的用户信息，保存时间可以根据需要设置

如果没有设置Cookie失效日期，它的生命周期保存到关闭浏览器为止

Cookie对象的Expires属性设置为MinValue表示永不过期

Cookie存储的数据量受限制，大多数的浏览器为4K因此不要存放大数据

由于并非所有的浏览器都支持Cookie，数据将以明文的形式保存在客户端

代码：

Resopnse.Cookies[“UserID”]=”test”

String UserName= Resopnse.Cookies [“UserID”].ToString()

Cache

Cache用于在Http请求期间保存页面或者数据

Cache的使用可以大大的提高整个应用程序的效率

它允许将频繁访问的服务器资源存储在内存中，当用户发出相同的请求后,服务器不是再次处理而是将Cache中保存的数据直接返回给用户

可以看出Cache节省的是时间—服务器处理时间

Cache实例是每一个应用程序专有的，其生命周期==该应用程序周期

应用程序重启将重新创建其实例

注意：如果要使用缓存的清理、到期管理、依赖项等功能必须使用Insert 或者Add方法方法添加信息

代码：

Cache[”ID”]=”cc”或者Cache.Insert(“ID”,”test”)

String ID =Cache[“ID”].ToString()

通常使用最频繁的是Session，那么Session和Cache又有什么区别呢？

Session缓存和Cache缓存的区别。

（1）最大的区别是Cache提供缓存依赖来更新数据，而Session只能依靠定义的缓存时间来判断缓存数据是否有效。

（2）即使应用程序终止，只要Cache.Add方法中定义的缓存时间未过期，下次开启应用程序时，缓存的数据依然存在。而Session缓存只是存在于一次会话中，会话结束后，数据也就失效了。

（3）Session容易丢失，导致数据的不确定性，而Cache不会出现这种情况。

（4）由于Session是每次会话就被加载，所以不适宜存放大量信息，否则会导致服务器的性能降低。而Cache则主要用来保存大容量信息，如数据库中的多个表。

（5）Session目前只能保存在内存中，对其性能有影响。

Session：为当前用户会话提供信息。还提供对可用于存储信息的会话范围的缓存的访问，以及控制如何管理会话的方法。它存储在服务器的内存中，因此与在数据库中存储和检索信息相比，它的执行速度更快。与不特定于单个用户会话的应用程

序状态不同，会话状态应用于单个的用户和会话。因此，应用程序状态非常适合存储那些数量少、随用户的变化而变化的常用数据。而且由于其不发生服务器-客户

端数据传输，Session还适合存储关于用户的安全数据，如购物车信息。

Session的关键特性有：存储于服务器内存中，与会话相关，在会话的整个生存期中存在即不会被主动丢弃，不被序列化，不发生服务器-客户端数据传输。

Cache：它存储于

服务器的内存中，允许您自定义如何缓存项以及将它们缓存多长时间。例如，当缺乏系统内存时，缓存会自动移除很少使用的或优先级较低的项以释放内存。该技术

也称为清理，这是缓存确保过期数据不使用宝贵的服务器资源的方式之一。它不与会话相关，所以它是多会话共享的，因此使用它可以提高网站性能，但是可能泄露

用户的安全信息，还由于在服务器缺乏内存时可能会自动移除Cache因此需要在每次获取数据时检测该Cache项是否还存在。

Cache的关键特性有：存储于服务器内存中，与会话无关，根据服务器内存资源的状况随时可能被丢弃，不被序列化，不发生服务器-客户端数据传输。

Cookie：Cookie 提供了一种在 Web 应用程序中存储用户特定信息的方法。例如，当用户访问您的站点时，您可以使用 Cookie

存储用户首选项或其他信息。当该用户再次访问您的网站时，应用程序便可以检索以前存储的信息。在开发人员以编程方式设置Cookie时，需要将自己希望保

存的数据序列化为字符串（并且要注意，很多浏览器对Cookie有4096字节的限制）然后进行设置。

Cookie的关键特性有：存储于客户端硬盘上，与用户相关，在一定时间内持久化存储，可以跨浏览器共享数据，需要被序列化，发生服务器-客户端数据传输。

下面这个问题很有启发性:

最近小组的同事很喜欢用Session做页面跳转，具体就是在查询页面把查询结果放到DataTable中，用Session存储这个dataTable,读取到数据之后再子页面做Session清除，这样对性能有没有什么影响？

1、session：session的确是存放在服务器的内存中（但不是4k上限，具体大小限制应该是服务器内存），而且同一个sessionid的多个

http请求会排队，也就是session对于同一个浏览器来说是同步的，用不好会极大影响性能。另外，session依赖于客户端cookie，因为

sessionid是存放在客户端浏览器进程cookie中的，因此不支持cookie的浏览器，session也会丢失(session

url重写可部分解决这个问题，可参考：http://www.sungness.com/archives/48)。因此不建议用。

2、cookie，也不建议存放datatable这样的“大数据”。因为cookie不仅有4k上限，并且不是“纯存放在客户端”这么简单，要知道

cookie的值在每次web页面请求往返的过程中都是要附带在http头中的，如果太大会占用服务器和客户端之间的网络带宽（虽然只是4k，但在线人多

了可就是4k * n了）。对于b/s结构的应用来说，网络带宽是性能最主要的瓶颈之一！另外，对于datatbale转换成json字符串再存入

cookie，服务器CPU也会消耗。最可怕的是，一但你的cookie忘记删除了，那么在其有效期和作用域内，用户访问你的所有页面时都将携带这个4K

大小的http头，那就悲剧了。10000在线人数，4千兆网卡也不够你花的。

3、数据库连接，每次保存查询语句然后再查询的方式不错，不过看你的查询复杂度了，如果很费时的查询，这样调用也是不可取的。内存和cpu的矛盾你要根据

实际情况作出选择。对于具有连接池的应用来说，一次连接数据的成本并不高，经过测试差不多=10次调用取当前系统时间函数。但查询语句的复杂度就没谱了。

另外，如果并发人数很多的情况下，频繁占用数据库连接，会导致连接池没有可用连接了，那就又悲剧了。此时就不是一次连接的成本，系统整体性能将毁灭性的下

降，反应迟钝。

4、cache：一个不错的选择，不过它可同样是占用服务器内存哦，只是比session多了一些灵活性。不过我也不建议你用于存放传递参数的地方。要知

道session就算内存满了也不会丢失你的参数值（会抛异常），可cache可不是，它会直接删掉你的参数值，甚至内存极度不足时都不会让你进去（也不

会报错）。换句话说，可能上一行代码刚存进去，下一行代码去读就丢了。很可怕吧~

5、form表单：最为提倡的方式，http协议中原本页面间传值的方法就是这样的，只是有时不太方便，能用之则用之。

6、自定义存储机制：如果你对性能要求很苛刻，或者非要精益求精的话。那么还是自己写一个存储机制吧。例如我自己就是写了自己的XSession对象，它

的用法与session使用类似，但是存储机制都是我自己封装的，既有cache的优点、又有session的优点，还有数据库的优点、性能看你写的算法

了、而且具有更大的使用灵活性。缺点就是需要你自己coding.

---