⑴ 什麼叫web表示層
web表現層
（1）Servlet的誕生，宣告java在web 領域佔有一席之地，並逐步取代CGI的地位。
（2）在Servlet里寫html標簽是一件痛苦的事。畢竟HTML中，靜態的文本標簽佔大部分，動態顯示部分只是小部分。於是JSP誕生了。成為了ASP的一個有力競爭對手。
（3）隨著"Java Code Pollution"問題浮出水面（HTML和Java代碼混雜，不僅頁面結構差，而且其中的Java代碼也很難維護），TagLib應運而生。自定義的XML元素開始替換Java代碼，這樣，整個頁面就XML化了。
（4）TagLib不能在一般的HTML瀏覽器或編輯器裡面顯示，頁面不能所見即所得。而ASP.net挾Visual Studio快速可視開發之優勢，正在Web開發領域攻城掠地。Java世界倉促應戰，啟動JSF項目。成員眾多的Web Framework陣營中又多出一位權威的重量級選手。
......
各種新概念層出不窮，頁面流程越來越復雜。大家的口號都是"為了降低開發難度，讓程序員只關注於業務邏輯，而不用關心底層的技術細節"，都是"為了企業級應用，而企業級應用的需求是復雜的，所以，把簡單問題復雜化是有道理的——據說，這是為了系統的面向未來的可擴展性、可伸縮性......"
⑵ eric4怎麼樣開發web程序
開發Web方面的程序已經有一段時間了,下面總結一下我對Web開發的看法.可能有些認識的還不夠深刻和正確,見笑 :)
Web程序的開發我認為大約分4個層次:
1.表現層 (represent layer)
2.控制層 (logic control layer)
3.業務邏輯層 (service layer)
4.數據存儲層 (persistent layer)
一個標準的系統大致就是做3件事,I(Input)P(Process)O(Output),也就是輸入,處理,輸出.在Web開發方面也是一樣.
由於開發,部署,移植,性能和代碼可重用性的考慮,Web開發將IPO分為了若干層次.我對我上面所說的4個層次作簡單的解釋:
1.表現層:
此層的主要作用是:向用戶展示信息,並且得到用戶輸入數據和向用戶展示處理後的反饋.
2.控制層:
此層的主要作用是:為了讓開發人員和維護人員方便控制Web頁面的流向,一目瞭然的對其走向進行控制.同時此層也可以進行一些簡單的預處理,使業務邏輯避開本不該它們觸碰的外部檢測.此層的大部分任務是程序走向的控制,小部分任務是一般預處理和檢測功能.
3.業務邏輯層:
此層的主要作用是:進行用戶所要關心的業務邏輯,進行整個程序的核心業務處理,此層一般會使用從表現層傳入的數據並調用數據存儲層的介面來進行相應的查詢和更新刪除保存功能.並將最終處理結果反饋給控制層,由控制層根據處理結果去尋找表現給用戶的路徑.
4.數據存儲層:
此層的主要作用是:進行數據的查詢和持久化過程.
由於每一層對應的開發在現實世界中都有很多相應的技術和框架進行支撐,所以我會簡單的介紹一下發展的歷史和相關框架.
1.表現層顧名思義就是表現給用戶看的東西,同時也應能夠得到用戶的輸入數據.在Web上面就是用html表現給用戶和得到用戶提交的表單數據.
1.可是要表現出來的數據很多都是動態的,是從業務邏輯中得到的,業務邏輯中的數據或許是從資料庫或者socket埠等地得來的,要怎麼把這些動態的數據方便的表現給客戶呢?
1.為了實現這個目標就會出現相應的技術來支撐,以前是CGI,但在java方面最開始出現的是servlet,可是人們發現用servlet開發,想在把數據顯示在頁面上的時候要整屏幕的寫滿:out.print(<input type="text" ... >)之類的話語,邏輯和表現常常混雜在一起,不易維護也不易開發和美工.
1.後來sun就把servlet包裝了一把,取名叫JSP.JSP就是servlet的一種變形,是運行在伺服器上的,大家可千萬不要像以前的我一樣以為JSP和html一樣運行在客戶端.JSP把Java程序開發和request對象,session等對象的存取和網頁開發融合在一起.但是開發中常常會出現大量的java代碼混雜在JSP中,造成了閱讀和維護的困難,而且對分層和清晰還有復用都沒有一點好處.
1.在後來就有了taglib標簽,為的是減少不斷出現在頁面上的代碼,對於不可避免的一些是非判斷,循環表示,信息表達,進行了封裝,把代碼移到一個個java類中去了.在使用時只用調用其標簽和傳入參數就好了,開發人員也可以自己繼承tag的相關介面進行所需要的開發.
1.在再後來,出現了很多各有優點的JSP競爭者,比如很多模版庫(如Velocity,FreeMaker)等.標簽庫也變得越來越豐富了,官方也提供了很多標准標簽庫供人們簡化方便使用.但是不要忘記無論是JSP還是Velocity或者FreeMaker都是要被一個模版引擎解釋編譯成相應的html代碼的,所以在web.xml中都要配置其相應解釋引擎的類.
1.現在Ajax的非整個頁面的刷新前端的技術也流行起來了,其框架層出不窮,在需要其提供的特性時可以考慮使用.
2.控制層很久以前一般都是使用servlet來進行業務邏輯的處理,再用request.getRequestDispatcher("targetURL").forward/include(request,response)或者response.sendRedirect("targetURL")進行頁面流程的轉發.前者request方法和後者response的區別就是request和response的信息是否丟失和URL標題是否改變的區別.request的forward()方法會將request和response的信息完好無損的傳遞給下一個servlet但是瀏覽器看到的URL卻不會改變,而response的sendRedirect()方法則丟失了request和response,但是URL路徑會改變.
2.後來在開源世界中出現了一個流行的MVC框架叫做struts,它的1.0版從2001發布,到現在已經快5年了.它是那個年代MVC的典範,用一個ActionServlet作為中心控制器,頁面的流向從struts-config.xml中配置.用繼承ActionForm的Form通過框架的反射功能自動映射了網頁上的同名元素,省去了request.getParameter("name")的步驟.並在Action中進行一些處理和流向控制(千萬不要把這里當做處理業務邏輯的地方,這里應該調用業務邏輯層的介面,將頁面上傳入的數據封裝成VO傳入介面的方法中,這里的action最好只起到一個流程式控制制的作用).
2.很久以前struts由於一些被別人看不好的特點,也出現了很多相應的競爭者,如webwork(此框架現在已被struts納入懷中,准備取長補短融合為struts2.0),springMVC,Tapestry都各有各的優點.
3.業務邏輯層的業務邏輯原先都是在代碼中用new來創建實體類,用其進行處理和檢測,但是變化多端業務邏輯常常讓開發人員更改和實現不同的相關代碼,雖然已經使用了介面來編程,但是當實現類變為另外一個實現類的時候還是要在代碼中改變其new的對象,然後還要重新編譯和部署.
3.後來的人們通過java的反射技術和CGLIB實現了一種叫做IOC/DI的技術,其實就是: 把new 某個介面的具體實現類 'SomeInterface si = (SomeInterface) new SomeInterfaceImpl();' 這個動作用一個工廠方法來代替'SomeInterface si = (SomeInterface) applicationContext.getBean("yourConfigedClassId"),然後把new這個Object的名字從代碼中移到配置文件中去,把類名寫進配置文件,標上個id,比如是例子中的yourConfigedClassId,然後在代碼的getBean()中,傳入所需要的id名稱,通過反射來進行注入和賦值.當有業務邏輯有更改的時候,只須改變配置文件中配置的具體實現類名,不用改變原有的程序,也不用重新編譯業務邏輯代碼,只要簡單更改配置文件就行了.
3.IOC/DI(控制反轉和依賴注入)就是把實例化哪個類的控制權由程序轉移到配置文件中,代碼中只寫介面和傳入配置名字的id的工廠方法,程序運行的時候,根據配置信息,把所配的類通過反射注入到程序中.
3.業務邏輯還有很多要注意的事項,比如說寫日誌阿,事務阿,什麼的.有人利用java的動態代理和CGLIB實現了面向切面的編程技術AOP支持.AOP根據切面把所有的進入點統一進行處理,將分散的代碼集中在一起進行管理.
3.後來由於各種各樣輕量級現實的需要和EJB的重量,有個牛人就寫了一套IOC/AOP為核心的Spring框架的輕量級解決方案,很方便的給予了相應的技術支撐,讓開發人員樂在其中.
3.不知道我把此層的意思表達清了沒,有些話看起來好像挺繞嘴?
//天色已晚,明日還要上班,有空再繼續寫 :) 2006-11-30 01:26.
//2006-11-30 23:01
4.數據存儲層方面一般牽扯到兩個概念,一個是DAO,一個是ORM.
4.DAO就是Data Access Object,這個模式旨在解決一個簡單的問題:數據訪問代碼應該放在哪裡?這種模式最典型的結構就是:a.一個數據介面工廠類;b.一個數據訪問介面(如介面中定義的create(),find(),delete(),update()方法);c.實現數據訪問介面的具體實現類;d.值對象(Value Object)這樣可以把數據訪問的方法抽象在一個介面中,不同資料庫的存取代碼實現在implement介面的相應實現類中,這樣如果有變動或更改(如資料庫表的改變或移植到其他資料庫),業務邏輯只調用介面,具體實現類的變動便不會影響到上層.
4.ORM就是Object Relation Mapping,因為現在關系資料庫已經變得非常成熟,所以大部分資料庫依然是關系型的,這樣就造成了用jdbc存取出來的ResultSet轉變為一個Value Object的冗餘代碼,也造成了插入和修改的大量代碼,最重要的是當資料庫表進行了變化的時候,要更改很多處地方,很不方便.ORMapping就是運用反射和動態代理把相應的資料庫表映射為一個值對象,極大程度的方便了開發和使用.但是一切遵循的規律就是得到一些,失去一些,得到方便的同時,你不得不告訴程序你要怎麼來進行相應的映射,也就是XXX.hbm.xml文件的配置.
4.由於社會有ORM這個需要,便出來了一個名叫Hibernate的框架.Hibernate是ORM的一個非常方便的實現框架,它的優點就像其他很多框架一樣有很多,一言難盡,我感覺如果想掌握它的精髓就是了解框架的結構,明白配置文件編寫,學會使用HQL.開源世界中還存在一些好的ORM框架,如ibiats,等.
4.關於數據存儲層的演化,我的同事小羅每當看到xiaxin和其他兩人一起寫的<深入淺出Hibernate>的第一章1.2和1.3節的時候都會不由自主的發出感嘆:'這部分寫的實在是太好了,一步一步由淺入深,一步一步簡化,每次當你覺得已經簡單的不能再更簡單的時候,總會有新的方法來解決,一步一步,最後當一切都用完了,一切都不能再進步的時候,你一抬頭,Hibernate出現了.'
Web開發方面我的理解現在只到達了這種水平,這是我十一躺在從家裡回深圳的火車上,躺在下鋪,望著中鋪白底板時突然悟到的,對你的職業一定要'通透',是我當時唯一的感覺.
接下來我打算寫一些簡單的文章,我的小說還在醞釀中,我發現荒誕小說要是沒有一個具體的劇情,看起來似乎不能引人入勝,這是我在看<漲潮海岸>電影時發現的.
呀,跑題了.
接下來我打算寫一些簡單的文章,只是介紹一些基礎的小文章,因為我上周日去逛八卦三路的圖書批發市場看到還有人在買struts方面的書,我的一個同事都說struts過時了,我想總要為大家貢獻些自己的力量來幫助新人,讓他們能夠分享些我的經驗.
又快跑題了,下面我的文章准備這個順序寫<J2EE 1.4 基礎(核心?)指引>,<Struts 基礎(核心?)指引>,<Hibernate 基礎(核心?)指引>,<Spring 基礎(核心?)指引>.Spring之所以放在最後是因為它可以起到一個融合這幾個框架的容器功能.
其實我說要寫的文章就是想把我認為題目裡面比較重要的東西說出來,最核心的,最常用,最必須知道的東西簡單的說一下,做個引導,具體細節市面上有很多很多書可以看啦. :)
ps:每個框架都有其優缺點,都有其適應的環境,請分析好需求在選擇,不要盲目的跟風,但可以學習. :)
12月2號聽說竇唯要來深圳,報紙上說它在上步店和南山店,不過是什麼店卻沒說,<雨吁>裡面他終於開始發音了,好開心. :D
//2006-12-01 0:56 finished
//12-06 23:19 最近看了幾家國際性大軟體公司的面試要求,發現他們都要求會EJB和Web Service,可我只是了解些簡單的概念,還沒怎麼接觸過呢,有空打算學習一下.大公司原來都不用開源框架阿,真厲害,這可怎麼辦呢.何去何從? P:
//12-12 00:37 聽同事說:大多銀行系統都需要用EJB,因為他們常常牽扯到多個資料庫和分布式,大公司需要的主要是穩定的系統架構,要商業化的穩定,不需要頻繁的發布和更新的版本.看來我得更加全面的學習和了解整個行業的動向阿,以前我看網上的評論,都以為EJB已經沒人用了呢,這回也要學習一下了,還有Web Service.不過要學習的東西真的好多阿,得一步一步來,千萬別急,踏踏實實. 最近在重新溫習SQL語言,從頭到尾在學習一遍.我現在再聽yw送給我的雅尼音樂會. :)
<游戲開發中的人工智慧>出中文版了,上周日下午的時候在購書中心發現的,還有一本好像叫<大型MMP網路游戲的構架>之類的書,都是很不錯. 計劃,我現階段技術方面的計劃暫時是重溫SQL,快速重溫Struts,快速重溫Hibernate,仔細重溫Spring,然後把這三個框架組合在一起的那幾個項目的代碼好好學習研究一把,看看它們之間現實中真正是怎麼使用的,多看幾遍,理解深入.然後簡單了解Ajax的原理.然後就開始學習EJB,先速度稍快的全部學習一遍,不要求每個細節,只了解大致構架,目的,好處,用途.然後稍快的瀏覽一下Web Serivce,達到目標同EJB.然後再回過頭來學習一遍前面這些項我那時認為重要的和需要掌握的.每一次學習完畢都要總結一下經驗,讓潛意識去處理.恩,現在我也只能暫時計劃到這里了.
⑶ Web工程的分層開發中，每一層的含義和作用是什麼
通俗的講，web工程一般分為三層：視圖，控制和持久層。視圖層自然就是展示給用戶的，一般是jsp或者html頁面等。控制層是控制業務邏輯的，就是具體的實現，持久層當然就是資料庫了。
⑷ web開發中三層結構和四層結構分別指哪三層和哪四層
三層就是:MVC吧,表現層、業務層、數據讀取層
四層就是:客戶機瀏覽器、Web伺服器、數據倉庫及模型倉庫、分布式資料庫群及模型庫群
⑸ Web應用程序為什麼分層開發
分層不是為了代碼的化簡，實際上分層之後代碼只會增加。
分層是為了整個應用的設計和維護。
如果你要開發一個簡單且永久不變的應用，當然可以將一堆代碼放在一起。但現在的技術發展和用戶需求的變化如此之快，誰能保證開發一個系統之後可以一直用下去。當你想修改程序的一些功能的時候，發現自己編寫的東西全部集中在一個文檔里，太雜了，牽一發而動全身，消耗太大了。同樣，設計的時候要考慮所有的邏輯還要考慮視圖在內，不亂才怪。
分層之後，上一層只需要調用下一層提供的介面就能使用下一層提供的服務，而下一層對上一層不具有依賴性，增加代碼的可測試性和可重用行。
web應用分層方式很多，一般分為表現層，業務邏輯層和數據訪問層，如果要改變視圖就直接在表現層操作，不用修改另外的兩個層。而且不同層可以教給不同人員去開發，再整合一下就可以了，是不是清晰很多了呢
⑹ 通常所說的web應用程序分3層，即mvc，如果我想分4層，應該怎麼分
你不找一個現成的MVC 框架 而要用servlet 自己來做，當然不會那麼清晰
以至於別的用過mvc框架人想告訴你什麼事情，所說出來的可能都是一些你沒聽過的概念，以至於溝通不能。
建議看下面的站點
https://msdn.microsoft.com/en-us/library/ff650511.aspx
， 這是2003年微軟為了在 http://asp.net 基礎上實現mvc 做的探討與說明。
那個年代http://asp.net還沒有MVC 產品，所以這個文檔剛好符合你現在的狀況 也就是落後了時代大概12年的狀況