① 一個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開發者能很自然運用面向編程，而不需要附加編碼。