① 一个JAVAWEB项目(B/S结构)的各个组成部分的作用分别是什么
b 指浏览器，s 指服务器。 服务器提供服务，客服端通过浏览器来访问接收服务
② java web项目 目录结构问题
貌似.project里面存着这个项目的具体信息，是否是web
项目，需要在文件里面查找然后加载一些数据。
大概是这样子的，具体没深入过。
③ 采用SSM框架的javaweb工程目录结构是怎么样
借鉴github某项目的目录
├── SSM-API // common API
│ ├── src/main
│ ├── ├──java/com/crossoverJie // specific code。
│ ├── ├──resources
├── SSM-BOOT // Available for internal use of bbo dependencies
│ ├── ├──resources/spring // bbo consumer configuration
├── SSM-SERVICE // The service implementation of the bbo application
│ ├── src/main
│ ├── ├──java/com/crossoverJie/api // specific code
│ ├── ├──├──controller // Heartbeat detection interface
│ ├── ├──├──bbo // Dubbo related code
│ ├── ├──├──├── // package
│ ├── ├──├──├──pojo // pojo package
│ ├── ├──├──├──service // service package
│ ├── ├──├──├──util // Toolkit
│ ├── ├──├──impl // implement bbo API
│ ├── ├──resources // configuration file
│ ├── ├──├──mapping // *.mapper configuration file
│ ├── ├──├──spring // Spring related configuration file
├── SSM-WEB // web application
│ ├── src/main
│ ├── ├──java/com/crossoverJie // specific code
│ ├── ├──├──controller // controller package
│ ├── ├──├──cxf // CXF related code
│ ├── ├──├── // package
│ ├── ├──├──enums // enum package
│ ├── ├──├──intercept // Interceptor
│ ├── ├──├──lucene // Lucene related code
│ ├── ├──├──pojo // pojo package
│ ├── ├──├──req // request package
│ ├── ├──├──res // response package
│ ├── ├──├──service // service pachage
│ ├── ├──├──shiro // shiro related code
│ ├── ├──├──util // Toolkit
│ ├── ├──├──vo // vo package
│ ├── ├──resources
│ ├── ├──├──mapping // *.mapper configuration file
│ ├── ├──webapp // front code
├── doc
│ ├──lucene // lucene related code
│ ├──sql // sql scripts
├── .gitignore // gitignore
├── pom.xml // parent pom
├── LICENSE
├── README.md
④ JavaWeb项目，其中，哪些技术是最基础、最重要的
最基础最重要的就是Java语言、面向对象分析设计思想、设计模式和框架结构。Java语言体系比较庞大，包括多个模块。从WEB项目应用角度讲有JSP、Servlet、JDBC、JavaBean（Application）四部分技术；Java语言是完全面向对象的语言，在分析项目业务关系的时候应用一些UML图能尽快找出业务逻辑主要面对的对象，然后对每个对象进行行为划分，最后再实现对象之间的集成和通信；设计模式主要在与两层的设计模式、三层的设计模式和N层的设计模式，很多的Web项目采用的是MVC的三层开发结构，也就是JSP+Servlet+JavaBean。
⑤ eclipse WEB项目开发时，项目文件组织结构是怎样的
按照 Java EE 规范的规定，一个典型的 Web 应用程序有四个部分：
1. 公开目录 ;
2. WEB-INF/web.xml 文件，发布描述符（必选） ;
3. WEB-INF/classes 目录，编译后的 Java类文件（可选） ;
4. WEB-INF/lib 目录，Java类库文件（*.jar） （可选） ;
公开目录存放所有可以被用户的访问的资源, 包括 .html, .jsp, .gif, .jpg, .css, .js, .swf 等等。
WEB-INF 目录是一个专用区域, 容器不能把此目录中的内容提供给用户。
这个目录下的文件只供容器使用，里面包含不应该由客户直接下载的资源，
例如： Servlet(这些组件包括应用程序逻辑以及对其他资源如数据库的可能访问), Web应用程序中servlet可直接访问的其他任何文件，在服务器方运行或者使用的资源(如 Java类文件和供 servlet 使用的 JAR文件)，由您的应用程序生成的临时文件,，发布描述符以及其它任何配置文件。
这些资源是专用的， 因此只能由它们自己的 Web应用程序及容器访问。
特别地，JSP/Servlet 程序文件也能通过 ServletContext 访问到这个目录下的文件，
例如 JSP 中可以通过application.getRealPath(“/WEB-INF/web.xml”) 访问到发布描述符文件的路径。
Web容器要求在你的应用程序中必须有 WEB-INF 目录。
注意： 如果你的 Web 应用程序中没有包含这个目录, 它可能将无法工作
WEB-INF 中包含着发布描述符, 一个 classes 目录和一个 lib目录, 以及其它内容。
发布描述符(deployment descriptors)是 J2EE Web 应用程序不可分割的一部分(也就是说是它的最小部分, 必不可缺的一部分)。
它们在应用程序发布之后帮助管理 Web 应用程序的配置。
对于Web 容器而言, 发布描述符是一个名为 web.xml 的 XML 文件, 存储在 Web 应用程序的 /WEB-INF目录下。
发布描述符有多种用途：
• 为 Servlet 和 Web 应用程序提供初始化参数 这使我们的Web应用程序中的硬性编写的代码的初始化值更少。 例如常见的 <param-name>, <param-value>标记, 就可以为Servlet 提供参数, 这个参数可以在 init() 方法中加载。
Struts 的 ActionServlet 也是通过这种方式来找到它们需要的配置文件 struts-config.xml 的位置, 从而加载并分析它,来初始化 Struts 框架用到的各种 FromBean, Action, Forward等。
• Servlet/JSP 定义 可以为 Web 应用程序中的每个 Servlet 或者预编译的 JSP 网页提供定义。
包括Servlet/JSP的名字, Servlet/JSP 的类以及一个可选的描述。
• Servlet/JSP 映射 Web容器使用这些信息把进入请求映射到 servlet 和 JSP 网页。
• MIME类型 由于每个 Web 应用程序可以包含多种内容类型, 因此我们可以在发布描述符中为每一种类型指定 MIME 类型。
• 安全性 我们可以使用发布描述符来管理应用程序的访问控制。 例如, 可以指定我们的Web应用程序是否需要登录, 如果需要的话, 应该使用什么登录页面, 以及用户会作为何种角色。
发布描述符还可以用来自定义其他元素, 包括欢迎网页, 出错网页, 会话配置等等。
classes 目录用于存储编译过的 servlet 及其它程序类, 例如 JavaBean。
如果一个程序有打包的 JAR 文件(例如一个第三方 API 打包成了一个 JAR 文件, 如 Struts 框架的类库struts.jar, MySQL 的数据库 JDBC 驱动程序文件 mysql-connector-java-3.1.11-bin.jar 等),
那么它们可以被复制到lib目录中(如果解压缩这些压缩包的话, 请将它们复制到classes目录中)。
Web 容器使用这两个目录来查找 servlet 及其他相关类, 也就是说, 容器的类装入器会自动查看 classes 目录, 以及 lib目录下的 JAR文件。
这就意味着你不需要明确的把这些类和 JAR文件添加到 CLASSPATH中。
Web容器自动将这两个目录中的文件加入 Web应用的类路径中。
⑥ java搭建web平台都有什么框架
web平台也可以理解为B/S(Brouser/Server)技术平台，是一种基于浏览器载体的框架，包含前端、后端和数据库三个大的方向，各个方向的技术都不一样，如果都懂的就是全栈了。现在主流的技术包含JAVA、.NET、SqlServer、Bootstrap等，学会了这些也就知道怎么去开发B/S项目了。
Web前端开发技术包括三个要素：HTML、CSS和JavaScript，还有很多高级的前端框架，比如bootstrap、Jquery等，前端开发也是比较的复杂，如果找到规律，开发起来也比较的快。
Web后端技术也有很多，比如.Net、JAVA、PHP等，各大语言都有其开发架构，像.NET的MVC架构，JAVA的Java EE，一般web后端技术的知识面是很广的，语言、设计模式、需求分析、性能优化等都要懂。
数据库现在有三种主流的关系型数据库：MysqlSQLserverOracle，还有Nosql等结构性数据库：Redis、Mogodb等。
如果对C#开发BS架构的项目心里还没有底的话，可以了解下web开发平台中的一些架构思想，对前端、后端和数据库等一些主流框架进行了集成，对我们应该是有好的帮助的。
⑦ 列出javaweb 项目的目录结构和关键配置文件
什么意思？这个是SSH的
⑧ 关于javaweb项目包的结构..
一般用当下主流的框架结构来创建包，比如springMVC框架，你要创建model层，层，service层和controller层，其它要在项目中用到的像工具类可以创建一个工具包
⑨ 为什么JavaWeb项目要分层
首先让我们坐着时光机回到n年前的web开发。
那个时候最早都是静态的html页面，后来有了数据库，有了所谓的动态页面，
然后程序猿在编码的时候，会把所有的代码都写在页面上，包括数据库连接，包括事务控制，接收参数，各种校验，各种逻辑，各种html/js/css代码等等
怎么样？够乱吧？像一坨那什么一样，这个页面可能有成千上万行？
那么好，问题来了，回头需要修改的时候，你怎么办？
你找个东西找半天，好不容易找到了，还不敢改，怕被其他地方用了，改出连带问题。
页面一出错，定位不准到底是哪里的问题，从头到尾的挨个排查。
等等等等。
这就是大家常说的什么叫可维护性，这也是为什么越来越多的公司的规范要求不能写复杂sql。
还记得之前在东软的时候，一哥们写了一个80多行的大sql来完成一个核心的查询。
试问这个大sql天天在数据库里run，还有性能可言？
再试问谁敢改？
后来项目要改需求还是出现bug了，那个sql要改动，写sql的哥们改了好久才改好，因为时间长他也忘了，
再后来他离职了。。。
有人问，那简单sql实现不了我的功能呀，怎么办？
从数据库设计层面开始下手，要允许适当的冗余，把表弄好，就迎刃而解了，这也是数据库层面的一种解耦吧。
后来。。。
进入第二阶段，大家痛定思痛，决定要把页面和逻辑拆开，页面只是负责显示，逻辑都在后台。
这就出现了短暂的，在jsp里使用标签调用bean的用法。bean里耦合了除了页面之外的所有东西。
再后来。。。
进入了第三阶段，大家又痛定思痛，决定要拆成三部分，就是大名鼎鼎的MVC。
再再后来。。。
衍生出来了类似于struts/springmvc等等的mvc框架
---------------
JavaWeb项目的层有2个维度。
第一个维度是MVC的三层：
M：model，模型层，包括了你的业务逻辑和数据库操作，封装好给视图层使用的。
V：view，视图层，仅仅做的是展示数据，不包含业务逻辑，主要是jsp/html等等
C：controller，控制层，负责接收请求，调用模型层处理业务逻辑并返回给视图层。
第二个维度是java代码里的三层：
controller：控制层，负责接收参数/解析参数/封装参数，调用serivce，将service方法的返回值进行封装（如果需要），返回数据/返回页面，路由。
service：负责业务逻辑，事务控制在这层里做，被controller调用，以及调用。
：持久层，负责数据库交互，被service调用。
这2个维度别弄混了哟。我今天主要说的是第二个维度的层哟。
我认为，第二个维度是第一个维度的延伸，其实第二个维度再加上一个表现层就完美了，这就为什么有人说是4层架构。
---------------
前戏结束，步入正题：
有些学生朋友可能会问为什么要分层呢？我本来可以在一个地方写完的东西，非要散落在各个层中，都在一起不是挺好的吗？
开发效率高呀~
跳来跳去的我脑子都晕啦。。。
这就是为什么有人会把所有的东西都扔在一个层里，比如controller层。。。
其实我们可以在jsp上把所有的逻辑以及数据库操作,数据展示全部写在一起，耦合在一起，这样开发起来貌似更快，
但是维护性非常差，有朝一日想改一个小地方，牵一发而动全一身，隐患很高，无法快速定位问题。
因此我们需要分层。
分层了之后，你理论上改了持久层的东西，逻辑层是不用变动的。
每个Dao类是跟每个表走，Dao的每个方法里就一个个的简单sql，不包含任何业务逻辑，可以被不同的service复用和调用。
经过抽象后基本上都是通用的，因而我们在定义DAO层的时候可以将相关的方法定义完毕，
这样的好处是在对Service进行扩展的时候不需要再对DAO层进行修改，提高了程序的可扩展性。
提高了程序的可扩展性。具体什么时候做这些操作，怎么做这些操作都由Service来处理。
（就像郭德纲的相声里的一句话：“行了，你甭管了”）
而Service则不是，一个Service里可以会调用多个不同的，完成特定的业务逻辑，事务控制，
封装Service层的业务逻辑有利于通用的业务逻辑的独立性和重复利用性
同时，一个Service的方法也有可能被多个Controller的方法来调用。
逻辑出问题就在Service找问题，数据库，sql有问题就在Dao层找问题，
参数解析错误，跳转错误，就在Controller上找问题。
这样快速定位问题，互不干扰。
---------------
分层架构（这里会延伸到更广阔的架构）：
回头项目玩大了，怎么办？拆！！！
具体可以搜一下：maven分模块开发，怎么玩代码依赖，怎么玩微服务，怎么玩SOA，怎么玩RPC，怎么玩bbo。
web项目发展有几个阶段啊
第一个阶段（单一应用架构）：
所有代码都耦合在一个项目里，放在一台服务器上，这种all in one的方式是有好处的。
创业初期，不用什么架构，走敏捷开发，最快速的实现需求才是王道。
你甭管我有多烂，我至少能跑起来，我至少能在外网上让你访问，让你使用。
当然了，初期的访问量很少，节省部署和运维成本才是王道呀。
听阿里的讲座，说淘宝的前期的版本用的就是一台PC机作为服务器，所有的功能耦合在一个项目里，
每次往生产环境上发版本，要上传一个600mb的包，呵呵。
第二个阶段（垂直应用架构）：
哎哟，不错哦。自己的儿子被越来越多的人访问，访问量激增，一台服务器扛不住了，
没事，我们可以玩负载均衡，玩集群。
但是！这种性能加速度其实会变得越来越小，因为你的项目是耦合在一起的。
这时，我们需要拆分项目，这里又有2个维度，按层拆，按模块拆。
将拆好的不同项目分别部署在不同的服务器上，并且再分不同的小集群。
第三个阶段（分布式服务架构）：
唉呀妈呀，访问量陡增，到这步你创业应该算成功了，开始烧投资人的钱了吧。
经过上面拆成了越来越多的模块，模块与模块交互越来越多，怎么办？
这个时候我们需要把核心的业务抽出来，作为独立的服务，慢慢发展成稳定的服务中心，
用来提升业务复用和整合。
就像阿里的大牛说过，没有淘宝的积累，天猫能那么快的出来吗？
这个时候，你的缓存，数据库，消息队列等服务都应该是分布式的。
第四个阶段（流动计算架构）
哎呀妈呀，访问量又上了一个台阶，翻了好几百倍吖，肿么办？
这个时候服务越来越多，一些容量和资源的浪费问题凸显出来，
这时我们需要一个调度中心来基于访问压力动态的管理集群容量，
提高利用率。
第五个阶段（云计算架构）
抱歉，作者正在学习中，未完待续。
⑩ javaweb项目结构相关，怎么能更好的分层
域模块层由实际需求中业务对象组成，比如订单明细、产品、等。
开发者在这层不用管哪些数据传输对象，而关注域对象即可。
例如，Hibernate允许你将数据库中的信息存入域对象，这样你可以在连接断开的情况下把这些数据显示到用户界面层，而那些对象也可以返回给持久层，从而在数据库里更新。
而且，你不必把对象转化成DTO（这可能导致它在不同层之间传输过程中丢失）。
这个模型使得Java开发者能很自然运用面向编程，而不需要附加编码。