Java B/S模式
答案:6 悬赏:60
解决时间 2021-01-13 23:22
- 提问者网友：风月客
- 2021-01-13 00:50
Java B/S模式
最佳答案
- 二级知识专家网友：撞了怀
- 2021-01-13 02:30
B/S（Browser/Server）结构即浏览器和服务器结构。
它是随着Internet技术的兴起，对C/S结构的一种变化或者改进的结构。在这种结构下，用户工作界面是通过WWW浏览器来实现，极少部分事务逻辑在前端（Browser）实现，但是主要事务逻辑在服务器端（Server）实现，形成所谓三层3-tier结构。这样就大大简化了客户端电脑载荷，减轻了系统维护与升级的成本和工作量，降低了用户的总体成本（TCO）。
以目前的技术看，局域网建立B/S结构的网络应用，并通过Internet/Intranet模式下数据库应用，相对易于把握、成本也是较低的。
它是一次性到位的开发，能实现不同的人员，从不同的地点，以不同的接入方式（比如LAN, WAN, Internet/Intranet等）访问和操作共同的数据库；它能有效地保护数据平台和管理访问权限，服务器数据库也很安全 。特别是在JAVA这样的跨平台语言出现之后，B/S架构管理软件更是方便、快捷、高效。
它是随着Internet技术的兴起，对C/S结构的一种变化或者改进的结构。在这种结构下，用户工作界面是通过WWW浏览器来实现，极少部分事务逻辑在前端（Browser）实现，但是主要事务逻辑在服务器端（Server）实现，形成所谓三层3-tier结构。这样就大大简化了客户端电脑载荷，减轻了系统维护与升级的成本和工作量，降低了用户的总体成本（TCO）。
以目前的技术看，局域网建立B/S结构的网络应用，并通过Internet/Intranet模式下数据库应用，相对易于把握、成本也是较低的。
它是一次性到位的开发，能实现不同的人员，从不同的地点，以不同的接入方式（比如LAN, WAN, Internet/Intranet等）访问和操作共同的数据库；它能有效地保护数据平台和管理访问权限，服务器数据库也很安全 。特别是在JAVA这样的跨平台语言出现之后，B/S架构管理软件更是方便、快捷、高效。
全部回答
- 1楼网友：思契十里
- 2021-01-13 06:47
B/S 是指基于web的开发
JSP+Servlet+JavaBean 是MVC模式
2者有本质的区别
JSP+Servlet+JavaBean 是MVC模式
2者有本质的区别
- 2楼网友：山有枢
- 2021-01-13 05:42
B/S模式也就是Browser/Server（浏览器/服务器）
至于JSP+Servlet+JavaBean也就是所谓的MVC模式
M Model 模型，负责数据持久层 JavaBean
V View 视图，负责表现层 JSP
C Controler 控制器，负责流程控制，业务逻辑处理 Servlet
说简单点就是用JavaBean来负责数据库方面（数据库连接，信息读取等等）
JSP负责页面显示，Servlet负责流程控制
举个简单的例子：
登录页面（login.htm）数据提交----->Servlet(Servlet进行判断，在Servlet中调用JavaBean连接数据库并查询是否有该用户存在) 页面跳转------->登录成功的页面（比如用户中心，这里可以用JSP也就是表现层）或者登录失败提示页面
至于JSP+Servlet+JavaBean也就是所谓的MVC模式
M Model 模型，负责数据持久层 JavaBean
V View 视图，负责表现层 JSP
C Controler 控制器，负责流程控制，业务逻辑处理 Servlet
说简单点就是用JavaBean来负责数据库方面（数据库连接，信息读取等等）
JSP负责页面显示，Servlet负责流程控制
举个简单的例子：
登录页面（login.htm）数据提交----->Servlet(Servlet进行判断，在Servlet中调用JavaBean连接数据库并查询是否有该用户存在) 页面跳转------->登录成功的页面（比如用户中心，这里可以用JSP也就是表现层）或者登录失败提示页面
- 3楼网友：酒安江南
- 2021-01-13 04:59
jsp用来做显示，servlet用来做控制器，javabean做业务逻辑，
其实就是MVC模式。
其实就是MVC模式。
- 4楼网友：三千妖杀
- 2021-01-13 04:39
在Java B/S开发模式有以下几种：
一、JSP+JDBC
这是最简单的一种开发模式是页面+逻辑处理，映射到技术上反应出来的有Jsp+Jdbc，在基于这类的实现中在View层也就是jsp页面上负责数据的显示、逻辑处理，结合jdbc完成数据的持久化，在小型的项目中，人们确实发现这种方式是最为方便的，但在复杂的项目以及需求不断变化的项目中，人们慢慢的发现这种方式造成了不少的问题，首先是调试的问题，想想在一个jsp页面中进行排错是多么的困难，其次是修改的问题，为了满足用户需求的一个小小的变化，都需要去改不少的页面，而且很多时候由于写的时间长了，自己都需要回忆很久才能想起是怎么回事，更不用说如果人员流动了会怎么样，同时还带来开发效率的问题，由于需要缺少足够的调试的支持，需要较为熟练的开发人员才能快速的完成，对于一般的人员来说需要一定的适应和学习过程，当然伴随而来的还有诸如修改界面的时候一不小心少copy了点代码什么造成的错，最大的问题可能还是重用的问题，通常会造成N多同样的代码在页面上copy来copy去的，总结下来在这种模式下有几个比较重大的问题就是：
1、调试问题。
2、维护问题，显示和逻辑处理在一起导致了修改显示的时候较为困难，至于修改代码则因为之前的调试问题导致了困难，同时由于逻辑均在页面上后期接手人员需要一段时间去理解。
3、代码重用性问题。
但同样它还是存在优点的，那就是可以很快的上手，但由于调试和维护性问题确实太大了，所以在现在也是基本不再采用这种方式了。
二、JSP+JavaBean
在经历了jsp+jdbc阶段后，开始考虑怎么样去解决上面三个问题，这个时候就诞生了诸JSP+JavaBean这样的技术体系，在这个体系中由jsp页面负责显示以及接收页面请求，并调用相应的JavaBean来完成逻辑处理，在获取其返回的处理数据后转到相应的页面进行显示。在这样的技术体系中，由于逻辑是由JavaBean来完成的，可以对其进行调试了，代码的重用性一定程度上也得到了提高。刚开始的时候用这样的技术体系确实发现比以前用jsp+jdbc爽了很多，但随着用多了，慢慢又发现了问题，那就是在页面中需要编写对于页面请求数据的获取，还得根据请求去调用相应的javabean，并根据javabean的处理结果转入相应的页面，这同样造成了修改的麻烦，毕竟是去页面上修改这些逻辑，总结下来在这种Java B/S开发模式下有比较重大的问题就是：
1、代码重用性以及维护性问题。但这里的代码重用性问题和jsp+jdbc的就不同，在逻辑处理部分现在已经可以重用了，但现在在各个页面就不得不重复的写获取页面请求的参数、相应的调用Model、根据Model的处理结果转发页面，这样的话就导致了在改的时候需要到处去找，造成了维护的复杂。
2、系统结构不清晰。毕竟仍然是在页面控制整个响应页面事件的处理流程，这个时候就造成了很多页面中出现完全相同的jsp代码，而且控制代码在页面，仍然是不便操作，例如对于JavaBean的调用等，而且由于获取javabean的数据需要转发的缘故，其实通常就是在最终的显示页面上加上上面的控制事件处理流程的代码，并没有真正的做到显示和处理的分离。
同样，它的优点在于分离了显示和业务逻辑处理，增强了可调试以及维护性，而且也是很容易上手的，对于小型项目来说仍然是可选的方案之一。
三、基于MVC Framework
在经历了上面的Jsp+JavaBean的Java B/S开发模式后，我们发现其实现在最需要的就是在jsp、javabean之间能有个东西自动完成页面请求数据的封装、根据请求调用相应的javabean、同时根据javabean的处理结果返回至相应的View，有了这样的思想后，发现smalltalk中的MVC思想很适合这种场景，于是便在Java B/S开发中引入了MVC思想，在这里也简单的介绍下MVC思想，MVC强调View和Model的分离，View所面对的是Controller，由Controller负责与Model进行交互，View只负责显示页面以及显示逻辑的处理，显示逻辑指的是诸如第一行要显示蓝色、第二行要显示红色这样的显示方面的处理，Controller负责接受页面请求，并将其请求数据进行封装，同时根据请求调用相应的Model进行逻辑处理，在Model处理后返回结果数据到Controller，Controller将根据此数据调用相应的View，并将此数据传递给View，由View负责将数据进行融合并最终展现。MVC带来的优点很明显的体现出来了，基于一个这样的MVC Framework的话开发人员可以按照一种固定的模式进行开发，规范了整个开发过程，提高了质量以及系统结构的清晰性，并由于保证了View/Model的分离，使得一个Model可以对于多种显示形式的View，需要的仅仅是去改变View和Controller。
按照MVC思想，最容易想到的实现方案莫过于jsp+servlet+javabean，在这里面jsp对应着View，servlet对应着Controller，javabean对应着Model，因为采用servlet可使用servlet container已经封装好的页面数据请求对象HttpServletRequest，这样就省去了自己封装页面请求数据的工作，作为Controller同时还需要承担根据请求调用对应的javabean，最简单的做法无非就是在Servlet中直接根据某种逻辑(诸如反射或接口)调用相应的bean进行执行，之后将HttpServletRequest、HttpServletResponse作为参数传入javabean进行处理，javabean从HttpServletRequest中获取请求数据，将返回的结果数据放入HttpServletResponse，整个过程结束后继续由Controller接手进行处理，这个时候作为Controller的servlet将根据处理的结果返回相应的页面，在这个模型使用时人们慢慢的发现了一个问题，那就是随着jsp、javabean的变化造成了controller的不断修改，需要修改其中调用相应javabean以及转发相应页面的部分，为了解决这个问题，首先想到的是应该分离根据请求调用相应javabean的步骤，这个时候采用了设计模式中的front controller+application controller的方法，front controller负责接受页面请求并进行封装，同时将此数据对象传递至application controller，由application controller来负责调用相应的bean，这样的设计其实都是遵循着一个设计原则，就是职责单一，通常实现application controller的模式是Command模式，在这种情况下MVC Framework的结构体系就演变成了view+controller(front+application)+model。
在完成了上述演变后慢慢又发现了一个问题，就是model依赖于了httpservletrequest，这样造成的一个问题就是没法测试，仍然要不断重启服务器来测试，当然与此同时的发展是model层的细化，细化成用于响应页面请求的action Layer+Domain Model Layer+Persistent Layer，在这里不去讨论后面层次的问题，因为作为MVC Framework它并不管你Model层是怎么个处理流程的。
慢慢也发现了另外一个问题，那就是变化经常要影响到controller的修改，于是便引入了采用配置文件的解决方法，编写action的配置文件，在配置文件中控制根据action的返回结果转入相应的View，这样的话在将来需要改变的时候只需要去改变这个配置文件就可以了，保证了Controller的稳定，这是典型的设计中的重点考虑因素，分离变化和不变化的，让变化造成的影响最小。
但在引入了上面的配置文件后，慢慢又发现了问题，那就是手写配置文件总是容易出各种各样的问题，这个时候采用图形化的界面来生成配置文件的想法又有了，这也就造就了page flow的诞生，当然，这只是page flow的一小部分功能。
当然，随着MVC的发展，也带动了其他相关技术的发展，如异步请求/响应模式(ajax、amowa)等。
一、JSP+JDBC
这是最简单的一种开发模式是页面+逻辑处理，映射到技术上反应出来的有Jsp+Jdbc，在基于这类的实现中在View层也就是jsp页面上负责数据的显示、逻辑处理，结合jdbc完成数据的持久化，在小型的项目中，人们确实发现这种方式是最为方便的，但在复杂的项目以及需求不断变化的项目中，人们慢慢的发现这种方式造成了不少的问题，首先是调试的问题，想想在一个jsp页面中进行排错是多么的困难，其次是修改的问题，为了满足用户需求的一个小小的变化，都需要去改不少的页面，而且很多时候由于写的时间长了，自己都需要回忆很久才能想起是怎么回事，更不用说如果人员流动了会怎么样，同时还带来开发效率的问题，由于需要缺少足够的调试的支持，需要较为熟练的开发人员才能快速的完成，对于一般的人员来说需要一定的适应和学习过程，当然伴随而来的还有诸如修改界面的时候一不小心少copy了点代码什么造成的错，最大的问题可能还是重用的问题，通常会造成N多同样的代码在页面上copy来copy去的，总结下来在这种模式下有几个比较重大的问题就是：
1、调试问题。
2、维护问题，显示和逻辑处理在一起导致了修改显示的时候较为困难，至于修改代码则因为之前的调试问题导致了困难，同时由于逻辑均在页面上后期接手人员需要一段时间去理解。
3、代码重用性问题。
但同样它还是存在优点的，那就是可以很快的上手，但由于调试和维护性问题确实太大了，所以在现在也是基本不再采用这种方式了。
二、JSP+JavaBean
在经历了jsp+jdbc阶段后，开始考虑怎么样去解决上面三个问题，这个时候就诞生了诸JSP+JavaBean这样的技术体系，在这个体系中由jsp页面负责显示以及接收页面请求，并调用相应的JavaBean来完成逻辑处理，在获取其返回的处理数据后转到相应的页面进行显示。在这样的技术体系中，由于逻辑是由JavaBean来完成的，可以对其进行调试了，代码的重用性一定程度上也得到了提高。刚开始的时候用这样的技术体系确实发现比以前用jsp+jdbc爽了很多，但随着用多了，慢慢又发现了问题，那就是在页面中需要编写对于页面请求数据的获取，还得根据请求去调用相应的javabean，并根据javabean的处理结果转入相应的页面，这同样造成了修改的麻烦，毕竟是去页面上修改这些逻辑，总结下来在这种Java B/S开发模式下有比较重大的问题就是：
1、代码重用性以及维护性问题。但这里的代码重用性问题和jsp+jdbc的就不同，在逻辑处理部分现在已经可以重用了，但现在在各个页面就不得不重复的写获取页面请求的参数、相应的调用Model、根据Model的处理结果转发页面，这样的话就导致了在改的时候需要到处去找，造成了维护的复杂。
2、系统结构不清晰。毕竟仍然是在页面控制整个响应页面事件的处理流程，这个时候就造成了很多页面中出现完全相同的jsp代码，而且控制代码在页面，仍然是不便操作，例如对于JavaBean的调用等，而且由于获取javabean的数据需要转发的缘故，其实通常就是在最终的显示页面上加上上面的控制事件处理流程的代码，并没有真正的做到显示和处理的分离。
同样，它的优点在于分离了显示和业务逻辑处理，增强了可调试以及维护性，而且也是很容易上手的，对于小型项目来说仍然是可选的方案之一。
三、基于MVC Framework
在经历了上面的Jsp+JavaBean的Java B/S开发模式后，我们发现其实现在最需要的就是在jsp、javabean之间能有个东西自动完成页面请求数据的封装、根据请求调用相应的javabean、同时根据javabean的处理结果返回至相应的View，有了这样的思想后，发现smalltalk中的MVC思想很适合这种场景，于是便在Java B/S开发中引入了MVC思想，在这里也简单的介绍下MVC思想，MVC强调View和Model的分离，View所面对的是Controller，由Controller负责与Model进行交互，View只负责显示页面以及显示逻辑的处理，显示逻辑指的是诸如第一行要显示蓝色、第二行要显示红色这样的显示方面的处理，Controller负责接受页面请求，并将其请求数据进行封装，同时根据请求调用相应的Model进行逻辑处理，在Model处理后返回结果数据到Controller，Controller将根据此数据调用相应的View，并将此数据传递给View，由View负责将数据进行融合并最终展现。MVC带来的优点很明显的体现出来了，基于一个这样的MVC Framework的话开发人员可以按照一种固定的模式进行开发，规范了整个开发过程，提高了质量以及系统结构的清晰性，并由于保证了View/Model的分离，使得一个Model可以对于多种显示形式的View，需要的仅仅是去改变View和Controller。
按照MVC思想，最容易想到的实现方案莫过于jsp+servlet+javabean，在这里面jsp对应着View，servlet对应着Controller，javabean对应着Model，因为采用servlet可使用servlet container已经封装好的页面数据请求对象HttpServletRequest，这样就省去了自己封装页面请求数据的工作，作为Controller同时还需要承担根据请求调用对应的javabean，最简单的做法无非就是在Servlet中直接根据某种逻辑(诸如反射或接口)调用相应的bean进行执行，之后将HttpServletRequest、HttpServletResponse作为参数传入javabean进行处理，javabean从HttpServletRequest中获取请求数据，将返回的结果数据放入HttpServletResponse，整个过程结束后继续由Controller接手进行处理，这个时候作为Controller的servlet将根据处理的结果返回相应的页面，在这个模型使用时人们慢慢的发现了一个问题，那就是随着jsp、javabean的变化造成了controller的不断修改，需要修改其中调用相应javabean以及转发相应页面的部分，为了解决这个问题，首先想到的是应该分离根据请求调用相应javabean的步骤，这个时候采用了设计模式中的front controller+application controller的方法，front controller负责接受页面请求并进行封装，同时将此数据对象传递至application controller，由application controller来负责调用相应的bean，这样的设计其实都是遵循着一个设计原则，就是职责单一，通常实现application controller的模式是Command模式，在这种情况下MVC Framework的结构体系就演变成了view+controller(front+application)+model。
在完成了上述演变后慢慢又发现了一个问题，就是model依赖于了httpservletrequest，这样造成的一个问题就是没法测试，仍然要不断重启服务器来测试，当然与此同时的发展是model层的细化，细化成用于响应页面请求的action Layer+Domain Model Layer+Persistent Layer，在这里不去讨论后面层次的问题，因为作为MVC Framework它并不管你Model层是怎么个处理流程的。
慢慢也发现了另外一个问题，那就是变化经常要影响到controller的修改，于是便引入了采用配置文件的解决方法，编写action的配置文件，在配置文件中控制根据action的返回结果转入相应的View，这样的话在将来需要改变的时候只需要去改变这个配置文件就可以了，保证了Controller的稳定，这是典型的设计中的重点考虑因素，分离变化和不变化的，让变化造成的影响最小。
但在引入了上面的配置文件后，慢慢又发现了问题，那就是手写配置文件总是容易出各种各样的问题，这个时候采用图形化的界面来生成配置文件的想法又有了，这也就造就了page flow的诞生，当然，这只是page flow的一小部分功能。
当然，随着MVC的发展，也带动了其他相关技术的发展，如异步请求/响应模式(ajax、amowa)等。
- 5楼网友：洒脱疯子
- 2021-01-13 03:12
我来胡扯几句吧
bs就是（Browser/Server，浏览器/服务器）模式啊
JSP+Servlet+JavaBean体现了分层的思想
jsp负责录入数据和回显数据，
servlet负责业务逻辑处理，
对数据库的操作有bean来完成！
使用jsp/servlet/java beans很好。
它们分别充当MVC模式中的视图，控制器和模型。
当然你可以用单独的jsp页面作为控制器，但它不能充分利用java的强大功能
。当使用servlet，由于它是纯java,你可以借用JAVA的全部能力以处理请求，而且便于调试。它的作用是将请求转发到不同的jsp页面，并与java beans 交互。jsp只负责显示信息，它只需从java beans中读取所需的数据。至于具体怎么应用需要慢慢的积累，一般的java程序员无须在jsp页面显示化太多工夫，而应在逻辑处理上做文章，界面交给网页设计师们吧。
对于JSP，程序员关注的是如何编写好的java beans和自定义的jsp tag。
而servlet则是重点，当然还有EJB.
学习时用tomcat就行啦 只要付和j2ee
标准的容器就行啊
bs就是（Browser/Server，浏览器/服务器）模式啊
JSP+Servlet+JavaBean体现了分层的思想
jsp负责录入数据和回显数据，
servlet负责业务逻辑处理，
对数据库的操作有bean来完成！
使用jsp/servlet/java beans很好。
它们分别充当MVC模式中的视图，控制器和模型。
当然你可以用单独的jsp页面作为控制器，但它不能充分利用java的强大功能
。当使用servlet，由于它是纯java,你可以借用JAVA的全部能力以处理请求，而且便于调试。它的作用是将请求转发到不同的jsp页面，并与java beans 交互。jsp只负责显示信息，它只需从java beans中读取所需的数据。至于具体怎么应用需要慢慢的积累，一般的java程序员无须在jsp页面显示化太多工夫，而应在逻辑处理上做文章，界面交给网页设计师们吧。
对于JSP，程序员关注的是如何编写好的java beans和自定义的jsp tag。
而servlet则是重点，当然还有EJB.
学习时用tomcat就行啦 只要付和j2ee
标准的容器就行啊
我要举报
如以上回答内容为低俗、色情、不良、暴力、侵权、涉及违法等信息，可以点下面链接进行举报！
点此我要举报以上问答信息！
大家都在看
推荐信息