web项目开发总结

web项目开发总结（精选8篇）

篇1：web项目开发总结

唐诗宋词学习网站项目总结

1引言

当下人们生活节奏飞快，能够在紧张的工作之余细细品读几首唐诗宋词，亦不失为一件美事。作为一个具有特色的学习网站，网站提供了颇具特色的唐诗宋词的学习功能，使用户能够在轻松的状态中学习。

1.1编写目的

本次项目总结主要是对唐诗宋词网站项目的总结，希望通过总结我们在开发过程中遇到的问题和采取的方法，对以后的项目开发起到一定的指导性的意义。从而提高我们组以后开发项目的效率和规范我们的过程。从客户的需求中提取项目应该实现的功能要求，为后期的构建提供指导。

1.2背景

鉴于当前互联网的快速发展，以及国家对中国传统文化的提倡，希望建设一个学习唐诗宋词的网站，帮助推动对传统文化的传播和继承。

2实际开发结果

2.1产品

唐诗宋词学习网站

2.2主要功能和性能

● 普通的游客，以未登录的状态浏览网站的网页，本网站只提供搜索和在线阅读功能；

● 诗词搜索：用户可以根据诗名、词名、词牌名、内容关键字等词条进行搜索；

● 作者搜索：用户根据喜爱的诗人或者词人的名字进行搜索； ● 用户根据以上的搜索的结果，选择查看；

本网站为注册的会员提供了除以上的服务外，更具有吸引力的功能：

收藏列表：

● Favorite list:用户可以将自己喜爱的诗和词加入到Favorite list 中；

● New poem list:用户可以将自己喜爱的新诗词加入此列表，此表中的诗词是以后在线学习和复习的内容；

● 在线学习，并完成测试的诗词会被自动加入到Favorite list中； 收藏列表的管理：用户拥有对自己列表自主管理的权利，如增加新的诗词、删除等操作 ● 分享到微博：用户可以将喜爱的时、词分享到微博，推荐给好友阅读；

● 在线学习：用户通过在线学习的板块可以记忆自己喜爱的诗词。

学习分为三个难度等级：初等、中等、高等。网站同时为在线用户提供记忆提醒，为用户推荐最佳的复习时间、安排复习的内容。

2.3基本流程

同概要设计流程

2.4进度

系统规划阶段 需求分析阶段 项目功能实现 系统测试阶段 系统界面美化 项目验收阶段

标志性事件 开始到完成

系统需求说明书完成 11.20-11.30 基本代码的生成 测试文档产生 接受公开的测试 对项目功能的演示

12.1-12.16 12.17-12.23 12.24-12.30 12.31-1.5 3开发工作评价

3.1对生产效率的评价

本次项目中，由于组员之前缺少默契，对项目的了解程度不是很 好。所以前期的时候，小组的效率非常低，对自己能力的高估和对项目的工作量不清楚是造成效率低的主要原因。同时，随着项目的进展，采用的结对编程使组员之间形成了一种默契。鉴于对以前SSH框架的初步了解和对项目的深入理解，中后期的生产效率还是有一定的提高。但是与程序员的真实水平相差很远。

3.2对产品质量的评价

1.对于网站初期的规划的唐诗宋词的增删改查功能。2.诗词作者信息的增删改查功能。

3.收藏列表的增删改查和添加删除诗词功能。4.生诗词库的建立和考核测评功能。5.用户的注册登陆功能。

上述的各项基本功能均已经实现，可以总体运行。但是每一个功能还有很多工作要做，完善。各项功能还是有些bug，完善这些功能还需要一部分时间。同时由于我们组员对用户的需求认识不足，造成了很多反复，导致生产率效率低下。

3.3对技术方法的评价

1、使用数据库建模工具：PowerDesigner 工具来建立系统数据库模型，以方便程序员很好的理解业务流和掌握系统架构者的架构思想，更好的满足客户的功能需求。在今后的项目开发中，我们要更好的来完成系统的前期数据库模型的建立，最大的来优化系统功能。

2、系统开发框架：此系统的框架使用的是SSH结构，此框架在开发一些中小软件是比较实用的。使得程序员能够随心所欲的使用对象编程思维来操纵数据库。但是我们要是可以开发出自己的框架，把一些通用的功能开发到框架中。这样以来，在以后的系统开发中，针对系统中一些通用的功能就不需要再开发，从而也可以很好的提高我们的开发效率；减少很多维护费用。使我们的技术不断的更加成熟。

3.4出错原因的分析

主要有以下几个方面的原因需要我们可以以后注意：

1、对软件开发的流程不是很熟悉。因为这方面知识的获取只是停留在理论层面，缺乏理论经验。

2、组员之间的交流还有待提高。因为在最后的一段时间，由于课程学习和复习的原因，大家能够集中在一块进行编程的时间不多。对项目的关注程度有所降低。

3、对web开发技术了解面不够，目前只是会对SSH框架熟悉。而且其中的框架使用细节流程也不是很清楚。

4经验与教训

项目历时两个月时间，在这两个月的时间里，使我们组对于项目有了更深刻的理解。

首先是对软件工程课程的更进一步学习，理解。此次的综合训练是紧跟课程同时进行的。在课程进行的同时，老师对其用到的知识进 行了详细的讲述。包括团队的建立，题目的选择，团队中各个组员之间的关系和整个项目选择的过程模型等。

第一阶段：需求分析阶段。只有充分了解了用户的需求才能开发功能完整、性能良好的项目。在这个阶段，我们小组听取了梁丹同学对于这个网站各个功能模块的描述，并做详细的记录，这个为我们后面项目的度量提供了可靠的材料。

第二阶段：项目分析设计阶段。整个项目在这个阶段的工作要多一点，它直接关系到后一阶段的编码，所以它起到了承上启下的作用。这一阶段的主要任务包括分析项目中对象，再根据对象设计数据库，在此包括其建模设计，在完成数据库后就是数据流程图了，它大体上描述了程序走的流程，以及大体的一个架构。完成上述工作后就是类的设计了，它是根据数据流图的设计来设计的，写好每个模块的每一个类，为下一阶段做好准备。在此，我们就完成了整个系统的一个架构。

第三阶段：编码阶段。在整个项目周期中只占到了1/4的时间，用代码将整个系统的业务逻辑表达出来。其中和遇到好多问题：对java中的好多现有的类不熟悉，使得编写的代码质量不高，代码的复用性不高，好多问题还都没有解决。

第四阶段：测试和发布。这一阶段是我们项目的最后一个阶段了，主要是对项目所涉及的功能进行功能测试。发现问题及时解决。

同时鉴于我们采用的是Scrum敏捷开发模型，并采用了结对编程。下边介绍下关于团队建设方面的总结。团队的个体成员为实现一个共同目标而协同工作。团队工作就是团队成员为实现这一共同目标而共同努力。项目团队工作是否有成效会直接影响项目的成败，尽管计划以及项目经理的工作技能是必要的，但人员——项目经理和项目团队——才是项目成功的关键。项目成功需要一个有效的项目团队。

我们组每位成员都精心付出了自己的努力，相互依赖，齐心协力地进行工作，已保证项目目标的成功实施.同时我们组也做到了以下的关键几点：

1、对项目目标的清晰理解。

2、对每位成员角色和职责的明确期望。

3、目标导向。

4、高度的合作互助。

5、高度信任。

这些都是以后我们在做项目设计时候必须借鉴的。一个绩效良好的项目团队很有必要管理好时间，为有效管理时间，团队成员要明确每周的目标，每天制定一个做事表，集中精力完成当天的做事表。要控制干扰，谢绝参加那些对实现目标没有意义的活动。团队成员也要有效利用等待的时间，一次性处理好文件工作，并要为实现目标奖励自己。我们组的每位成员都尽心尽力地为这个项目付出，期待项目最后成功的实施。

通过此次项目的学习和实践，使得我们组对于软件过程和项目管理这门课程有了更深入的了解，对其中所涉及的方法和工具有新的认 识，我们组会在以后的学习中继续摸索，灵活运用各种方法，熟练对各种工具的掌握，努力提高我们组的知识水平和业务能力！同时也认识到我们组在实际的代码编写阶段出现了许多无法解决的bug，需要我们利用下来的时间进行完善，真正做到学习无止境。也使我们认清了我们现在的编程水平还很低下，对知识的掌握还不够。距成为一名合格的软件工程师还有很长的一段距离。

篇2：web项目开发总结

这是第二次做项目了，虽然每次做的并不是什么很大的项目，但做项目的过程中却真正体会了其中的艰辛与快乐。一个个问题解决时的快意，一个个问题产生后的迷茫，都让我回味无穷。乱七八糟的讲呢也不知道从哪讲起，所以总结了以下几点心得：

1.对于网站开发，是离不开数据库的，数据库的结构设计也是重中之重。我们团队在做的过程中对表进行了一些修改，导致很多不必要的问题。因为数据库结构设计的更改，有时会导致一定程度的返工，这时修改代码所消耗的时间会让我们得不偿失的，数据库结构设计的好坏在很大程度上决定了软件设计的速度。

2.代码书写的问题。程序代码都具有严格的规范性，所以有时一个不起眼的问题，在造成问题的同时我们也很难发现，我在读取数据库的资料时就犯了这样的问题。还有就是代码的精简度，是衡量一个优秀软件的重要指标，对于这方面我很少做考虑。

3.整体性能与用户需求。事实确实如此，我们会被很多习惯限制自己的思维，在项目中我们根本没有考虑到并发和吸引用户等问题，我想这是当下要慢慢去想的。

4.对学过的知识的掌握。做项目肯定会用到以前的一些知识点，我平常很少花时间去复习学过的知识，就是等到哪里用到了就去找，最后才发现已经忘了这个知识点是出现在那一次课了。所以对学过的知识有一个复习和很好的归纳是有必要的。

5.分工与合作。项目完成以后，我体会到任务分配的好的话，会带来很多好处，任务分配下去，不同的人要做不相干的模块，这样在整合项目的时候也会省事很多。

篇3：响应式Web开发模式分析

在科技飞速更新大趋势下, 人们常用的计算机互联网设备已不仅限于一台台式电脑, 显示器和一根网线。各种尺寸, 类型的笔记本电脑, 平板设备, 智能手机, 智能手表, 智能电视等带CPU和存储功能的各类微型计算机设备正在迅速崛起。随着3G, 4G网络的不断普及, 目前国内PC端网站的日均覆盖人数基本保持在2.3亿人次上下, 已趋于停滞。而移动端App的日均覆盖人数已接近2亿, 并呈现持续上涨趋势, 大量数据调查表明, 移动互联网行业时代已经到来, 越来越多的人开始习惯用移动设备代替笔记本和台式机完成日常工作和生活需要[1], 用户的注意力从PC向移动端转移的态势已不可逆转, 人们在这些各种尺寸的智能设备上浏览网页的用户体验需求便必然提高。

传统的Web前端开发都是为一种设备提供的, 比如台式电脑。在设计时每个Web页面通常都是为每个元素的宽度固定尺寸。这样设计的网页在不同大小的屏幕上, 会有不同的显示效果, 当一个用户使用桌面PC和使用移动互联设备访问一个网站时, 有很大的差异, 会感觉不适应[2]。为了解决这些问题, 为不同的设备制作不同的网页是目前国内很多网站的做法, 例如可以专门为移动设备提供一个mobile版本, 以保证网页在不同设备上的显示效果, 但是维护成本却增加了, 同时也大大增加了架构设计的复杂度[3]。随着目前不同尺寸设备的增多, 我们不可能为每种设备都去单独开发一套Web界面。

1 响应式页面

为了应对引言中有关问题, 2010年, Ethan Marcotte提出了“响应式Web设计 (Responsive Web Design) ”的概念[4]。该文借鉴了响应式建筑设计的思路:现出现了一门新兴的学科——"响应式架构 (responsive architecture) ", 物理空间应该可以根据存在于其中的人的情况进行响应。同样, 页面的设计与开发应当根据用户行为以及设备环境 (系统平台、屏幕尺寸、屏幕定向等) 进行相应的响应和调整。尽管响应式Web在2010年被提出, 这个技术真正开始被国内开发者关注则是近2年随着HTML5和CSS3的出现刚刚开始。

2 响应式Web开发流程

目前最为常用的Web开发模型都是基于瀑布模式或瀑布模式的修改。这类模式通常可以简化为5个步骤:计划分析、总体架构设计、具体开发、精确测试、完善修改。

2.1 计划分析与总体设计

传统的开发过程里的框架图主要由布局和组件构成。它们通常被设定为一个特定的尺寸 (通常基于像素, 比如wrapper通常是960px的显示器宽度) , 并且几乎没有调整的余地。这些框架给出了具体的网格布局的尺寸大小, 在某个特定屏幕分辨率下, 它们通常能够获取最佳的浏览效果, 但在更大或更小的分辨率下, 网站可能产生横向滚动条, 或在页面两侧产生空白区域[5]。不一样的屏幕会导致布局的改变, 最后可能导致导航条菜单无法使用, 无法进入表单, 界面也会变得凌乱。在响应式Web开发中视图不同设计的组件也不相同, 页面并不是起到包含的作用。框架图要考虑到在各种尺寸的屏幕上显示, 因此布局尺寸也是多样的。布局要能够适应各种分辨率尺寸, 考虑三列, 两列, 甚至在小的显示设备上采用单列显示。响应式的Web设计不应使用基于像素的完美设计, 而应设计不同尺寸的布局和组件以便适应多样化的要求。滚动条, 文字内容, 表单和其他成份是组成整个页面的基础。在计划分析时也应考虑到除了鼠标键盘以外的设备进行控制, 比如平板电脑或手机上的触控。

2.2 具体开发与测试

在响应式的开发模式下, 开发是以灵活的网格为基础的。各种组件可以容易的被加入到布局中, 因此最初设计上并未规划各种组件。但在开发过程中开发者要对组件进行设计并在各个阶段实施测试, 对各个组件代码进行优化亦是必不可少的。通过策划者, 设计师和开发者之间良好的协作可以规避由于必需的修改而引起的各种问题。在开发的每一个阶段都应在多种浏览器和不同尺寸屏幕中进行测试, 这样可尽早发现问题, 也可发现某种移动环境与框架图不匹配的错误, 以及了解该设计在不同平台上的性能。测试内容包括可访问性、导航与表单的可用性、可读性等方面。对于较小屏幕设备, 将全局导航与主要内容之间的部分高度压缩, 或者采用可折叠设计, 确保页面跳转后主要内容可以呈现在首屏中, 以防引起用户误认为页面没有完成跳转。

2.3 完善修改

传统开发过程没有通过设计和界面迭代的过程, 容易忽略项目中的小细节, 从而引起一些问题并与客户期望相冲突。在响应式开发中, 可以在取得进展的同时, 采用动态代码向客户展示每一步的实现过程。这样这些早期的成果可以推动下一阶段工作的进行, 并在截至日期之前容易进行关键的修改。

3 响应式Web的实现方式

3.1 媒体查询 (Media Queries)

W3C在CSS3中加入了媒体查询 (Media Queries) 模块, 媒体查询根据媒体类型、屏幕宽度、屏幕比例、设备方向 (横向或纵向) 等各种功能特性来改变页面布局, Web设计者只需要针对不同的屏幕分辨率等级来编写不同的页面布局样式, 然后上网设备会根据自身的屏幕分辨率来选择一种适合页面的布局, 从而改善用户浏览体验[6]。

上图为媒体查询方式的简单调用的截图片段, 其中代码来自于Bootstrap, 一个目前比较好用的前端框架。当屏幕显示的浏览器可视范围大于1200像素时, 容器的展示效果为1170像素, 当可视范围在992-1200像素之间时, 容器展示效果为970像素。在这里Responsive设计最关注的就是宽度, 根据用户的使用设备的当前宽度, Web页面将加载一个备用的样式, 实现特定的页面风格。利用CSS3中媒体查询的技术支持我们可以定义需要调整的容器宽度的断点或称临界点, 常见的设备临界点如图2所示。

断点也可以让页面布局在预设的点进行变形, 也就是说, 在台式桌面上显示3栏, 在移动设备上仅显示1栏。大多数CSS属性都可以实现断点之间的变形。断点放置的位置通常取决于内容。比如, 如果一句话要换行, 可能就需要加上断点。但断点使用时需要谨慎, 如果搞不清内容之间的逻辑关系, 很容易弄的混乱。

当我们调整我们浏览器的大小时, 利用Media Queries已经可以非常不错地完成工作了, 但这并不能满足移动端的浏览器。原因是移动端浏览器会默认页面是为宽屏幕设计的, 所以将它缩小整个页面来适应小屏幕。我们需要利用viewport meta标签, 将网页宽度默认等于屏幕宽度 (width=device-width) , 原始缩放比例 (initial-scale=1) 为1, 即网页初始大小占屏幕面积的100%。

3.2 流式布局

利用媒体查询技术我们可以根据屏幕宽度, 设备方向等各种功能特性来改变页面布局, 但是这种改变有着很大的局限性:这种变化方式是突变的, 从一组CSS媒体查询规则突变到另一组, 两者之间没有任何平滑渐变。如果窗口处于媒体查询所设的固定宽度范围外时浏览网页就需要水平滚动才能完整浏览。出现这种问题的原因是网页中的内容的是使用绝对单位, 比如像素来定义的[7]。要解决上述问题, 就需要另外一种设计理念:动态布局 (或称流式布局) 。动态布局的设计思路是一切设计都尽量以动态的方式来进行操作和布局, 而不是以固定不变的形式。流式布局可以概括为以下几种技术:

3.2.1 百分比宽度 (Fluid Width)

传统页面中的table或者div通常都是固定像素宽度的, 当页面放大缩小时宽度依然会是原有设定的宽度。利用百分比可以根据浏览器窗口宽度自动调整页面布局, 不会出现水平滚动条, 大屏幕时, 页面两侧不会出现固定布局中的大面积空白, 小屏幕时, 内容也不会挤成一团难以阅读[8]。在丹·锡德霍姆 (Dan Cederholm) 编写的《无懈可击的Web设计》一书中, 伊桑·马科特为其撰写了一章关于流动布局的内容。在书中, 他提出了一个标准化的公式, 即“目标元素宽度÷上下文元素宽度=百分比宽度”[9]。

图3中左侧所示为演示页面的html导航条演示代码, 中间所示的是对应CSS中的Wrapper和navigation代码, 右侧所示为CSS固定宽度转换为百分比宽度代码。该代码在转换后会发生问题, 导航条内容会相互挤在一起。原因是左边的导航中Li标签的CSS中并未设置宽度, 而<a href="#">链接被包裹在各自对应的<Li>标签中, 它们才是我们要找的外边距的上下文宽度。display:inline-block的作用是将对象呈递为内联对象, 但是对象的内容作为块对象呈递。旁边的内联对象会被呈递在同一行内, 允许空格。我们可以将其改为display:inline, 或者将Li-a标签中的margin-right属性拿到Li中, 问题得到解决。这个简单的例子说明设置百分比宽度的关键在于找到目标元素宽度所对应的上下文元素。

3.2.2 弹性宽度 (Elastic Width) 文字

像素px是相对于显示器屏幕分辨率而25言px的;。em是相对长度单位, 相对于当前对象内文本的字体尺寸。如当前对行内文本的字体尺寸未被人为设c置od, e/*则*/}相C对SS于浏oth览er器的默认字体尺寸[10]。em作为一个测量单位, 指的是特定字母的宽度和高度相对于特定字体磅值的比例。目前Web开发人员通常会用像素来对文本大小进行控制, 但是不同的屏幕有着不同尺寸, 以像素为单位的文本可能在这台设备上能够正常比例显示, 在另一台设备则太大或太小。因为已经固定像素值, 不同的文本往往需要分别逐一设置。如果我们给<body>标签设置文字大小为100%, 给其他文字都使用相对单位em, 那这些文字都会受body上的初始声明的影响。这样做的好处就是, 如果在完成了所有文字排版后, 客户又提出将页面文字统一放大一点, 我们就可以只修改body的文字大小, 其他所有文字也会相应变大[11]。某种意义上讲em与百分比类似, 文本尺寸也按比例缩放, 两者在技术上都是随父级容器级联, 都属于流式布局设计方式。

3.2.3 弹性图片 (Elastic Image)

页面上所有图像一般都以原始宽度进行加载, 当包含元素的可视部分宽度小于图像的原始宽度时, 图像的某些部分会被遮挡和隐藏, 我们可以利用图像采用百分比宽度的方式来保证图像的最大宽度不大于它所含有元素的可视部分宽度, 当分辨率调整时, 图像的最大宽度值会相应按比例调整, 使得图像能够按比例缩放[12]。CSS3.0提供了实现图片随着流动布局相应缩放的简单方式。做出类似如下代码的声明即可:img{max-width:100%;}。用这种简单的方式去替代Java Script框架 (比如j Query) , 这样便可使图片自动调整与其所在容器相配。当然此方式同样可以用到其它的多媒体标签上来。特别要注意的是, 用此方法声明时在所在的标签上不要指明图片的宽度和高度。

4 结语

篇4：Web应用开发的学习心得

关键词：web应用；Web1.0；Web2.0

中图分类号：TP309文献标识码：A文章编号：1007-9599 （2011） 07-0000-01

Learning Experiences of Web Application Development

Guo Haiku

(Guangdong Industry Technical College,Experimental&Training Center,Guangzhou510300,China)

Abstract:Reviews the development history of the web application development,this paper introduces the general process of learning Web development and development process of Web application.

Keywords:Web application;Web1.0;Web2.0

一、引言

所谓的Web应用，就是由网站提供的，客户端以浏览器为平台的基于Internet的应用，它不是纯静态的网页模式，而是包括网页、程序、数据库及其它数据存储形式在内的能够实现对信息的查询、增删改和交互式操作的综合应用。

二、Web1.0和web2.0

谈Web的发展就不可能不提到Web1.0和Web2.0。Web1.0时代，我们作为互联网的使用者只能被动的去接受网上的信息，这时候的网络更多的是一种单向的信息传送。任何一个会上网的人都不可能不知道Html（Hypertext Markup Language：超文本标记语言），而那时候网络提供的是一种信息浏览和简单信息交互的平台，讲求的是门户，内容，商业模式等。ASP，PHP，CGI等技术已经能基本上满足中小企业电子商务及信息发布平台建设的需要。而ASP，CGI等技术由于其自身的局限性已经不能满足各行各业各种深层次的需求而被迫走向灭亡。从互联网的发展和从事网络技术被看好以来，有着各种汇编语言背景的程序员就根据自身的语言背景去选择与他们所掌握语言相近的脚本语言，如C语言或Perl语言的程序员可能会去选择学习PHP等。而ASP作为一种服务器端脚本由于其可以包含HTML标记、普通文本、脚本命令以及微软强大的COM组件支持功能而成为很多网页爱好者学习的主流。但是无论当初你是多么喜欢和欣赏ASP，它即将走向灭亡的趋势都是不可逆转的。除非你将自己的技能排在网络开发的技术之外，或者你比较守旧，喜欢死守过时的技能不放。否则你必须根据技术的发展趋势去选择一种在未来世界更加畅通的WEB开发技术。在J2EE和.NET两种平台即将成为主流的环境下，选择JSP还是C#又成为了Web开发的一次选择。Ajax技术的逐渐成熟对Web2.0的推动起到了巨大的作用，在以前我们仅仅通过动态图片的方式来体现网页的生动这种方式之外，我们发现Web2.0的时代我们也可以作为信息的制造者来参与到互联网这个庞杂的东西之中。Google这个业界的领头者算是把Ajax用到了极致。Google Maps也是因此声名大噪。博客，维基百科，直到现在非常火热的微博，这些也都是Web2.0的经典之作。我们发现这个时候我们既是互联网的使用者同时也是互联网信息的发布者了。最典型的维基百科我们也可以作为作者去修改其中的任何一个词条。以前作为纸质出版的时代我们很难体验到作为一个作者发表自己思想所带来的成就，但是现在Web2.0很轻松的实现了我们这个梦想。总的来说，Web2.0就是一种互联网和用户双方的互动过程，在Web2.0中互动的概念是非常重要的。也正是因为有了互动这一特性，Web2.0才能和Web1.0明显的区别开来。现在Web2.0可以说已经发展到了极致，因此有人扬言Web2.0将在以后的几年之中走下坡路甚至到最后的消亡，我认为Web2.0的消亡是不可能的，就像我们现在依然可以看到Web1.0的各种应用一样！现在人们更是眼光放足于长远，很多人开始畅想于Web3.0是个什么东西。李开复也提到Google已经开始了Web3.0概念的提出，李开复自己本人也对Web3.0提出了概念，这个网上随处可以找到，这里不再多说！至于Web3.0网上的说法是五花八门，难得统一，至于各种观点大家都可以在网上找到，我在这里也不再多说。至于Web3.0到底是什么样子，现在还很难具体揣测出来，也许是等到某种技术的诞生也就自然而然的将我们带到了Web3.0的时代，到了那个时候我们也许就会恍然大悟，“原来Web3.0就是这样啊！！”

三、学习web开发的一般过程

1.学习网页设计基础知识、html以及css。

2.学习客户端开发技术，如网页前端脚本javascript，之后可以选择学习一种javascrip框架简化开发。

3.学习服务器端开发技术，如一门服务器端语言PHP，之后可以学习数据库，综合应用。

四、Web应用的开发过程

1.需求分析-目标定位、用户分析、市场前景。

2.平台规划-内容策划、界面策划、网站功能。

3.项目开发-界面设计、程序设计、系统整合。

五、结语

Web应用的需求正以一种惊人的速度在增长，web应用新的开发技术也在不断涌现，随着各种技术的发展，web应用已经不仅是一个网站，而是可以作为完整的企业级解决方案，特别是随着web2.0的各种技术（比如：Blog、RSS、Podcasting、SNS和WIKI等）的出现，更加显示了web应用的发展潜力。

参考文献：

[1]莫少东,罗伟其.web应用开发技术的发展前景[J].暨南大学学报,2001,22,1

[2]王成良.web开发技术及其应用[M].王成良.北京:清华大学出版社,2007,12

篇5：web项目前端开发经验总结

最近这一个月完成了自己的第一个java web项目，是给某杂志社做的在线投稿系统，虽然进度很慢，但是中间确实学到了不少东西，深刻体会到了自己看几个月书都不如做一个项目来的实在。这个项目自己主要负责的是JSP页面、JS脚本、CSS样式表的编写，虽然主要做的是前端，但是在设计前端后台交互功能时，对MVC架构和数据库又多了一分了解，这一个月的时间，自己在技术上也确实成长了不少。下面分成几块总结一下自己的这个项目中的心得吧：

1.项目开发流程：从确认需求开始，到原型设计，再到原型测试，这些都没什么说的了，主要是刚开始开发前端JSP页面时，自己走了很多弯路，想到有什么页面就写什么页面，GET和POST的路径也是随心所欲，想到什么名字就起什么名字，结果发现这样做严重影响了项目开发的进度，后来经过主管的提点后，我幡然醒悟，其实，面向对象的思想就贯穿在整个项目当中，在前面的原型设计的过程中，除了页面的设计还有数据库的设计，数据库的每个表就对应着Java中的每个实体类，这个类封装了数据库中的列作为属性，封装了数据库的增删改查作为方法，就拿这个投稿系统为例，实体主要有用户、稿件等等，实体间还有着一对一映射或者一对多映射等对应关系。其实，整个系统的开发就是围绕着这些个实体进行的，甚至于我们可以把实体名字做为二级目录，把实体的增删改查作为GET或POST的路径，譬如account/add、paper/delete等等，有了这些路径，那么与之对应的GET和POST的Controller也就有了，接下来我们要做的就是，定义Controller中返回的视图，写完Controller后再把与实体相关的增删改查方法写到服务层中，再把项目的整个骨架搭起来，再去处理细节，很快的，这个项目就成型了。这里前端和后台的配合尤为重要，数据交互是整个系统的核心。

2.JSP页面设计：提到JSP页面，在这里我想说的一点是，其实JSP页面是在服务器生成的，那么传给JSP页面的变量、参数都会在服务器转化为它们具体的值，然后再传给客户端。JSP页面可以实现很多服务器端的功能，因为可以直接在页面嵌入JAVA代码，但是我们必须明确的一点是，JSP页面主要是用来呈现视图的，不要再其中套入大量的代码，要明确前端与后台的分工。

3.JSTL标签：JSTL标签就是JSP standard taglib，即JSP标准标签库，首先，EL表达式可以非常方便的取出Controller返回的View包含的Model，甚至都无需声明EL表达式。其次，JSTL标签可以实现很多的逻辑控制功能，比如最基本的c:if判断、c:forEach循环，甚至有更强大的c:choose，有了这些，我们可以大大简化代码量，JSP页面中用几十行java写的代码，有时用几句JSTL标签组合就实现了，此外，像fmt:parseDate和fmt:formatDate也是很好用的标签，用于日期的解析和格式化，此外JSTL更有强大的函数标签库fn:，项目中我也只用到了fn:length取后台传的list的长度。要善用JSTL标签，但是又不要完全依赖于它，JSTL标签很方便、快捷，但是切记，JSTL功能有限，不要完全依赖于它。

4.shiro框架：shiro框架是apache的一款面向java web项目的权限控制框架，这个框架无论前端、后台都十分好用，在前端，我们可以使用shiro强大的标签库，通过用户角色赋予用户不同的访问权限。譬如，如果一个系统的用户有访客、用户、管理员三种角色，我们就可以通过shiro标签来控制游客不能访问哪些内容，页面向用户和管理员呈现的不同内容，这就是shiro标签的神奇之处。

5.sitemesh框架：这个主要是用来将所有页面套用固定格式，用以页面的复用，其实有些时候标签更为方便，而且sitemesh框架的内存开销是的二倍，还会导致拦截器出现一些莫名的bug，所以并不推荐使用。

6.jquery：在这个项目中写了很多的jquery代码，发现jquery确实是个神奇的东西，jquery的神奇之处就在于jquery强大的选择器可以方便的取到页面的DOM元素，并且给这些元素绑定不同的事件，提到绑定事件，说一下on、live和bind的区别：bind是jquery最早的绑定事件方法，on是jquery 1.7.0以后才有的方法，bind和on都不能将事件绑定给DOM加载完毕后后添加到页面的DOM元素，这时就需要live了。还有一个经常使用的就是jquery的ajax了，其实在做这个项目之前自己一直不理解ajax的作用机理，只是心里又个概念而已，但是，在真正使用的ajax之后，才发现ajax的强大之处，确实如AJAX自身描述一样，异步加载javascript，这就允许我们在不打开新页面的情况POST一些参数给后台，后台得到并处理这些参数后将JSON返回给前端，这个JSON的处理function就写在ajax的success处理function中。在这个项目JSON和AJAX最主要的应用就是翻页，加载一个页面，把页面传给后台然后把得到的JSON呈现给用户，翻页时重新POST参数，然后在用js重新处理一下翻页区域即可。

7.jquery.validate.js：这是一个轻量的jquery框架，主要用于表单的验证，非常方便。

8.twitter bootstrap.js：bootstrap自带的js框架，里面定义了许多与bootstrap样式相关联的函数，使用起来也很方便。

9.正则表达式：正则表达式的模式匹配是很强大的，灵活运用正则表达式，也会简化代码，甚至我们在查找替换时都可以使用正则表达式。

篇6：web前端开发年终总结

做了整一年web前端开发，对这个职业感触颇多。

这是一个新的职业，入门相对后台的开发人员较低，会一些基本的技术就可以了，如：html、css、js等。

但是，随着开发时间的增长你就会发现自己很快的就会进入一个瓶颈，可能会错误的认为，做前端开发不过如此。可是，如果你静下心来在回头看你写的代码，你会发现之前需求的实现方式并不是最好的，举个最简单的例子，有没有使用jquery的连缀式编程。

如：$(#id).css({color:red});$(#id).show;

可以写成，$(#id).css({color:red}).show();

不要小看这次小小的优化，实力都是慢慢积累的。

上面只是一个简单举例，要说明的是，虽然这个职业入门比较低，但是每一次提高都是艰难的.。

几乎每个前台工程师都是自学成才，因为牛人本来就少，难得遇见，就算遇到一个你也不一定就有机会能跟着他学习。所以在自学过程是坎坷的，甚至都不知道改如何进步，当然本人也在努力中。

分享一点经验：

1.千万注意写代码、和命名规范(也许n久之后或者项目大的时候这才是重中之重)。

2.html的文档结构。好的文档结构会让你写css，js变的简单合理(胜过好的代码实现方式)。

3.尽量尽自己的水平优化代码html，css，js(每一次优化都是提高)。

4.多去关组网站性能优化的方式(最后网站的访问速度和用户体验是证明你能力的时候)。

个人目前的水平有限，就分享这么多吧。

学习经验：

个人觉得，尽量看书加上实际操作来学习，因为从书上学习东西比较系统，学到的东西是系统的而不是一片一片或者一点一点的。最重要的是要去验证书上写的跟实战的结果进行对比，你会发现实际可能还真不一定是那样的。等系统学习完之后，再要提高可能就要找论坛，博客等针对某个点进行突破，后面的成长还有很长。个人能力不到那个地方不在妄加说辞。

如果按照这样的方式来学习，那么开什么书就是最重要的了，看一本好的书可以使你恍然大悟，看一本垃圾的书可能连作者都不知道他写的是什么。个人觉得“图灵”系列的书籍都是不错的，清晰、透彻，比较适合我们来学习，比如：javascript高级程序设计,精通html与css设计模式等。

篇7：web项目开发总结

---Web的网上书店

在大三下学期，通过学习软件工程这门课程，使自己更加系统的认识到了在项目开发阶段，并通过作为担任项目组组长，各个环节都有其必要性和重要性，每个阶段的工作都是项目的必要组成部分。

在整个项目开发过程中，通过作为担任项目组组长，让自己有了更多对项目实施过程中，各个环节、各个组织人员相互协调、统一意见与认识的体会。

比如:在开始阶段，增进每个成员之间的认识，并统一项目的方向，培养每个人对项目本身的兴趣，增强每个人对自己任务的责任感。

开发阶段，协调、同于各个人员的工作与安排，并监督项目的实施的进度。在遇见问题，组织人员对问题的针对性的解决。

和认识到了在开发项目时，不是单纯的编写代码，而是整个开发过程中，各个环节的重要性，尤其是跟进开发进度时，文档的编写也是必不可少的。

篇8：基于WEB开发框架的研究

MVC (Model View Controller) 是把软件系统分为模型、视图、控制器3个基本部分。M是指数据模型, V是指用户界面, C则是控制器。使用MVC的目的是将M和V的实现代码分离, 从而使同一个程序可以使用不同的表现形式。比如一批统计数据可以分别用柱状图、饼图来表示。C存在的目的则是确保M和V的同步, 一旦M改变, V应该同步更新。

图1为Java实现的MVC模型, Java MVC模式是将Servlet, Jsp和Java Bean结合起来的技术。Servlet适合数据处理, Java Bean用于模型, 而Jsp适合显示。这个模式充分发挥了每项技术的优点。

在早期的WEB开发中, 因为业务比较简单, 并没有这3层的划分。用户数据的呈现及输入的接收、封装、验证、处理、以及对数据库的操作, 都放在Jsp页面中。随着业务越来越复杂, 需要考虑更好的利用OOP来解决问题。于是便把业务逻辑抽取出来并形成与显示和持久化无关的一层, 能够让业务逻辑清晰, 产品更便于维护。这就是SUN当初倡导的JSP Model1开发方式。

Model1模式的实现比较简单, 适用于快速开发小规模项目。但从工程化的角度看, 局限性非常明显:JSP页面身兼View和Controller2种角色, 将控制逻辑和表现逻辑混杂在一起, 从而导致代码的重用性非常低, 增加了应用的扩展性和维护的难度。

Jsp Model2中引入了MVC框架, 使用了3种技术JSP、Servlet和Java Beans, Jsp负责生成动态网页, 只用做显示页面。Servlet负责流程控制, 用来处理各种请求的分派。Java Beans负责业务逻辑, 对数据库的操作。

大部分Web应用程序都是用像ASP, PHP, 或者JSP来创建的。造成了数据库查询语句这样的数据层代码和像HTML这样的表示层代码混在一起。由经验的开发者会将数据从表示层分离开来, 交由后台处理, 但这通常不是很容易做到的, 它需要精心的计划和不断的尝试。而使用MVC框架, 应用程序被分成3个核心部件:模型、视图、控制器, 各自处理自己的任务。尽管使用MVC框架需要付出一些额外的工作, 但是给人们带来的好处是无庸质疑的。

视图 (View) 代表用户交互界面, 通常由网页组成。在早期WEB开发中, 网页的数据嵌入在页面中, 无论页面打开多少次, 页面内容也不会发生变化, 这种页面称为静态网页。而MVC框架中View视图中的数据来源于数据库, 随着数据库数据的变化, 页面中的数据也会随着发生改变, 称之为动态网页, 现在比较流行的动态网页开发技术由Jsp、Asp和Php。Java的MVC模型就是采用的Jsp动态开发技术, 因此View的页面由jsp网页组成。在View层只涉及数据的显示, 和数据的采集, 不涉及视图的业务处理。比如最常见的登录页面, 登录视图只是把登录的信息进行收集并提交, 不对登录的信息做判断。

模型 (Model) :就是业务流程/状态的处理以及业务规则的制定。在MVC的3个部件中, 模型拥有最多的处理任务。视图中的数据由Model来提供, 当需要改变视图中的数据时, 不需要修改WEB页面, 只需要修改相应的Model即可。MVC框架中Model层的主要关注点是如何把请求的数据自动装配成Action所需要的bean, 除此外, 框架Model层还可以提供复合bean自动装配、输入校验、本地化及国际化、字符集编码转换、多重输出等功能。比如上述的登录系统, 就是由Model层来完成登录账号和密码的判定。由于应用于模型的代码只需写一次就可以被多个视图重用, 所以减少了代码的重复性。

控制 (Controller) 接受用户的输入并调用模型和视图去完成用户的需求。Java MVC中的控制层由Servlet来实现。控制层并不对数据做处理, 而是根据视图的提交要球, 来决定调用相对应的模型。比如上述的登录系统, 控制器的作用就是接收View层提交的信息, 并把这个信息传给对应的Model去处理, 然后把处理后的结果, 再返回给View层。

MVC的优点: (1) 可以为一个模型在运行时同时建立和使用多个视图。变化-传播机制可以确保所有相关的视图及时得到模型数据变化, 从而使所有关联的视图和控制器做到行为同步。 (2) 视图与控制器的可接插性, 允许更换视图和控制器对象, 而且可以根据需求动态的打开或关闭、甚至在运行期间进行对象替换。 (3) 模型的可移植性。因为模型是独立于视图的, 所以可以把一个模型独立地移植到新的平台工作。需要做的只是在新平台上对视图和控制器进行新的修改。 (4) 潜在的框架结构。可以基于此模型建立应用程序框架, 不仅仅是用在设计界面的设计中。

MVC的不足体现在以下几个方面: (1) MVC并没有很明确的定义, 所以完全理解MVC并不是很容易。并且内部实现原理比较复杂和多样, 对于新手来说需要花费一些时间去思考。 (2) 视图与控制器的可接插性, 造成模型和视图的分离, 这样也给调试应用程序带来了一定的困难。 (3) MVC的实现比较复杂, 并不适合小型甚至中等规模的应用程序, 花费大量时间将MVC应用到规模并不是很大的应用程序通常会得不偿失。

2 MVP框架

MVC (Model-View-Controller, 模型-视图-控制器) 模式是80年代Smalltalk-80出现的一种软件设计模式, 后来得到了广泛的应用, 其主要目的在于促进应用中模型、视图、控制器间的关注的清晰分离。MVP (Model-View-Presenter, 模型-视图-表示器) 模式则是由IBM开发出来的一个针对C++和Java的编程模型, 大概出现于2000年, 是MVC模式的一个变种, 主要用来隔离UI、UI逻辑和业务逻辑、数据。

Model-View-Presenter旨在应用程序分层和提高测试效率, 主要目标是将显示逻辑与业务逻辑分离, 正如设计面向对象程序中创建松散耦合并可重用的对象。MVP的另一个目标是提高针对View的测试效率。编写依赖Session, View State, AJAX, HTML或web控件和业务实体的单元测试类较为复杂, 因此将各视图的显示逻辑保留在ASPX/ASCX文件类中, 并将业务逻辑从中分离出来放在相应的类中, 在MVP中Presenter充当视图和业务逻辑的缓冲层。

MVC和MVP的区别:在MVP里, Presenter把Model层和View层进行了完全的分离, View并不直接使用Model, 主要的业务逻辑在Presenter里实现。而且, Presenter与具体的View是没有直接关联的, 而是通过定义好的接口进行交互, 从而使得在变更View时候可以保持Presenter的不变, 达到了重用的效果, 而在MVC中View会从直接Model中读取数据而不是通过Controlle如图2所示。

从图中可以看到, 在MVC里, View是可以直接访问Model的, View里会包含Model信息, 因此不可避免的还要包括一些业务逻辑。在MVC模型里, 更注重业务的逻辑, 也就是Model的不变, 而针对Model, 则有不同的显示及View。所以, 在MVC模型里, View是依赖于Model的, 但是Model不依赖于View。并且, 如果有一些业务逻辑在View里实现了, 则导致要更改View也是比较困难的, 因为View中的业务逻辑是无法重用的。

在MVP模式里, View只有简单的Set/Get的方法, 用来输入和设置界面显示的内容, 除此就不应该有更多的内容, 绝不容许直接直接访问Model, 而这就是与MVC很大的不同之处。

MVP的优点: (1) View和Model实现了完全分离, 可以修改View而不影响Model。 (2) 业务逻辑的处理更加集中, 便于控制。 (3) 多个View可以共用一个Presener, 便于代码的重用。 (4) 业务逻辑集中在Presenter中, 便于进行单元测试。

MVP的缺点:由于对View的控制放在了Presenter中, 造成了View和Persenter的交互会过于频繁。这样会增加View和Presenter的耦合性, 一旦View发生了变化, Presenter也需要进行变化。比如, 原来的Html网页显示的是Word文档, 但是新求需要将Word文档转换为PDF文档显示, 那么就需要更改View和Presenter。

3 MVVM框架

MVVM是3层架构, M层 (Model实体层) 、V层 (View表示层) 、VM层 (View Model层, 对Model层进行CRUD进行操作, 同时对V层提供数据绑定) 。对这种模式的实现, 大部分都是通过在view层声明数据绑定来和其他层分离的, 这样就方便了前端开发人员和后端开发人员的分工, 前端开发人员在html标签中写对Viewmodel的绑定数据, Model和Viewmodel是后端开发人员通过开发应用的逻辑来维护这两层。

最近几年, MVVM模式在Javascript中开始有人实现, 目前比较成熟的框架有Knockout JS, Avalon MVVM和Knockback.js, 原理如图3所示。

⑴info Channel:信息通道, 主要用于向后台发起数据请求。⑵data Channel:数据通道, 主要用于存储从后台获取到的数据。⑶mole Manage:数据操作, 主要用于操作数据通道中的数据, 如crud操作。⑷module Pool:数据仓库, 主要存储后台返回的数据。⑸crud Store Pool:crud实例池, 增删改的数据, 在持久化到数据库之前, 都会先存在于此池中。⑹action:后台数据处理及数据库访问模块

执行流程如下: (1) info Channel通过调用服务器端action获取数据库数据。 (2) info Channel把获取的数据放到内存中的module Pool中。 (3) data Channel从module Pool中取数据, 并传递到View端。 (4) View端的数据通过mole Manage取出。 (5) mole Manage把取出的数据放到内存的crud Store Pool中。 (6) 通过info Channel把crud Store Pool中的数据传递到后台, 实现数据的持久化操作。

View Model的具体应用: (1) 在前端开发中如需初始化某一模块的数据可以调用data Ch na n nel中的init View Data (view Id, data Store Param) 方法。 (2) 如需查询某一节点的数据集, 可以调用data Chnannel中的get Data By Path (view Id, path) 。 (3) 如需进行crud操作, 可以调用mole Manage中的相关方法。

View Model解决的问题: (1) 向后台的多请求操作改为通过接口统一调用。 (2) 是一个前后端通信的中间件, 具有可插拔性, 适用于文档型及关系型数据库。 (3) 实现了单例模式, 避免多个实例操作同一个对象。 (4) 缓存大数据, 避免频繁向后台请求数据。

4 Model层

Model层同其他的MVC框架一样, Model代表特定领域的数据或者应用所需的数据, 一个典型的特定领域的数据如用户信息, 或者一部电影的信息。

Model仅仅关注数据信息, 不关心任何行为;不格式化数据或者影响数据在浏览器中的展现;格式化数据是View层的任务, 同时业务逻辑层被封装在Viewmodel中, 用来和Model进行交互。在Model层做的一个比较意外的行为是对数据的验证, 比如当用户输入用户名的时候, 判断用户名的格式是否正确, 是否有非法字符等。Model基本是按照上面的定义来实现的, 但是会有通过ajax调用服务器服务来进行读写Model数据。

MVVM框架是衍生于MVC框架的, 两者之间的最大区别在于, MVC框架中的Controller是由是由高级编程语言实现的, 比如用Java实现的MVC框架, Controller是由Servlet实现, 而在View中, 也会用到部分的Jsp代码;而MVVM框架中的View Model则是由脚本语言Javascript实现, 在View界面将不会用到Jsp代码, 从而实现了前端和后台的完整分离。

优点: (1) MVVM使并行开发更加容易, 使前端开发和后端开发人员互不影响。 (2) 抽象化View层, 减少了代码中的业务逻辑。 (3) View Model比事件驱动更容易测试。 (4) View Model的测试不用关心UI的自动化和交互。

缺点: (1) 对于简单的UI, 使用MVVM有点太重。 (2) 声明式的数据绑定不利于调试, 因为命令式的代码可以和容易的设置断点, 这种模式就不利于设置这样的断点。 (3) 在不挑剔 (non-trivial) 的应用里数据绑定可以创建大量的簿记 (book-keeping) 。 (4) 在大的应用中, 在获取大量的概要 (generalization) 前很难设计视图-模型层。

5 结语

本章主要阐述了比较流行的3个WEB框架, MVC、MVP和MVVM, 并对其工作原理以及优缺点进行了分析和比较, 并着重介绍了MVVM框架, 以及如何实现MVVM框架的。

摘要：程序开发框架的选择, 始终是个仁者见仁、智者见智的事情。尤其是WEB层的开发框架, 数量非常多, 而且各有特色, 常见的有MVC、MVP、AOP、ORM、MVVM等, 文章将主要对MVC、MVP、MVVM三种框架进行分析, 叙述其优缺点, 以方便开发人员进行选择。

关键词：MVC,MVP,MVVM

参考文献

[1]王飞剑, 罗义兵, 郝香山, 等.基于B/S结构的农业空间信息管理系统设计与实现[J].计算机工程与设计, 2009, 30 (8) .

[2]顾立业.基于MVC和Ext JS的高校学生信息管理系统的设计与实现[D].大连:大连理工大学, 2013.

[3]杨文韬.基于SSH框架的智能社区信息管理系统的设计与实现[D].广州:中山大学, 2013.