這篇文章主要介紹“Java EE框架的介紹”,在日常操作中,相信很多人在Java EE框架的介紹問題上存在疑惑,小編查閱了各式資料,整理出簡單好用的操作方法,希望對大家解答”Java EE框架的介紹”的疑惑有所幫助!接下來,請跟著小編一起來學(xué)習(xí)吧!
10年積累的成都做網(wǎng)站、成都網(wǎng)站建設(shè)、成都外貿(mào)網(wǎng)站建設(shè)經(jīng)驗,可以快速應(yīng)對客戶對網(wǎng)站的新想法和需求。提供各種問題對應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識你,你也不認(rèn)識我。但先做網(wǎng)站后付款的網(wǎng)站建設(shè)流程,更有邵東免費網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。
確保高效發(fā)展進(jìn)程的建議
很久以前,J2EE,特別是應(yīng)用程序服務(wù)器被認(rèn)為過于臃腫和“重量級”。對于開發(fā)人員來說,使用此技術(shù)開發(fā)應(yīng)用程序會非常繁瑣且令人沮喪。但是,由于 J2EE 框架的名稱已更改為Java EE,因此該假設(shè)不再適用。 Java EE 與其他企業(yè)框架相比區(qū)別在哪以及框架輕量級的標(biāo)準(zhǔn)是什么?
在選擇技術(shù)時,需要考慮的最重要方面之一是開發(fā)人員在開發(fā)過程中的生產(chǎn)力。工程師應(yīng)該花費盡可能多的時間來實現(xiàn)用例和創(chuàng)收功能,因為這將使公司朝著目標(biāo)前進(jìn)。
所選擇的技術(shù)和方法應(yīng)該最大限度地縮短開發(fā)人員的時間。具體哪些時間呢:等待構(gòu)建,測試和部署; 配置應(yīng)用; 實施與業(yè)務(wù)用例無關(guān)的管道; 并配置構(gòu)建環(huán)境和外部依賴項。 但是大多數(shù)可用技術(shù)都沒有這樣做。
與其他框架相比,Java EE 的最大優(yōu)勢之一是使用的API的標(biāo)準(zhǔn)化。標(biāo)準(zhǔn)聽起來可能很無聊而且不夠創(chuàng)新 - 從本質(zhì)上講,這是真的,因為Java規(guī)范請求(JSR)已經(jīng)成為行業(yè)內(nèi)過去已經(jīng)過充分證明的結(jié)果。 但使用這些標(biāo)準(zhǔn)有幾個優(yōu)點。
Java EE中的特定API - 例如上下文和依賴注入(CDI),JAX-RS,JSON 處理(JSR 353)和 Bean驗證 - 可以很好地協(xié)同工作,并且可以無縫地相互組合。 最重要的是,CDI 被用作應(yīng)用程序組件之間的“粘合劑”。 該規(guī)范包含諸如*“如果容器支持規(guī)范 A 和 B,那么 A 必須與 B 無縫集成并良好地工作?!?
例如,JAX-RS 支持 JSONP 類型,例如JsonObject
用作請求或響應(yīng)實體,它支持調(diào)用Bean 校驗功能 - 如果驗證失敗,則包括正確的HTTP狀態(tài)代碼(參見清單1)。
@Path("duke") public class DukeResource { @GET public JsonObject getDuke() { return Json.createObjectBuilder().add("name", "Duke").build(); } @POST public void create(@Valid @NotPlayedYet Game game) { // game object has been validated at this point } }
清單1. JAX-RS的JSONP和Bean Validation集成
使用 JSONP 類型意味著內(nèi)容類型將是 application / json
,并且如果驗證失敗,將發(fā)送HTTP狀態(tài)代碼 400 Bad Request
。 這無需編寫任何配置代碼就能使一切都完成。
另一個例子是 CDI 使開發(fā)人員能夠通過 @Inject
將任何 bean 和用戶定義的對象注入 Java EE托管組件。 請參閱清單2,了解一個 bean 驗證 Validator
,它直接使用另一個 CDI 托管bean。
public class GameNotPlayedValidator implements ConstraintValidator<notplayedyet, game> { @Inject GameHistory history; public void initialize(NotPlayedYet constraint) { // no initialization needed } public boolean isValid(Game game, ConstraintValidatorContext context) { return !history.exists(game); } }
清單2. bean 驗證的 CDI 集成
集成是規(guī)范的一個主要方面,可以提供直接的開發(fā)人員體驗。開發(fā)人員可以依賴應(yīng)用程序服務(wù)器進(jìn)行集成和配置工作,從而可以專注于應(yīng)用程序的業(yè)務(wù)邏輯。
由于 Java EE 的配置約定驅(qū)動方法,大多數(shù)實際應(yīng)用程序不需要大量配置。 繁瑣的 XML 描述符的日子結(jié)束了。 對于簡單的 Java EE 應(yīng)用程序,您不需要單個 XML 文件。
由于聲明性注釋,一個簡單的帶注釋的普通舊 Java 對象(POJO)處理 HTTP 請求(@Path
),或分別作為 Enterprise JavaBeans(EJB)bean(@ Stateless
) - 包括事務(wù),監(jiān)視或攔截器。過去,這些方法已在各種框架中得到很好的證明,并已在 Java EE 中進(jìn)行了標(biāo)準(zhǔn)化。
如果需要,XML 描述符仍可用于部署時配置,但是配置約定有助于最大限度地提高開發(fā)人員的工作效率。
少數(shù)實際企業(yè)項目在部署工件中沒有任何額外依賴項的情況下工作。 但這些依賴關(guān)系的理由主要是由技術(shù)驅(qū)動 - 例如包括日志記錄或?qū)嶓w映射框架或 Apache Commons 或 Google Guava 等常用庫 - 而不是用例。
Java EE 7 - 尤其是與 Java 8 一起使用時 - 具有足夠的功能來覆蓋大多數(shù)用例而沒有任何其他依賴性。開箱即用的內(nèi)容大部分都可以用最少量的代碼來實現(xiàn),例如,通過 CDI 提供商的可注入配置,通過攔截器的斷路器(查看 Adam Bien 的開源庫),或通過復(fù)雜的收集操作 Java 8 lambda 表達(dá)式和流。
當(dāng)然,你可以爭辯說不要在這里重新發(fā)明輪子。 但實際上,為了節(jié)省一些自編寫的代碼行,將兆字節(jié)的外部依賴項包含在部署工件中并沒有多大意義。
經(jīng)驗表明,最大的問題不是直接引入的依賴,而是傳遞的依賴。傳遞的依賴經(jīng)常與應(yīng)用程序服務(wù)器上已有的庫版本沖突,并導(dǎo)致具有挑戰(zhàn)性的沖突。在一天的工作時間內(nèi),開發(fā)人員要花費更多時間來管理這些沖突,而不是聚焦在將小功能實現(xiàn)到項目中所需的時間。這主要適用于具有技術(shù)驅(qū)動而非用例驅(qū)動的依賴關(guān)系的情況。
有關(guān)簡單的 Java EE 7 項目Maven項目對象模型(POM)的文件啟發(fā),請參閱清單 3,該文檔受Adam Bien的啟發(fā) Java EE 7 Essentials Archetype.
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemalocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelversion>4.0.0</modelversion> <groupid>com.sebastian-daschner</groupid> <artifactid>game-of-duke</artifactid> <version>1.0-SNAPSHOT</version> <packaging>war</packaging> <dependencies> <dependency> <groupid>javax</groupid> <artifactid>javaee-api</artifactid> <version>7.0</version> <scope>provided</scope> </dependency> </dependencies> <build> <finalname>game-of-duke</finalname> </build> <properties> <maven.compiler.source>1.8</maven.compiler.source> <maven.compiler.target>1.8</maven.compiler.target> <failonmissingwebxml>false</failonmissingwebxml> <project.build.sourceencoding>UTF-8</project.build.sourceencoding> </properties> </project>
清單3. Java EE 7 Maven POM 文件
當(dāng)然,有時應(yīng)用程序確實需要集成對于實現(xiàn)軟件目標(biāo)至關(guān)重要的庫。但是,這些依賴關(guān)系需要通過業(yè)務(wù)需求來證明。一般來說,它很有意義,可以節(jié)省時間和精力來最小化外部生產(chǎn)庫。
對于測試依賴關(guān)系,這是一個不同的故事,因為庫,例如JUnit,Mockito或者在某些情況下,Arquillian - 是至關(guān)重要的。 但同樣,關(guān)注測試依賴項列表也是有意義的。
由于應(yīng)用程序服務(wù)器知道Java EE API,因此該API不必包含在部署 artifact 中。 只包含業(yè)務(wù)邏輯 - 只需最少的膠水代碼和交叉關(guān)注點。
因此,這些千字節(jié)大小的工件可以使構(gòu)建時間非常短,因為構(gòu)建過程不需要復(fù)制很多東西。這可以在每個構(gòu)建上產(chǎn)生幾秒鐘的差異。 如果總結(jié)開發(fā)人員和持續(xù)集成(CI)服務(wù)器所花費的所有額外時間,那就會產(chǎn)生很大的不同。項目建設(shè)的頻率越高 - 對于持續(xù)交付(CD)情景尤其如此 - 影響越大。
除了較短的構(gòu)建時間外,小型部署 artifacts 還可確保較短的發(fā)布和部署時間。 由于實現(xiàn)已經(jīng)包含在運行時中,所以在所有情況下,移動部件花費的時間都是最小的。
這正是Java EE成為Docker等容器技術(shù)的完美框架的原因。Docker 鏡像基于圖層,構(gòu)建圖像時,基本圖像已包含操作系統(tǒng),Java運行時和應(yīng)用程序。因此,在每個構(gòu)建中添加的唯一內(nèi)容是部署工件的最后一個千字節(jié)薄層。與胖WAR或獨立JAR方法相比,這節(jié)省了時間和存儲 - 不僅在每個構(gòu)建上,而且在圖像版本化或發(fā)布版本時 。
無論在哪個階段,擁有精簡的部署 artifacts 都可以實現(xiàn)非??焖俸透咝У牟渴鸸艿馈?/p>
J2EE 應(yīng)用程序服務(wù)器是重量級軟件在啟動和部署時間,安裝大小和資源占用空間方面的體現(xiàn)。 但是在 Java EE 的新世界中,這已不再適用。
所有現(xiàn)代Java EE 7應(yīng)用程序服務(wù)器(如WildFly,Payara,WebSphere Liberty,Profile和TomEE)都可在幾秒鐘內(nèi)啟動和部署。由于內(nèi)部,全面的模塊化,他們只能加載所需的組件并盡快部署精簡的應(yīng)用程序 artifacts。
現(xiàn)在的安裝尺寸和占地面積非常合理。 應(yīng)用程序服務(wù)器不會消耗比簡單的 servlet 容器更多的東西,但它具有完整的 Java EE 功能。 有趣的是,現(xiàn)在運行的瀏覽器實例消耗更多內(nèi)存。
話雖如此,每個服務(wù)器只部署一個應(yīng)用程序是可能的,也可以是合理的 - 無論是在容器中還是在內(nèi)部。 通過“每個容器每個應(yīng)用程序服務(wù)器一個應(yīng)用程序”方法,您可以為現(xiàn)代微服務(wù)架構(gòu)提供高效且靈活的解決方案。
在打包過程中,不應(yīng)該繼續(xù)使用EAR文件了。將整個應(yīng)用程序部署在獨立的專門的服務(wù)器上,要求我們在那個環(huán)境中必須可以訪問所有的組件方法,這樣做可以節(jié)省更多的構(gòu)建和部署時間。除此之外,這還避免了EAR文件傾向于導(dǎo)致的類加載層次結(jié)構(gòu)問題。
在大多數(shù)云和微服務(wù)部署中,使用獨立的JAR包。 它們包含應(yīng)用程序和運行時實現(xiàn)。 在Java EE領(lǐng)域,這種方法可以使用特定于供應(yīng)商的工具鏈來實現(xiàn),例如 WildFly Swarm,Payara Micro 或TomEE Embedded。
但是,由于上述原因,我強烈建議盡可能將業(yè)務(wù)邏輯與運行時分開。 這意味著將應(yīng)用程序打包在僅包含應(yīng)用程序代碼的WAR文件中。
在我看來,如果由于公司“政治”問題而不是技術(shù)原因而無法控制安裝或操作流程,則獨立 JAR 文件是一種有用的解決方法。 然后運送部署工件中所需的所有內(nèi)容并且只需要 JRE 時可以解決相當(dāng)多的非技術(shù)問題。
企業(yè)項目最有效的解決方案之一如下:
僅在提供 API 時使用 Java EE 7 和 Java 8
構(gòu)建一個千字節(jié)大小的 WAR 文件,其中僅包含業(yè)務(wù)邏輯和最小管道(例如 JAX-RS 資源或JPA)
構(gòu)建 Docker 鏡像 - 僅將 WAR 文件添加到包含已配置的應(yīng)用程序服務(wù)器的基礎(chǔ)鏡像
通過使用容器部署應(yīng)用程序的 CD 管道進(jìn)行傳送
“重量級 Java EE”的日子肯定結(jié)束了。 Java EE 中包含的 API 提供了高效且愉快的開發(fā)人員體驗以及標(biāo)準(zhǔn)內(nèi)的無縫集成。 特別是,將應(yīng)用程序代碼與運行時分離的方法可實現(xiàn)快速,高效的開發(fā)過程。
通過由多個供應(yīng)商發(fā)起的新MicroProfile計劃,將來可能會進(jìn)一步縮小Java EE所需的組件。
到此,關(guān)于“Java EE框架的介紹”的學(xué)習(xí)就結(jié)束了,希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學(xué)習(xí),快去試試吧!若想繼續(xù)學(xué)習(xí)更多相關(guān)知識,請繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站,小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>
新聞名稱:JavaEE框架的介紹
當(dāng)前路徑:http://www.rwnh.cn/article8/pcosop.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站改版、動態(tài)網(wǎng)站、網(wǎng)站排名、網(wǎng)站內(nèi)鏈、靜態(tài)網(wǎng)站、虛擬主機(jī)
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)