工作流程_工作流程图 - CSDN
精华内容
参与话题
  • Web工作的基本流程

    千次阅读 2018-07-12 10:02:45
    目录目录前言web的基本工作流程web中的一些基本概念HTTPweb客户端和服务端URIURLURNHTTP报文浏览器的工作流程连接结语前言最近在学习web安全方面相关的知识,小白一枚,也是从基础开始学起吧,希望可以把所学的进行...

    目录

    前言

    最近在学习web安全方面相关的知识,小白一枚,也是从基础开始学起吧,希望可以把所学的进行总结写到博客里,以前学习的时候没有总结的习惯,不太会系统的处理知识,现在希望可以学着进行总结,总结的好处不言而喻。当然,也希望各位大牛看到有不合适的地方及时指出,欢迎大家来进行交流学习。

    web的基本工作流程

    首先,我们先来思考一下我们平常在上网浏览网页时候的场景,大致就是打开一个web浏览器,输入某一个网站的地址,然后转到该网址,在浏览器中得到该网址的页面。从这个场景中我们可以抽象出来几个基本对象,我们(用户)、web浏览器(客户端)和发送过来页面的地方(服务端),这些对象其实就是整个web工作流程中的重要组成部分。

    这里写图片描述

    为了加强理解,其实可以将这个工作流程看做去吃饭时点餐的流程,web浏览器就是服务员,而服务端就是厨房。你给服务员说你要点什么菜,然后服务员将你点的菜端上来,具体厨房里是怎么忙活的也并不知道,其实web服务器就相当于厨师,有着各种各样的技能,根据你的成菜要求,为你进行服务,数据库在这里可以认为是个菜窖,需要什么菜去拿什么菜。

    这是我最近在网易云课堂上微专业课时老师进行的比喻,我觉得对理解很有帮助,在这里我也加入了自己的理解。

    web中的一些基本概念

    HTTP

    HTTP协议(Hyper Text Transfer Protocol,超文本传输协议)是用于从web服务器传输超文本到本地浏览器的传输协议,是因特网中的“多媒体信使”。它可以使浏览器更加高效,使网络传输减少。它不仅保证计算机正确快速地传输超文本文档,还确定传输文档中的哪一部分,以及哪部分内容首先显示(如文本先于图形)等。同时,HTTP使用的是可靠的数据传输协议,即使是来自于地球另一端的数据,它也可以确保数据在传输的过程中不会丢失和损坏,保证了用户在访问信息时的完整性。HTTP是互联网上应用最为广泛的一种协议,后面还会介绍其他的互联网常用协议(https,ftp,file,mailto等)。
    按照上述点餐流程理解的话就是厨师具备煎、炒、烹、炸、溜、爆、煸、蒸、烧、煮等多种烹调技法,你需要告诉厨师这道菜怎么做。

    web客户端和服务端

    web服务器是web资源的宿主,每天都有数以亿计的图片、HTML页面、视频、音频等资源在互联网上传输,而这些资源信息都是存储在web服务器(由于web服务器使用的是HTTP协议,所以也常常被称作HTTP服务器)上的。如果客户端向服务器发送HTTP请求,服务器会在HTTP响应中回送所请求的数据以及其他一些数据信息,包括对象,对象类型,对象长度等。

    这里写图片描述

    最常见的web客户端就是web浏览器,web浏览器向服务器请求HTTP对象,并将这些对象显示在你的屏幕上。其他的客户端还有“网络蜘蛛”(spiders)、“web机器人”(Web robots)等。这些客户端还被称作Agent代理,可以代表用户发起HTTP请求,后面提到的“网络蜘蛛”、“web机器人”都是自动代理,可以在无人监视的情况下,自动发起HTTP请求并获取相应内容,也就是我们常说的“网络爬虫”。

    URI

    Web上可用的每种资源 HTML文档、图像、视频片段、程序等,均由一个通用资源标识符(Uniform Resource Identifier, 简称”URI”)进行定位。这个就像是快递地址一样,快递小哥根据你的地址才能找到你你给你快递,然后你返回给快递小哥一个签收单,而这个地址在世界范围内唯一标识并定位资源信息。
    给定了URI,HTTP就可以解析出来对象,URI有两种形式——URL和URN。

    URL

    统一资源定义符(Uniform Resource Locator)是资源标识符最常用的形式,它提供了一种定位因特网上任意资源的手段。URL精确地说明了某资源的位置以及如何去访问它。
    这里写图片描述

    该图来自《HTTP权威指南》

    URL的语法会随着方案的不同而有所变化,但都遵循一个通用的语法规则。
    大多数URL方案的语法都遵循由这9个部分构成的通用格式上,但是几乎没有URL全部包含了这些组件。
    这里写图片描述
    下面对这些组件进行解释说明
    这里写图片描述

    该图来自《HTTP权威指南》

    正如前面所说几乎没有哪个URL包含了全部组件,这其中最重要三个部分是方案(scheme)、主机(host)和路径(path)。

    URN

    URL是个强有力的工具,它提供了一种可以在各种互联网协议间共享的统一命名机制,这大大简化了复杂的互联网世界。但是它并不完美,它表示的是实际的地址,而不是准确的名字,所以仔细思考会发现,如果我要请求的这个资源被移走了呢?也就是说快递小哥送快递时,发现收快递方搬家了,这就很懵逼了,那么这个URL也就没用了,没法定义资源位置了。
    所以为了应对这个问题,IETF小组已经对一种叫做统一资源名(Uniform Source Name)的新标准进行了研究,无论对象资源被搬移到哪个地方,URN都能为对象提供一个稳定的名称。
    不过要完成这种转换,还需要漫长的标准化过程,URL的问题并不是一个需要紧迫解决的问题,只是有所缺陷,但好在大家都已经接受它并熟练地进行使用,所以在可预见的未来互联网中还是会以URL为主。

    感兴趣的朋友可以试着了解一下PURL,它是用URL来实现URN的一个例子,可以在http://purl.oclc.org了解更多关于PURL的信息,这里不做赘述。

    HTTP报文

    现在我们来看看客户端是怎么与web服务器进行事务处理的。一个事务由一条请求命令和一个响应结果组成,这种通信是通过HTTP报文(HTTP message)的格式化数据块进行的。

    这里写图片描述

    HTTP支持几种不同的请求命令,这些命令被称为HTTP方法(HTTP method),每条HTTP请求都包含一个方法,这个方法告诉服务器执行什么样的动作,下面列出几个常用方法以供了解:

    这里写图片描述

    同时,在HTTP响应报文中还会包含一个状态码,它是一个由三位数字组成的代码,告知用户请求是否成功,或者是需要采取其他什么动作,常见的状态码:

    这里写图片描述

    这里我们只列出了几个常用状态码,其他还有很多状态码,其中100~199表示信息状态代码,200~299表示成功状态码,300~399表示重定向状态码,400~499表示客户端错误状态码,500~599表示服务器错误代码。

    知道了这些基本组件后,我们再来看一下HTTP报文的结构,HTTP报文是由一行行的简单字符串组成的。HTTP报文都是纯文本,而非二进制,这样更方便人们对其书写和阅读。HTTP只有请求报文(request message)和响应报文(response message)两种类型,没有其他类型,这两种报文的结构很类似。

    这里写图片描述

    这里写图片描述

    以上图片来自《HTTP权威指南》

    浏览器的工作流程

    在了解完web的工作流程后及相关基本概念后,再来了解一下浏览器的工作流程。浏览器是我们最常用的客户端工具,那它的工作流程是怎样的呢?在这之前我们先来了解一下IP地址的概念。

    IP地址是指互联网协议地址(英语:Internet Protocol Address,又译为网际协议地址),是IP Address的缩写。IP地址是IP协议提供的一种统一的地址格式,它为互联网上的每一个网络和每一台主机分配一个逻辑地址,以此来屏蔽物理地址的差异。

    这个概念是不是和前面介绍的URL很像?那其实URL没有使用数字形式的IP地址,它使用的是文本形式的域名,或者称为主机名。主机名就是IP地址比较人性化的别称。想象一下,每次访问网站的时候,需要输入的是一串IP地址,那得有多繁琐。所以可以通过一种名为域名服务(DNS)的机制帮我们将主机名转化为IP地址,这样繁琐的问题就简单化了。浏览器的工作流程也就基本清楚了。

    这里写图片描述

    连接

    大概介绍了web的工作流程和HTTP报文之后,我们来看一下报文是如何传输的。在HTTP客户端向服务器发送报文之前,需要用到我们前面所提到的IP地址和端口号在客户端与服务器之间建立一条TCP/IP连接。这里涉及到一个传输控制协议(Transmission Control Protocol,TCP)的概念。首先我们看一下HTTP网络协议栈

    这里写图片描述

    从图上我们可以看出,HTTP是个应用层协议。HTTP无需操心网络通信中的具体细节,这些细节全部交给通用的可靠的互联网传输协议TCP/IP。TCP具有以下几个特征

    • 无差错的数据传输
    • 按序传输(按照发送顺序送达)
    • 未分段的数据流(可以在任何时候以任意尺寸发出数据)

    所以只要建立了TCP连接,客户端与服务器之间的报文交换就不会丢失、不会被破坏、不会出现错序。在TCP中,你只需要知道服务器的IP地址以及运行在服务器上特定程序相关的端口号,就可以了,而具体到客户端与服务器之间是需要通过Socket“三次握手”进行连接,这里不做赘述。

    在解析域名,建立TCP/IP连接,发送http报文,得到响应结果后,服务器会断开TCP连接,浏览器显示内容。但是如果服务器或客户端在报文中增加connection:keep-alive的名/值对,就表示客户端与服务器之间会继续保持连接,在下次使用时可以继续使用该连接。

    原文地址:

    https://blog.csdn.net/m0_37466453/article/details/72752684#web%E7%9A%84%E5%9F%BA%E6%9C%AC%E5%B7%A5%E4%BD%9C%E6%B5%81%E7%A8%8B

    展开全文
  • 程序员工作流程

    千次阅读 2017-03-31 12:34:58
    虽然对如何编写程序没有严格的规定, 但大多数程序员都采用类似的流程。 该程序开发流程如下。 1. 确定程序要做什么,即搞清楚需求。 2. 编写源代码,这里是使用Python 集成开发环境IDLE 或其他文本编辑器编写...

    虽然对如何编写程序没有严格的规定, 但大多数程序员都采用类似的流程。

    该程序开发流程如下。

    1. 确定程序要做什么,即搞清楚需求。

    2. 编写源代码,这里是使用Python 集成开发环境IDLE 或其他文本编辑器编写Python 代码。这一步通常最有趣也最具挑战性,要求你创造性地解决问题。Python 源代码文件使用扩展名.py,如web.py、urlexpand.py、clean.py 等。

    3. 使用Python 解释器将源代码转换为目标代码。Python 将目标代码存储在.pyc 文件中, 例如,如果源代码存储在文件urlexpand.py 中, 目标代码将存储在文件urlexpand.pyc 中。

    4. 运行或执行程序。就Python 而言,通常紧接着第2 步自动完成这一步。实际上, Python 程序员很少直接与目标代码(.pyc 文件)交互。

    5. 最后,检查程序的输出。如果发现错误, 回到第2 步并尽力修复错误。修复错误的过程称为调试。开发庞大或复杂的程序时,可能大部分时间都用在调试上,因此经验丰富的程序员设计程序时,会尽力采用可最大限度地减少调试时间的方式。

    如图1-1 所示,这是个循环往复的过程: 编写程序,测试,修复错误,再测试……直到程序正确运行。

                   

    展开全文
  • 工作流程自定义

    2008-12-08 13:54:28
    由于企业的需求总是随着时间推移不断发生变化,加之各个企业内部所设置的办公流程不尽相同,一套通用性比较好的管理信息系统应该能让系统管理员自己定义公文转发的流程。  尽管笔者没有机会在已参与开发了的MIS中...

    开发比较复杂的企业多用户管理信息系统(MIS),不可能不涉及到系统内多个用户之间的数据文件的流转、审批等功能的开发。由于企业的需求总是随着时间推移不断发生变化,加之各个企业内部所设置的办公流程不尽相同,一套通用性比较好的管理信息系统应该能让系统管理员自己定义公文转发的流程。

      尽管笔者没有机会在已参与开发了的MIS中实现出文件转发流程自定义的功能,但是,早在2002年初就曾深入思考过这方面的设计。当时由于某些原因不能公开自己的设计思路,现在市面上已经有不少MIS产品提供这样的功能,笔者又已离职,所以是时候把我的设计思路整理出来,和大家分享。

      首先,让我们分析需求,制定目标。

      1)一般情况下,企业内的公文转发、审批是按部门或职位来转送,即对岗不对人。例如:某个流程的某个环节需要财务总监审批,日后财务总监换人,该流程应该不受影响。而且,流程中某个环节可能出现某个部门中的任何一人都能审批,或者需要该部门的所有人员共同审批。
      2)流程中转送,审批的公文一般分为文件和表单2种格式。文件格式的公文应该支持批处理,即一次可以转发多个文件,审批时可以只退回其中某一个不合格的文件,其他的文件可以转送到下一个环节继续处理。表单格式的公文应该能让用户自己定义表单格式,确定表单中的表项。同理,表单也应该支持批处理。
      3)流程中处理公文的动作应该能让用户自己定义。这样一旦日后增加了新的处理动作,也不用修改MIS系统的底层数据建模。当然,要实现新的处理动作,还是需要在业务逻辑层编写相应的代码,不过和修改底层数据建模比起来,工作量要少得多。
      4)每个流程的环节数不一定相同,应该能让用户设定环节数,指定公文流转中每个环节的发送部门和接受部门,处理模式,最长等待时间。
      5)当待处理的公文发出后,系统应该在等待时间中定期向该流程中下个环节的用户(们)发出通知,提醒该用户(们)及时处理,直至公文已被处理。如果超出最长等待时间,公文还未被用户(们)处理,此次流程处理失败。企业管理层可能会要求记录相关信息,以便在日后业务流程重组(BPR)时参考。
      6)某些企业由于特殊原因,在某个流程中要求实现跨环节处理。例如,该流程有6步,执行到第二个环节时要求处理后可以跳过中间三个环节,直接转到最后一个环节等候处理。其实,这种情况下,并不一定要在技术层面上实现其灵活性,这种特例毕竟是少数。用户只需定义一个新流程,把上面流程的第1,2,6步复制加入进来,2个流程之间用流程名来区分即可。一个优秀的系统架构设计师应该充分利用现有的工具,不要什么都自行架设开发。

      上面的需求对灵活性要求较高,抽象化程度较深,所以在表现层和业务逻辑层的开发量较大,初期投资较多,不过开发完毕后估计不需对底层数据库修改,即可满足日后不断变化的公文流转需求。如果不需要这么高的灵活性,可以按实际项目简化某些假设条件。下面按照上面的需求进行用例(use case)分析和数据建模。

      1)由于流程环节的发送方和接受方是对岗不对人,我们应该先描画出整个企业的机构设置,确定每个部门的权利职责。其中大的部门内可能有若干子部门,每个子部门内又有不同职位,负责处理相应的事务。所以,可先建立一个树形关系的数据表来保存企业结构,然后,采用权限表和用户组相结合的方式来保存每个部门每个职位的职能。这块的设计思路见我之前发布的“浅谈数据库设计技巧(上)、(下)”,我在下面直接给出大致的数据表结构:

    部门表(Department_table)
    名称    类型    约束条件    说明
    Dp_id        int             无重复     类别标识,主键
    Dp_name varchar(50) 不允许为空    类型名称,不允许重复
    Dp_father    int              不允许为空    该类别的父类别标识,如果是顶节点的话设定为某个唯一值
    Dp_layer varchar(6)      限定3层,初始值为000000 类别的先序遍历,主要为减少检索数据库的次数

    功能表(Function_table)
    名称    类型    约束条件   说明
    f_id int   无重复   功能标识,         主键
    f_name varchar(20) 不允许为空     功能名称,不允许重复
    f_desc   varchar(50) 允许为空        功能描述

    用户组表(User_group)
    名称    类型         约束条件   说明
    group_id       int                 无重复          用户组标识,主键
    group_name varchar(20)   不允许为空    用户组名称
    group_power varchar(100) 不允许为空    用户组权限表,内容为功能表f_id的集合

    用户表(User_table)
    名称    类型    约束条件   说明
    user_id int 无重复           用户标识,主键
    user_name varchar(20) 无重复 用户名
    user_pwd varchar(20)    不允许为空 用户密码
    user_type int 不允许为空 所属用户组标识,和User_group.group_id关联

      说明:其中,按部门的不同职位设置不同权限的用户组,如某个用户组为“市场部业务员”,该用户组的用户可在流程“报销申请”中发送报销申请。

      2)尽管流程中的公文分为文件和表单2种格式,但是每个文件/表单都应该有其唯一标识,名称等属性。所以,我们把公文抽象化,把这2种格式的公文的共有属性提取出来建立一张公文表。

    公文表(Document_table)
    名称    类型    约束条件   说明
    doc_id int   无重复         公文标识,       主键
    doc_name varchar(50) 不允许为空    公文名称
    doc_type char(1)          不允许为空    公文类型

      doc_type字段用来辨别公文格式,目前只有2种格式,可设“1”表示文件格式,“2”表示表单格式。估计未来新增公文格式不会太多,所以该字段只需一位字符。文件格式的公文一般是在文件内固定好格式,我们可用一个二进制的字段直接保存整个文件的内容。文件格式的公文需要建一个表来保存相关信息,其大致数据表如下:

    文件表(File_table)
    名称    类型    约束条件   说明
    file_id int 无重复 文件标识,主键
    file_name varchar(50) 不允许为空 文件名称
    file_value binary 不允许为空 文件内容
    ……

      表单格式的公文要让用户自己定义表单格式,确定表单中的表项。有两种方法来实现:
      ①每当用户建立一个新格式的表单时,就新建立一个表,把用户输入的表单表项当作该表的字段。这种方式的优点是表单查询速度较快方便,业务逻辑层的开发量较小。缺点是不太灵活,如果企业所使用的不同格式的表单较多(>20种),整个数据库的结构显得比较混乱,而且大部分表单中都有相同的字段,这样也增加了数据冗余。这种方式的数据建模如下:

    表单总表(Sheet_table)
    名称    类型    约束条件   说明
    sheet_id       int 无重复    表单标识,     主键
    sheet_name varchar(50) 不允许为空 表单名称
    table_name  varchar(20) 不允许为空 表单子表名,如Sub_table1/Sub_table2

    表单子表1(Sub_table1)
    名称    类型   约束条件   说明
    sub_id        int         无重复             表单子表标识,主键
    option1    varchar 不允许为空          表单表项1
    option2    varchar 不允许为空          表单表项2
    option3    varchar 不允许为空          表单表项3
    ……

    表单子表2(Sub_table2)
    名称    类型   约束条件   说明
    sub_id        int         无重复             表单子表标识,主键
    option1   varchar  不允许为空          表单表项1
    option2   varchar  不允许为空          表单表项2
    option3   varchar  不允许为空          表单表项3
    ……

    ……

      ②对表单再进行一个抽象,把表单看成由若干个表单表项所组合成的一个集合。这种方式的优点是相当灵活,用户建立新格式的表单时只用从已有表单表项中勾选出需要的表项即可,而且整个数据库结构清晰,没有数据冗余。缺点是开发比较复杂,工作量和上面相比高出不少,而且表单查询速度较慢。下面是这种方式的数据建模:

    表单总表(Sheet_table)
    名称    类型       约束条件   说明
    sheet_id       int                无重复           表单标识,主键
    sheet_name varchar(50) 不允许为空      表单名称

    表单表项表(Option_table)
    名称   类型    约束条件   说明
    op_id        int                无重复             表单表项标识,主键
    op_name  varchar(50)  不允许为空       表单表项名称
    op_length int                不允许为空       表单表项长度
    op_unit varchar(10)      允许为空          表单表项单位

    表单信息表(Sheetinfo_table)
    名称    类型    约束条件   说明
    info_id int   无重复   表单信息标识,主键
    sheet_id int 不允许为空 所属表单标识,和Sheet_table.sheet_id关联
    op_id  int 不允许为空 表单表项标识,和Option_table.op_id关联
    info_value varchar() 不允许为空 表单信息值

      3)我们可以把公文转发的流程抽象化,看作一个实体超类。建表如下:

    流程表(Flow_table)
    名称        类型         约束条件    说明
    flow_id            int                  无重复            流程标识,主键
    flow_name      varchar(50)    不允许为空      流程名称
    flow_stepnum int                   不允许为空      流程步数
    flow_desc       varchar(200)   允许为空          流程描述

      流程中的每一步都可以抽象化成从发送方至接受方的用例,其数据建模大致如下:

    处理动作表(Action_table)
    名称        类型       约束条件   说明
    a_id           int 无重复       动作标识,       主键
    a_name     varchar(20)  不允许为空      动作名称
    a_call        varchar(50)   不允许为空     动作所调用的模块
    a_desc      varchar(200)  允许为空        动作描述

      说明:如果采用面向过程的开发方式,如纯脚本语言,可以把每一个处理动作写成一个函数,调用a_call字段记录的函数,即可完成相应处理动作。如果采用面向对象的开发方式,可以用COM组件来封装处理动作,则a_call用来记录相应的COM组件的接口方法。如果是在.NET Framework环境下,可以采用Web服务的方式。当然,发送方、接受方以及公文标识是作为输入参数的。

    流程环节表(Step_table)
    名称    类型   约束条件   说明
    step_id       int          无重复        环节标识,主键
    belong       int          不允许为空 所属流程标识,和Flow_table.flow_id关联
    setp_order int          不允许为空 所属流程的步骤次序
    sender       int          不允许为空 发送方标识,和User_group.group_id关联
    receiver     int          不允许为空 接受方标识,和User_group.group_id关联
    a_id           int          不允许为空 处理动作标识,和Action_table.a_id关联
    a_type       int          不允许为空 接受方所需的处理人数
    max_wait   int          不允许为空 最长等待时间
    wait_unit varchar(5) 不允许为空 等待时间的单位

      说明:a_type用来确定接受方所需的处理人数,“0”表示需同职位的所有人一起处理,“1”表示只需该职位的任意一名员工处理,“2”表示需该职位的任意两名员工一起处理,依次递推……一起处理的方式和处理动作有关,例如是投票方式,少数服从多数,还是某人有一票否决权等等。可能针对某些处理动作还得细化,进行相关的数据建模,这里我就不细分下去了。

      4)下面分析公文转发的流程环节记录。此时相当于实例化一个流程环节的对象,发送方和接受方应具体联系到管理信息系统的某个(些)用户,而不是某个用户组。每经过一环节,我们除了要保存这方面的信息,还必须保存该环节所转发的公文,以及处理状况等信息。而且,该环节所转发公文数量大于等于一,所以可以参考我之前发布的“浅谈数据库设计技巧(下)”中的“简洁的批量m:n设计”,建表大致如下:

    流程环节记录表(Step_log)
    名称   类型         约束条件       说明
    log_id      int                无重复               环节记录标识,主键
    step_id    int                不允许为空         环节标识,和Step_table.step_id关联
    sender   varchar(100)  不允许为空         发送用户标识,相关用户组的User_table.user_id的集合
    receiver varchar(100)  不允许为空         接受用户标识,相关用户组的User_table.user_id的集合
    doc_id     int                 不允许为空        转发公文标识,和Document_table.doc_id关联
    batch_no int                 不允许为空        批量转发公文编号,同一流程环节转发的batch_no相同
    state char(1)                不允许为空        处理状态
    sub_date datetime        不允许为空      提交时间
    res_date datetime        允许为空          处理回复时间
    comment varchar(255) 允许为空   处理回复注释

      说明:
      ①同一流程环节转发的batch_no和该批第一条入库的log_id相同。举例:假设当前最大log_id是64,接着某用户一次转发了3件公文,则批量插入的3条流程环节记录的batch_no都是65。之后另外一个用户通过某个流程环节转发了一件公文,再插入流程环节记录的batch_id是68。
      ②state字段用来描述其流程环节所处的状态,是正待处理,已被处理通过,已被处理驳回,还是超出最长等待时间被系统自动收回等等。通过这个字段我们对接受用户发出处理通知,还可以可以很容易的查询出所有超出最长等待时间被系统自动收回的流程,以便企业管理层在日后业务流程重组(BPR)时参考。
      ③如果某份公文在某个流程中的某个环节被处理驳回,可以看作该公文在此次流程中被驳回至起始点,最初发送用户可根据处理回复注释修改公文后重新发送。


      总结:
      企业公文流程自定义应该是把企业内已经固定了的公文转发、审批流程电子化,实现高效的无纸化办公,对于非正式的口头讨论、商议、集会等商务活动并不适合。当企业累积了一定数量的电子化公文转发的记录后,可以在商业咨询专家和技术开发人员的协助下对其进行数据挖掘,分析出其中的低效、无用环节,进行优化重组,最终提高整个企业的竞争力。作为技术开发人员,我们应该根据企业实际运作情况、资金投入规模,选择当前时期最适合的技术解决方案,切不可为了展示自己的技术实力,而把开发复杂化,企业开发并不是追求技术最先进,而是最适合。

    展开全文
  • SpringMVC的简介和工作流程

    万次阅读 多人点赞 2019-04-08 17:15:16
    一、简介 Spring MVC属于SpringFrameWork的后续产品,已经融合在Spring Web Flow里面。Spring 框架提供了构建 Web 应用程序的全功能 MVC 模块...二、工作流程 1、用户发送请求至前端控制器DispatcherServlet。...

    一、简介

        Spring MVC属于SpringFrameWork的后续产品,已经融合在Spring Web Flow里面。Spring 框架提供了构建 Web 应用程序的全功能 MVC 模块。SpringMVC是一种web层的mvc框架,用于替代servlet(处理响应请求,获取表单参数,表单验证等)

    二、工作流程

    1、用户发送请求至前端控制器DispatcherServlet。

    2、DispatcherServlet收到请求调用HandlerMapping处理器映射器。

    3、处理器映射器找到具体的处理器(可以根据xml配置、注解进行查找),生成处理器对象及处理器拦截器(如果有则生成)一并返回给DispatcherServlet。

    4、 DispatcherServlet调用HandlerAdapter处理器适配器。

    5、HandlerAdapter经过适配调用具体的处理器(Controller,也叫后端控制器)。

    6、Controller执行完成返回ModelAndView。

    7、HandlerAdapter将controller执行结果ModelAndView返回给DispatcherServlet。

    8、DispatcherServlet将ModelAndView传给ViewReslover视图解析器。

    9、ViewReslover解析后返回具体View.

    10、DispatcherServlet根据View进行渲染视图(即将模型数据填充至视图中)。 

    11、DispatcherServlet响应用户。

    三、理解

    1、为什么要使用springMVC?

        SpringMVC是一种基于Java,实现了Web MVC设计模式,请求驱动类型的轻量级Web框架,即使用了MVC架构模式的思想,将Web层进行职责解耦。基于请求驱动指的就是使用请求-响应模型,框架的目的就是帮助我们简化开发,SpringMVC也是要简化日常Web开发。(处理业务数据的对象和显示业务数据的视图之间存在紧密耦合)

    2、什么是MVC设计模式?

        MVC即Model-View-Controller,将应用按照Model(模型)、View(视图)、Controller(控制)这样的方式分离。

        视图(View):代表用户交互界面,对于Web应用来说,可以是HTML,也可能是jsp、XML和Applet等。一个应用可能有很多不同的视图,MVC设计模式对于视图的处理仅限于视图上数据的采集和处理,以及用户的请求,而不包括在视图上的业务流程的处理。业务流程的处理交予模型(Model)处理。

        模型(Model):是业务的处理以及业务规则的制定。模型接受视图请求的数据,并返回最终的处理结果。业务模型的设计是MVC最主要的核心。MVC设计模式告诉我们,把应用的模型按一定的规则抽取出来,抽取的层次很重要,抽象与具体不能隔得太远,也不能太近。MVC并没有提供模型的设计方法,而只是组织管理这些模型,以便于模型的重构和提高重用性。

        控制(Controller):可以理解为从用户接收请求, 将模型与视图匹配在一起,共同完成用户的请求。划分控制层的作用也很明显,它清楚地告诉你,它就是一个分发器,选择什么样的模型,选择什么样的视图,可以完成什么样的用户请求。控制层并不做任何的数据处理。

    3、SpringMVC的特点

    • 清晰的角色划分:控制器(controller)、验证器(validator)、 命令对象(command object)、表单对象(formobject)、模型对象(model object)、 Servlet分发器(DispatcherServlet)、处理器映射(handler mapping)、视图解析器(view resolver)等。每一个角色都可以由一个专门的对象来实现。
    • 强大而直接的配置方式:将框架类和应用程序类都能作为JavaBean配置,支持跨多个context的引用,例如,在web控制器中对业务对象和验证器(validator)的引用。
    • 可适配、非侵入:可以根据不同的应用场景,选择合适的控制器子类 (simple型、command型、form型、wizard型、multi-action型或者自定义),而不是从单一控制器 (比如Action/ActionForm)继承。
    • 可重用的业务代码:可以使用现有的业务对象作为命令或表单对象,而不需要去扩展某个特定框架的基类。
    • 可定制的绑定(binding) 和验证(validation):比如将类型不匹配作为应用级的验证错误, 这可以保存错误的值。再比如本地化的日期和数字绑定等等。在其他某些框架中,你只能使用字符串表单对象,需要手动解析它并转换到业务对象。
    • 可定制的handlermapping和view resolution:Spring提供从最简单的URL映射, 到复杂的、专用的定制策略。与某些webMVC框架强制开发人员使用单一特定技术相比,Spring显得更加灵活。
    • 灵活的model转换:在Springweb框架中,使用基于Map的 键/值对来达到轻易地与各种视图技术的集成。
    • 可定制的本地化和主题(theme)解析:支持在JSP中可选择地使用Spring标签库、支持JSTL、支持Velocity(不需要额外的中间层)等等。
    • 简单而强大的JSP标签库(SpringTag Library):支持包括诸如数据绑定和主题(theme) 之类的许多功能。
    • JSP表单标签库:在Spring2.0中引入的表单标签库,使得在JSP中编写 表单更加容易。
    • Spring Bean的生命周期可以被限制在当前的HTTP Request或者HTTP Session。

    4、SpringMVC的优点

    • 让我们能非常简单的设计出干净的Web层和薄薄的Web层
    • 进行更简洁的Web层的开发
    • 天生与Spring框架集成(如IoC容器、AOP等)
    • 提供强大的约定大于配置的契约式编程支持
    • 非常灵活的数据验证、格式化和数据绑定机制
    • 支持Restful风格

    5、SpringMVC的入门程序

    web.xml

    <web-app>
        <servlet>
            <!-- 加载前端控制器 -->
            <servlet-name>springmvc</servlet-name>
            <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
            <!-- 
      	       加载配置文件
      	       默认加载规范:
      	       * 文件命名:servlet-name-servlet.xml====springmvc-servlet.xml
      	       * 路径规范:必须在WEB-INF目录下面
      	       修改加载路径:
            -->
            <init-param>
                <param-name>contextConfigLocation</param-name>
                <param-value>classpath:springmvc.xml</param-value>   
            </init-param>
        </servlet>
        <servlet-mapping>
            <servlet-name>springmvc</servlet-name>
            <url-pattern>*.do</url-pattern>
        </servlet-mapping>
    </web-app>

    springmvc.xml

    <beans>
    	<!-- 配置映射处理器:根据bean(自定义Controller)的name属性的url去寻找handler;springmvc默认的映射处理器是BeanNameUrlHandlerMapping-->
    	<bean class="org.springframework.web.servlet.handler.BeanNameUrlHandlerMapping"></bean>
    	
    	<!-- 配置处理器适配器来执行Controller ,springmvc默认的是SimpleControllerHandlerAdapter
    	-->
    	<bean class="org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter"></bean>
    	
    	<!-- 配置自定义Controller -->
    	<bean id="myController" name="/hello.do" class="org.controller.MyController"></bean>
    	
    	<!-- 配置sprigmvc视图解析器:解析逻辑视图; 
    		后台返回逻辑视图:index
    		视图解析器解析出真正物理视图:前缀+逻辑视图+后缀====/WEB-INF/jsps/index.jsp
    	-->
    	<bean class="org.springframework.web.servlet.view.InternalResourceViewResolver">
    		<property name="prefix" value="/WEB-INF/jsps/"></property>
    		<property name="suffix" value=".jsp"></property>		
    	</bean>
    </beans>
    

    自定义处理器

    public class MyController implements Controller{
    
    	public ModelAndView handleRequest(HttpServletRequest arg0,
    			HttpServletResponse arg1) throws Exception {
    		ModelAndView mv = new ModelAndView();
    		//设置页面回显数据
    		mv.addObject("hello", "欢迎学习springmvc!");
    		
    		//返回物理视图
    		//mv.setViewName("/WEB-INF/jsps/index.jsp");
    		
    		//返回逻辑视图
    		mv.setViewName("index");
    		return mv;
    	}
    }
    

    6、SpringMVC常用注解及其作用

    @Controller:标识这个类是一个控制器

    @RequestMapping:给控制器方法绑定一个uri

    @ResponseBody:将java对象转成json,并且发送给客户端

    @RequestBody:将客户端请求过来的json转成java对象

    @RequestParam:当表单参数和方法形参名字不一致时,做一个名字映射

    @PathVarible:用于获取uri中的参数,比如user/1中1的值

    Rest风格的新api

    @RestController相当于@Controller+ @ResponseBody

    @GetMapping@DeleteMapping@PostMapping@PutMapping

    其他注解

    @SessionAttribute:声明将什么模型数据存入session

    @CookieValue:获取cookie值

    @ModelAttribute:将方法返回值存入model中

    @HeaderValue:获取请求头中的值

    7、SpringMVC和Struts2的对比

    框架机制:SpringMVC的入口是servlet,而Struts2是filter。

    Filter在容器启动后就初始化,服务停止后销毁,晚于Servlet;Servlet在是在调用时初始化,先于Filter调用,服务停止后销毁。

    拦截机制

        Struts2:1、Struts2框架是类级别的拦截,每次请求就会创建一个Action,和Spring整合时Struts2的ActionBean注入作用域是原型模式prototype(否则会出现线程并发问题),然后通过setter,getter吧request数据注入到属性;

        2、一个Action对应一个request,response上下文,在接收参数时,可以通过属性接收,说明属性参数是让多个方法共享的;

        3、Action的一个方法可以对应一个url,而其类属性却被所有方法共享,这也就无法用注解或其他方式标识其所属方法了。

        SpringMVC:1、SpringMVC是方法级别的拦截,一个方法对应一个Request上下文,所以方法直接基本上是独立的,独享request,response数据。而每个方法同时又何一个url对应,参数的传递是直接注入到方法中的,是方法所独有的。处理结果通过ModeMap返回给框架;
        2、在Spring整合时,SpringMVC的Controller Bean默认单例模式Singleton,所以默认对所有的请求,只会创建一个Controller,有应为没有共享的属性,所以是线程安全的,如果要改变默认的作用域,需要添加@Scope注解修改;

    Struts2有自己的拦截Interceptor机制,SpringMVC这是用的是独立的Aop方式,这样导致Struts2的配置文件量还是比SpringMVC大。

    性能方面:SpringMVC实现了零配置,由于SpringMVC基于方法的拦截,有加载一次单例模式bean注入。而Struts2是类级别的拦截,每次请求对应实例一个新的Action,需要加载所有的属性值注入,所以,SpringMVC开发效率和性能高于Struts2。

    配置方面:spring MVC和Spring是无缝的。从这个项目的管理和安全上也比Struts2高(当然Struts2也可以通过不同的目录结构和相关配置做到SpringMVC一样的效果,但是需要xml配置的地方不少);
    SpringMVC可以认为已经100%零配置。

    设计思想:Struts2更加符合OOP的编程思想, SpringMVC就比较谨慎,在servlet上扩展。

    集成方面:SpringMVC集成了Ajax。

    注意:springmvc是单例模式的框架,但它是线程安全的,因为springmvc没有成员变量,所有参数的封装都是基于方法的,属于当前线程的私有变量. 因此是线程安全的框架。所以效率高。

    struts action是多例的。所以可以使用成员变量获取参数。所以效率低。

    展开全文
  • 软件测试工作流程概括与总结

    万次阅读 多人点赞 2018-08-08 23:37:45
    最近在为面试新工作做准备,所以想想整理一下软件测试的基本工作流程,大致梳理一遍,这样也便于自己在面试过程中可以沉着的面对面试管的测试工作如何进行的问题。 首先,作为测试人员需要学习并了解业务,分析需求...
  • PHP脚本程序工作流程

    千次阅读 2019-05-10 10:59:12
    运行PHP脚本程序,必须借助PHP预处理器、WEB服务器和WEB浏览器,必要时还需借助数据库服务器。其中WEB服务器的功能是解析HTTP,PHP预处理器的功能是解释PHP代码,WEB浏览器的功能是显示PHP程序的执行结果,数据库...
  • 软件项目工作流程

    千次阅读 2014-11-11 14:01:04
    如果团队很小,需求经理的角色由项目经理担当,测试经理的角色有开发经理担当 如果一个人很全能,所有角色一个人担当 但不过几个人,软件开发的流程其中角色所要做的工作不能少
  • SpringMVC框架工作流程图及工作原理

    万次阅读 多人点赞 2018-07-10 09:13:39
    SpringMVC框架的工作原理图:SpringMVC的具体工作原理1、客户端用户发送请求至前端控制器DispatcherServlet。2、DispatcherServlet收到请求调用HandlerMapping处理器映射器。3、HandlerMapping处理器映射器找到具体...
  • UE工作流程

    千次阅读 2015-04-20 13:28:06
    一、 编写目的界面的质量要靠所有环节的人员来保证... 二、 适用人员UE员工三、 部门工作流程 以下是文字说明 1. 第一步交互设计 交互人员根据需求规格说明书(需求人员提供)的内容进行界面交互稿的制作。 交互人
  • MapReduce简述、工作流程

    万次阅读 2018-02-28 15:03:00
    MR编程模型之执行步骤:  1、准备map处理的输入数据  2、mapper处理  3、Shuffle  4、Reduce处理  5、结果输出 (input)&lt;k1,v1&gt; -&gt; map -&gt;&lt;k2,v2&...(o
  • struts1工作流程

    千次阅读 2010-01-12 10:10:00
    Struts在Tomcat中的安装配置及工作流程1.准备工作 安装JDK及Tomcat,并分别设置环境变量:JAVA_HOME、CLASSPATH、COMCAT_HOME,并确保Tomcat已正常工作。本文以jdk1.5和Tomcat5.5.12为环境介绍Struts在Tomcat中的...
  • MySQL逻辑架构及工作流程

    千次阅读 2018-08-31 18:43:02
    同时,MySql既可以嵌入到应用程序中,也可以支持数据仓库、内容索引和部署软件、高可用的冗余系统、在线事务处理系统等各种应用类型。  为了更心如的理解MySql服务器,我们需要理解MySql各部件之间如何协同工作。...
  • 图解EJB工作流程

    千次阅读 2014-07-21 17:14:29
    学习EJB需要对JNDI和RMI方面知识有一定的了解。 JNDI为EJB提供命名和目录服务
  • Mapreduce工作流程与简介

    千次阅读 2019-06-14 14:43:49
    最近几天一直在学习关于大数据方面的相关技术,今天学习了MapReduce的工作流程,让我对数据地处理有了新的认识,接下来我分享一下关于MapReduce2.0的工作流程 Mapreduce简介 Hadoop MapReduce 源于Google发表的 ...
  • Gitflow工作流程

    万次阅读 2014-01-02 08:36:45
    在工作场合实施Git的时候,有很多种工作流程可供选择,此时反而会让你手足无措。本文推荐了一种最常用的Git工作流程
  • OpenGL工作流程

    千次阅读 2012-04-25 11:40:12
    整个OpenGL的基本工作流程如下图:    其中几何顶点数据包括模型的顶点集、线集、多边形集,这些数据经过流程图的上部,包括运算器、逐个顶点操作等;图像数据包括象素集、影像集、位图集等,图像象素数据...
  • 标准的产品设计工作流程

    千次阅读 2011-11-08 14:37:24
    每个产品团队都会有自己的工作流程,无论这个工作流程是否最高效、是否体现最大价值,但是我认为只要这个流程能够为实现工作目标提供过程的保障就可以算是好的流程。 对于流程本身而言,可以因团队不同或工作任务...
  • SA工作流程

    千次阅读 2017-07-03 10:03:53
    最近从应用软件开发转岗为SA,首当其冲的就是要了解这个岗位的职责。概括地来看,SA日常工作包括:驱动软件版本更新和管理、联络软件及驱动厂商、技术支持、产品研发问题定位与追踪。
  • Spring MVC工作流程

    万次阅读 2017-07-28 20:54:51
    Spring MVC工作流程
  • IPQC工作职责和IPQC工作流程IPQC,in process quality contrl, 过程检验, 简单的说:工作内容包括:首件检查、各类变更文件的跟踪。4M1E的巡查。发现异常的提出、跟踪与验证。IPQC工作意义: 防止出现批量不合格品,...
1 2 3 4 5 ... 20
收藏数 3,303,058
精华内容 1,321,223
关键字:

工作流程