java架構設計,java架構設計經驗

本文目錄一覽：

• 1、北大青鳥java培訓：信息架構的概念與設計方法？
• 2、昆明Java培訓：Java架構師培訓多久能學會？
• 3、java軟體開發的架構設計

北大青鳥java培訓：信息架構的概念與設計方法？

關於信息架構的方法和技巧我們在前幾期的文章中給大家說過不少次了，今天我們就針對信息架構的概念以及設計方法來做一個簡單的介紹，下面電腦培訓就開始今天的主要內容吧。

一、信息架構的概念一個飯店需要有哪些設施，如果你是飯店的老闆如何合理的排布這些設施，可以讓客戶感覺很舒服的用餐，這個過程就是一個信息架構的過程。

他可以讓客戶對你的飯店產生好感，從而下次用餐的時候還會想到來你這裡吃飯。

在排布飯店設施的過程中我們要遵循一些規範，比如用戶的習慣或者施工規範等，正是因為需要遵循這些規範，所以我們需要一個信息架構來體現這些。

比較官方的信息架構解釋是這樣的：信息架構設計是對信息進行結構、組織以及歸類的設計，好讓使用者與用戶容易使用與理解的一項藝術與科學。

簡單來說，信息架構設計就是讓用戶可以容易地理解你的產品是怎樣的。

讓他們在使用你產品的時候可以更順利更自然。

就像一進入飯店就會有一種感覺，門口是等餐的地方，進去就應該吃飯，如果找洗手間一定不會往門口走，而會往深處走。

這就是信息架構的好處：他讓用戶使用同類產品時更容易上手和理解，讓產品更容易被接受。

二、如何設計信息架構1.了解用戶，場景，習慣你的產品是給到用戶用，你當然要了解你的用戶，我們先來看下一個概念：「心智模型」。

心智模型是經由經驗及學習，腦海中對某些事物發展的過程，所寫下的劇本。

人類在經歷或學習某些事件之後，會對事物的發展及變化，歸納出一些結論，然後像是寫劇本一樣，把這些經驗濃縮成一本一本的劇本，等到重複或類似的事情再度發生，我們便不自覺的應用這些先前寫好的劇本，來預測事物的發展變化。

心智模型是你對事物運行發展的預測。

再說得清楚一點，你「希望」事物將如何發展，並不是心智模型，但你「認為」事物將如何發展，就是你的心智模型了。

假設你從沒見過iPad，而我剛遞給你一台並告訴你可以用它來看書。

在你打開iPad使用它之前，你頭腦里會有一個在iPad上如何閱讀的模型。

你會假想書在iPad屏幕上是怎樣的，你可以做什麼事情，比如翻頁或使用書籤，以及這些事情的大致做法。

即使你以前從沒有使用過iPad，你也有一個用iPad看書的「心智模型」。

你頭腦里的心智模型的樣式和運作方式取決於很多因素。

昆明Java培訓：Java架構師培訓多久能學會？

Java架構師培訓多久能學會？首先，對於很多Java應用級程序員來說，架構師是未來一個重要的崗位升級方向，從當前Java語言的應用情況以及未來的發展趨勢來看，Java架構師未來的需求量依然比較大。

要想成為一名Java架構師，既需要在開發崗位上進行技術經驗的積累，同時也需要有一個自主學習計劃，從當前的技術發展趨勢來看，Java架構師需要具備以幾個方面的知識和能力：第一：Java架構師培訓多久能學會？平台知識。

當前在業務領域的Java開發通常要基於技術平台來展開，這些技術平台涉及到雲計算(大數據)平台、物聯網平台和人工智慧平台等，所以對於Java架構師來說，要想完成項目的架構設計，首先需要從掌握平台知識開始。

未來在產業互聯網時代，對於技術平台(尤其是雲計算)的理解能力能夠在很大程度上決定Java架構師的設計能力。

第二：Java架構師培訓多久能學會？介面設計能力。

介面設計是Java架構師的主要工作內容之一，由於Java語言的抽象程度比較高，所以對於介面設計的要求往往比較高，而且基於技術平台的介面設計與傳統的介面設計也存在加大的差異，所以這部分內容也需要重點提升。

傳統的Java介面設計會分成三個大的部分(層次)，涉及到業務層、服務層和數據層，而基於平台的介面設計，還需要考慮如何藉助於平台來實現功能擴展，需要在原有的介面設計上進一步抽象。

第三：Java架構師培訓多久能學會？模塊規劃能力。

Java語言雖然有諸多優點，但是Java語言自身的模塊化能力是比較弱的，早期的Java架構師會通過OSGI來解決這一問題，直到Java9的時候，Java語言本身才提供了模塊化的功能。

對於Java架構師來說，Java模塊的規劃對於後期的項目擴展具有非常直接的影響，這部分設計既需要考慮到程序本身的復用，還需要考慮如何在技術平台下工作，這比較考驗架構師的設計能力。

最後，當前對於Java程序員來說，要想成為Java架構師，需要首先從雲計算平台開始了解，然後進一步通過雲計算平台來向大數據部分進行擴展，這個過程中也會掌握一系列技術體系(包括框架和工具)，由於內容相對比較多，而且往往需要通過場景來進行鍛煉，所以通常需要學習較長一段時間(一年以上)。

java軟體開發的架構設計

軟體架構作為一個概念，體現在技術和業務兩個方面。

從技術角度來說：軟體架構隨著技術的革新不斷地更新其內容，軟體架構建立於當前技術和一些基本原則的基礎之上。

先說一些基本原則：

分層原則：分層是為了降低軟體深度複雜性而使用的關鍵思想，就像社會有了階級一樣，軟體有了層次結構。

模塊化原則：模塊化是化解軟體廣度複雜的必然手段，模塊化的目的就是讓軟體分工。

介面實現分離原則隨著軟體模塊化的不斷深入改進，面向介面編程而不是面向實現編程可以讓複雜度日趨增高的軟體降低模塊之間的耦合度，從而讓各模塊更輕鬆改進。從這個原則出發，軟體也從微觀進行了細緻的規範化。

還有兩個比較小但很重要的原則：

細節隱藏原則很顯然把複雜問題簡化，把難看的細節隱去，能讓軟體結構更清晰。其實這個原則使用很普遍，java/c++語言中的封裝原則以及設計模式中的Facade(外觀)模式就很能體現這個原則的精神。

依賴倒置原則隨著軟體結構的進一步發展,層與層之間、模塊與模塊之間的依賴逐漸加深，而層、模塊的動態可插拔要求不端增大。依賴倒置原則可看視為介面實現分離原則的深化，根據此原則的精神，軟體進入了工具時代。這個原則有點類似於知名的好萊塢法則：Don’t call us, we’ll call you。

以上這些原則奠定了我們的軟體架構的價值指標。但軟體架構畢竟是建立在當前技術之上的。而每一代技術都有架構模式。過去的不再說了，讓我們就來看一下當前流行的技術，以及當前我們能採用的架構。

因為面向對象是當前最流行開發技術，且設計模式的大量使用使面向對象的走向成熟，而資料庫是當前最有效的存儲結構、web界面是當前最流行的用戶介面，所以當前最典型的三層次架構就架構在以上幾項技術的基礎之上，用資料庫作存儲層、用面向對象來實現業務層、用web來作為用戶介面層。我們從三層次架構談起：

因為面向對象技術和資料庫技術不適配，所以在標準三層次架構的基礎上，我們增加了數據持久層，來管理O-R雙向映射，但目前一直沒有最理想的實現技術。cmp和entity bean技術因為其實現複雜，功能前景有限，已接近被淘汰的邊緣。JDO及hibernate作為o-r映射的後期之秀，尤其是hibernate，功能相當完備。推薦作為持久層的首選

在業務層，因為當前業務日趨負載，且變動頻繁，所以我們必須有足夠敏捷的技術來保證我們的適應變化的能力，在標準j2ee系統中session bean負責業務處理，且有不錯的性能表現，但採用ejb系統對業務架構模式改變太大，且其複雜而昂貴，業務代碼移植性差。而spring 作為一個bean配置的輕量級架構，漂亮的IOC模式實現，對業務架構影響小，所以推薦作為中間層業務框架。

在用戶結構層,雖然servlet/jsp/jstl/javaBean 能夠實現MVC架構，但終究過於粗糙。struts對MVC架構的實現就比較完美，Taperstry也極好地實現MVC架構，且採用基於事件的方式，非常誘人，惜其不夠成熟，我們仍舊推薦struts作為用戶介面層基礎架構。

因為業務層是三層次架構中最有決定意義的，所以讓我們回到業務層細緻地分析一下，在複雜的業務我們常常需要以下基礎服務的一種或幾種：事務一致 性服務acid(tool:jta/jts)、並發加鎖服務concurrentlock、池化管理服務cache、訪問控制服務(tool:jaas)、流程式控制制服務workflow、動態實現服務IOC，串列化消息服務(tool:jms)、負載平衡服務blance等。如果我們不採用重量級應用伺服器(如weblogic,websphere,jboss等)及重量級組件(EJB)，我們必須自己實現其中一些服務。雖然我們大 多情況下，不需要所有這些服務，但實現起來卻非易事。幸運的是我們有大量的開源實現代碼，但採用開源代碼卻常常是件不輕鬆的事。

隨著xml作為結構化信息傳輸和存儲地位日漸重要,一些xml文檔操作工具(DOM,Digester,SAX等)的使用愈發重要，而隨著 xml schema的java binding工具(jaxb,xmlbean等)工具的成熟，採用xml schema來設計xml文檔格式，然後採用java binding來生成java bean 會成為主要編程模式,而這又進一步使數據中心向xml轉移，使在中小數據量上,愈發傾向於以xquery為查詢語言的xml資料庫。現還有一個趨勢， microsoft,ibm等紛紛大量開發中間軟體如(microsoft office之infopath)，可以直接從xml schema 生成錄入頁面等非常實用的功能。還有web service 的廣泛應用，都將對軟體的架構有非常重大的影響。至於面向服務架構(SOA)前景如何，三層次架構什麼時候走入歷史，現還很難定論。

aop的發展也會對軟體架構有很深的影響，但在面向對象架構里，無論aspectJ還是jboss-aop抑是aspectWerks、 nanning都有其自身的嚴重問題：維護性很差，所以說它將很難走遠。也許作為一個很好的思想，它將在web service里大展身手。

rdf,owl作為w3c語義模型的標誌性的語言，也很難想像能在當前業務架構發揮太大影響。但如果真如它所聲稱那樣，廣泛地改變著信息的結構。那麼對軟體架構也會有深遠影響。