軟件架構(gòu)風(fēng)格，什么是標(biāo)準(zhǔn)的 restful apl

來源：整理時(shí)間：2024-12-10 13:23:31 編輯：智能門戶手機(jī)版

本文目錄一覽

1，什么是標(biāo)準(zhǔn)的 restful apl
2，是什么因素組成了一個(gè)軟件的架構(gòu)風(fēng)格
3，軟件設(shè)計(jì)中的框架和架構(gòu)的區(qū)別
4，常用的軟件架構(gòu)有那些
5，MVC和三層架構(gòu)有什么區(qū)別么
6，什么是軟件架構(gòu)

1，什么是標(biāo)準(zhǔn)的 restful apl

REST不是一個(gè)標(biāo)準(zhǔn)，而是一種軟件應(yīng)用架構(gòu)風(fēng)格。基于SOAP的Web服務(wù)采用RPC架構(gòu)，如果說RPC是一種面向操作的架構(gòu)風(fēng)格，而REST則是一種面向資源的架構(gòu)風(fēng)格。REST是目前業(yè)界更為推崇的構(gòu)建新一代Web服務(wù)（或者Web API）的架構(gòu)風(fēng)格。由于REST僅僅是一種價(jià)格風(fēng)格，所以它是與具體的技術(shù)平臺(tái)無關(guān)的，也就是說采用REST架構(gòu)的應(yīng)用未必一定建立在Web之上.

雖然我很聰明，但這么說真的難到我了

什么是標(biāo)準(zhǔn)的 restful apl

2，是什么因素組成了一個(gè)軟件的架構(gòu)風(fēng)格

說說我的體會(huì)：1、雖然名字都叫軟件架構(gòu)，但在各單位對(duì)這個(gè)工作產(chǎn)出物的具體要求，未必一致，這里邊包括：文檔撰寫的模板、設(shè)計(jì)內(nèi)容的詳略及側(cè)重點(diǎn)、技術(shù)選型的規(guī)定傾向等等吧。這些都可以形成你所謂的風(fēng)格。但這主要是工作的要求因素。2、還有就是設(shè)計(jì)師自己的風(fēng)格了。只有當(dāng)獨(dú)自完成一個(gè)架構(gòu)設(shè)計(jì)的時(shí)候才有看出架構(gòu)師風(fēng)格的機(jī)會(huì)。因?yàn)槠渌闆r下基本都會(huì)為了團(tuán)隊(duì)的協(xié)調(diào)統(tǒng)一而犧牲了個(gè)人的風(fēng)格。這里有一個(gè)前提就是架構(gòu)師確實(shí)用心做這個(gè)設(shè)計(jì)而不是天下文章一大抄，現(xiàn)實(shí)中很多架構(gòu)設(shè)計(jì)都是抄襲和臨摹，這樣的架構(gòu)設(shè)計(jì)都是糊弄事的。這個(gè)算是個(gè)人因素。我覺得應(yīng)該就是這兩種因素。另外對(duì)于抄襲和臨摹這種事在一個(gè)單位里，一般都不是個(gè)案，這個(gè)也可以算是單位或者部門的一種工作風(fēng)格。我把它歸入工作要求因素的一類。

雖然我很聰明，但這么說真的難到我了

是什么因素組成了一個(gè)軟件的架構(gòu)風(fēng)格

3，軟件設(shè)計(jì)中的框架和架構(gòu)的區(qū)別

框架，即framework。其實(shí)就是某種應(yīng)用的半成品，就是一組組件，供你選用完成你自己的系統(tǒng)。簡(jiǎn)單說就是使用別人搭好的舞臺(tái)，你來做表演。而且，框架一般是成熟的，不斷升級(jí)的軟件。構(gòu)架和架構(gòu)也就是通常所說的軟件體系結(jié)構(gòu)(software architecture).體系結(jié)構(gòu)一般包括三個(gè)部分:構(gòu)件,用于描述計(jì)算;連接器,用于描述構(gòu)件的連接部分;配置,將構(gòu)件和連接器組成一個(gè)有機(jī)整體.對(duì)體系結(jié)構(gòu)比較嚴(yán)謹(jǐn)比較認(rèn)可的定義可參見＜軟件工程技術(shù)概論＞（科學(xué)出版社）．體系結(jié)構(gòu)與框架（Framework)的區(qū)別與聯(lián)系如下： 1.呈現(xiàn)形式不同．體系結(jié)構(gòu)的呈現(xiàn)形式是一個(gè)設(shè)計(jì)規(guī)約，而框架則是程序代碼． 2．目的不同．體系結(jié)構(gòu)的首要目的大多是指導(dǎo)一個(gè)軟件系統(tǒng)的實(shí)施與開發(fā)；而框架的首要目的是為復(fù)用．因此，一個(gè)框架可有其體系結(jié)構(gòu)，用于指導(dǎo)該框架的開發(fā)，反之不然． 3．有種特殊的體系結(jié)構(gòu),DSSA(領(lǐng)域特定體系結(jié)構(gòu)）其首要目的也是為了復(fù)用． 4.有個(gè)叫體系結(jié)構(gòu)風(fēng)格的東西，將它用程序代碼實(shí)現(xiàn)后就成了Corba,COM之類的東西，它們倆叫體系結(jié)構(gòu)框架，也叫中間件集成框架，又有人愿意叫它對(duì)象中間件

軟件設(shè)計(jì)中的框架和架構(gòu)的區(qū)別

4，常用的軟件架構(gòu)有那些

1.模塊視圖類型 1)分解風(fēng)格 2)使用風(fēng)格 3)分層風(fēng)格 4)泛化風(fēng)格 2.組件連接器類型(C&C) 1)管道過濾器風(fēng)格 2)共享數(shù)據(jù)風(fēng)格 3)客戶端服務(wù)器風(fēng)格 4)發(fā)布訂閱風(fēng)格 5)進(jìn)程通信風(fēng)格 6)對(duì)等通信風(fēng)格 3.分配視圖類型 1)部署風(fēng)格 2)實(shí)現(xiàn)風(fēng)格 3)工作任務(wù)風(fēng)格不知道是不是你想要的結(jié)果

1。當(dāng)一個(gè)線程進(jìn)入moniter（也就是說站用一個(gè)object），另一個(gè)線程只有等待或返回，而我們把返回就稱為一種模式，這種模式的英文是Balking。 2。這兩個(gè)線程可以是有序的執(zhí)行，而不是讓OS來調(diào)度，這時(shí)我們要用一個(gè)object來調(diào)度，這種模式稱為Scheduler。（這個(gè)詞及其含義其實(shí)OS中就有）。 3。如果這兩個(gè)線程同時(shí)讀一個(gè)資源，我們可以讓他們執(zhí)行，但如果同時(shí)寫的話，你閉著眼睛都會(huì)知道可能出現(xiàn)問題，這時(shí)我們就要用另一種模式（Read/Write Lock）。 4。如果一個(gè)線程是為另一個(gè)線程服務(wù)的話，比如IE中負(fù)責(zé)數(shù)據(jù)傳輸?shù)木€程和界面顯示的線程，當(dāng)一個(gè)圖片沒有傳完時(shí)，另一個(gè)線程就無法顯示，至少是部分沒有傳完。那么這時(shí)我們要用一個(gè)模式稱為生產(chǎn)者和消費(fèi)者，英文是Producer-Consumer。 5。兩個(gè)線程的消亡也可以不是完全又OS來控制的，這時(shí)我們需要給出一個(gè)條件，使得每個(gè)線程在符合條件是才消亡，也就是有序的消亡，我們稱為Two-Phase Termination。那么有這5個(gè)線程模型，基本上可以用到大多數(shù)編程任務(wù)中。我需要指出的三點(diǎn)是： 1。從高層次上我們可以再驗(yàn)證是否含蓋了所有的情況。 2。其實(shí)模式不是完全固定的或者說象定律一樣，而模式可以為不同的情況進(jìn)行適當(dāng) 的調(diào)整和組合，目的是為了簡(jiǎn)潔和高效。 3。學(xué)習(xí)模式是為了具備更好的分析問題的能力。

5，MVC和三層架構(gòu)有什么區(qū)別么

1、一個(gè)是架構(gòu)一個(gè)是設(shè)計(jì)模式（原則上差異）2、MVC中有Controller這個(gè) 而三層架構(gòu)沒有（其實(shí)也可以有）3、Model也有區(qū)別 MVC中的Model是有業(yè)務(wù)邏輯與數(shù)據(jù)訪問組成4、相同點(diǎn)就是都有個(gè)View（這個(gè)必須有）三層架構(gòu)是一種軟件架構(gòu)風(fēng)格——分層架構(gòu)。MVC是分層架構(gòu)的一種模式。一些不同的框架都自稱實(shí)現(xiàn)了MVC，這在一定程度上導(dǎo)致了概念的混淆。有的實(shí)現(xiàn)了三層架構(gòu)的全部三個(gè)層次，如SSH。有的只實(shí)現(xiàn)了視圖層和業(yè)務(wù)層的一部分，如Struts。有的則完全是在視圖層。當(dāng)完全在視圖層時(shí)，其實(shí)就不叫MVC了，應(yīng)該叫MVP。

MVC是一個(gè)框架模式，它強(qiáng)制性的使應(yīng)用程序的輸入、處理和輸出分開。三層，其實(shí)不是真正的三層，也可以多層哦，沒有規(guī)定必須三層具體的找一個(gè)MVC的例子，你研究一下，再加上你之前的理論，一下就能看明白了UI層怎么分，這就是MVC了，找一個(gè)例子，看一下就能明白！

MVC和三層架構(gòu)有什么區(qū)別就是MVC是最流行的三層架構(gòu)中的一種框架，就是模型-視圖-控制器三者分離。MVC模式（Model–view–controller）是軟件工程中的一種軟件架構(gòu)模式，把軟件系統(tǒng)分為三個(gè)基本部分：模型（Model）、視圖（View）和控制器（Controller）。MVC模式最早由Trygve Reenskaug在1978年提出[1] ，是施樂帕羅奧多研究中心（Xerox PARC）在20世紀(jì)80年代為程序語言Smalltalk發(fā)明的一種軟件架構(gòu)。MVC模式的目的是實(shí)現(xiàn)一種動(dòng)態(tài)的程式設(shè)計(jì)，使后續(xù)對(duì)程序的修改和擴(kuò)展簡(jiǎn)化，并且使程序某一部分的重復(fù)利用成為可能。除此之外，此模式通過對(duì)復(fù)雜度的簡(jiǎn)化，使程序結(jié)構(gòu)更加直觀。軟件系統(tǒng)通過對(duì)自身基本部分分離的同時(shí)也賦予了各個(gè)基本部分應(yīng)有的功能。專業(yè)人員可以通過自身的專長(zhǎng)分組：控制器（Controller）- 負(fù)責(zé)轉(zhuǎn)發(fā)請(qǐng)求，對(duì)請(qǐng)求進(jìn)行處理。視圖（View） - 界面設(shè)計(jì)人員進(jìn)行圖形界面設(shè)計(jì)。模型（Model） - 程序員編寫程序應(yīng)有的功能（實(shí)現(xiàn)算法等等）、數(shù)據(jù)庫專家進(jìn)行數(shù)據(jù)管理和數(shù)據(jù)庫設(shè)計(jì)(可以實(shí)現(xiàn)具體的功能)。

6，什么是軟件架構(gòu)

當(dāng)你去了解一個(gè)東東的時(shí)候，第一步要做的，就應(yīng)該去知道這個(gè)東東的定義，對(duì)于軟件架構(gòu)也是如此，經(jīng)過網(wǎng)上查詢和書籍的幫助，我大概理清了一個(gè)輪廓。軟件行業(yè)是一個(gè)熱衷于制造名詞的行業(yè)，如果退回15年，估計(jì)沒幾個(gè)人知道軟件架構(gòu)是什么，在上個(gè)世紀(jì)80年代，隨著軟件開發(fā)的規(guī)模不斷擴(kuò)大，軟件開發(fā)成為一個(gè)行業(yè)，初期，隨之而來的是越來越多的軟件項(xiàng)目的失敗，造成項(xiàng)目失敗的原因很多，但主要集中在開發(fā)過程，所以軟件工程應(yīng)運(yùn)而生，CMMI等流程標(biāo)準(zhǔn)也是一茬接著一茬的冒個(gè)不停。在軟件工程初具規(guī)模的時(shí)候，軟件開發(fā)還是以數(shù)據(jù)結(jié)構(gòu)+算法的形式存在，進(jìn)入20世紀(jì)最后10年，隨著面向?qū)ο蠹夹g(shù)、設(shè)計(jì)模式等在開發(fā)過程中的成功應(yīng)用，軟件架構(gòu)也走進(jìn)了大家的視野。軟件架構(gòu)在定義上分為組成派和決策派兩大陣營(yíng)，分別描述如下：組成派認(rèn)為軟件架構(gòu)是將系統(tǒng)描述成計(jì)算組件及組件之間的交互。它有兩個(gè)非常明顯的特點(diǎn)：關(guān)注架構(gòu)實(shí)踐的客體——軟件，以軟件本身作為描述對(duì)象。分析了軟件的組成，說明軟件不是一個(gè)原子意義上的整體，而是有不同的部分經(jīng)過特定的接口進(jìn)行連接組成的一個(gè)整體，這對(duì)軟件開發(fā)來說很重要。決策派認(rèn)為軟件架構(gòu)包含了一系列的決策，主要包括：軟件系統(tǒng)的組織選擇組成系統(tǒng)的結(jié)構(gòu)元素和它們之間的接口，以及當(dāng)這些元素相互協(xié)作時(shí)所體現(xiàn)的行為用于指導(dǎo)這個(gè)系統(tǒng)組織的架構(gòu)風(fēng)格：這些元素以及它們的接口、協(xié)作和組合軟件架構(gòu)并不僅僅關(guān)注軟件本身的結(jié)構(gòu)和行為，還注重其他特性：使用、功能性、性能、彈性、重用、可理解、經(jīng)濟(jì)以及技術(shù)的限制和權(quán)衡等。決策派有以下兩個(gè)顯著的特點(diǎn)：關(guān)注軟件架構(gòu)中的實(shí)體——人，以人的決策為描述對(duì)象。歸納了軟件架構(gòu)決策的類型，指出架構(gòu)決策不僅包括關(guān)于軟件系統(tǒng)的組織、元素、子系統(tǒng)和架構(gòu)風(fēng)格等幾類決策，還包括關(guān)于眾多非功能性需求的決策。按照組成派的觀點(diǎn)，軟件架構(gòu)關(guān)注的是軟件整體的分割和交互，之所以分割，是因?yàn)椴煌牟糠衷谶壿嫽蛭锢砩舷鄬?duì)獨(dú)立，通過分而治之的原則進(jìn)行分割可以更好的理解整個(gè)系統(tǒng)，把握用戶的需求，但是雖然整個(gè)軟件可以分割成多個(gè)模塊或子系統(tǒng)，但是模塊和子系統(tǒng)之間的通信和交互也是很重要的，我想按照這種觀點(diǎn)，架構(gòu)師的主要任務(wù)是將軟件分割成不同的模塊，并定義模塊之間的接口。按照決策派的觀點(diǎn)，軟件是一個(gè)在很多限制下產(chǎn)生的產(chǎn)品，這些限制包括用戶和技術(shù)兩方面，用戶方面包括功能需求、性能需求、硬件需求等，技術(shù)方面包括技術(shù)選擇、可擴(kuò)展性、可重用性、可維護(hù)性等。我想按照這中觀點(diǎn)，架構(gòu)師的主要任務(wù)就是作出上述個(gè)各種限制作出選擇或決策。《軟件架構(gòu)設(shè)計(jì)》溫昱

軟件架構(gòu)（software architecture）是一系列相關(guān)的抽象模式，用于指導(dǎo)大型軟件系統(tǒng)各個(gè)方面的設(shè)計(jì)。軟件架構(gòu)是一個(gè)系統(tǒng)的草圖。軟件架構(gòu)描述的對(duì)象是直接構(gòu)成系統(tǒng)的抽象組件。各個(gè)組件之間的連接則明確和相對(duì)細(xì)致地描述組件之間的通訊。在實(shí)現(xiàn)階段，這些抽象組件被細(xì)化為實(shí)際的組件，比如具體某個(gè)類或者對(duì)象。在面向?qū)ο箢I(lǐng)域中，組件之間的連接通常用接口來實(shí)現(xiàn)。軟件體系結(jié)構(gòu)是構(gòu)建計(jì)算機(jī)軟件實(shí)踐的基礎(chǔ)。與建筑師設(shè)定建筑項(xiàng)目的設(shè)計(jì)原則和目標(biāo)，作為繪圖員畫圖的基礎(chǔ)一樣，一個(gè)軟件架構(gòu)師或者系統(tǒng)架構(gòu)師陳述軟件構(gòu)架以作為滿足不同客戶需求的實(shí)際系統(tǒng)設(shè)計(jì)方案的基礎(chǔ)。

軟件架構(gòu) 軟件架構(gòu)（software architecture）是一系列相關(guān)的抽象模式，用于指導(dǎo)大型軟件系統(tǒng)各個(gè)方面的設(shè)計(jì)。軟件架構(gòu)是一個(gè)系統(tǒng)的草圖。軟件架構(gòu)描述的對(duì)象是直接構(gòu)成系統(tǒng)的抽象組件。各個(gè)組件之間的連接則明確和相對(duì)細(xì)致地描述組件之間的通訊。在實(shí)現(xiàn)階段，這些抽象組件被細(xì)化為實(shí)際的組件，比如具體某個(gè)類或者對(duì)象。在面向?qū)ο箢I(lǐng)域中，組件之間的連接通常用接口_(計(jì)算機(jī)科學(xué))來實(shí)現(xiàn)。軟件體系結(jié)構(gòu)是構(gòu)建計(jì)算機(jī)軟件實(shí)踐的基礎(chǔ)。與建筑師設(shè)定建筑項(xiàng)目的設(shè)計(jì)原則和目標(biāo)，作為繪圖員畫圖的基礎(chǔ)一樣，一個(gè)軟件架構(gòu)師或者系統(tǒng)架構(gòu)師陳述軟件構(gòu)架以作為滿足不同客戶需求的實(shí)際系統(tǒng)設(shè)計(jì)方案的基礎(chǔ)。軟件構(gòu)架是一個(gè)容易理解的概念，多數(shù)工程師（尤其是經(jīng)驗(yàn)不多的工程師）會(huì)從直覺上來認(rèn)識(shí)它，但要給出精確的定義很困難。特別是，很難明確地區(qū)分設(shè)計(jì)和構(gòu)架：構(gòu)架屬于設(shè)計(jì)的一方面，它集中于某些具體的特征。在“軟件構(gòu)架簡(jiǎn)介”中，david garlan 和 mary shaw 認(rèn)為軟件構(gòu)架是有關(guān)如下問題的設(shè)計(jì)層次：“在計(jì)算的算法和數(shù)據(jù)結(jié)構(gòu)之外，設(shè)計(jì)并確定系統(tǒng)整體結(jié)構(gòu)成為了新的問題。結(jié)構(gòu)問題包括總體組織結(jié)構(gòu)和全局控制結(jié)構(gòu)；通信、同步和數(shù)據(jù)訪問的協(xié)議；設(shè)計(jì)元素的功能分配；物理分布；設(shè)計(jì)元素的組成；定標(biāo)與性能；備選設(shè)計(jì)的選擇?！盵gs93] 但構(gòu)架不僅是結(jié)構(gòu)；ieee working group on architecture 把其定義為“系統(tǒng)在其環(huán)境中的最高層概念”[ieee98]。構(gòu)架還包括“符合”系統(tǒng)完整性、經(jīng)濟(jì)約束條件、審美需求和樣式。它并不僅注重對(duì)內(nèi)部的考慮，而且還在系統(tǒng)的用戶環(huán)境和開發(fā)環(huán)境中對(duì)系統(tǒng)進(jìn)行整體考慮，即同時(shí)注重對(duì)外部的考慮。在 rational unified process 中，軟件系統(tǒng)的構(gòu)架（在某一給定點(diǎn)）是指系統(tǒng)重要構(gòu)件的組織或結(jié)構(gòu)，這些重要構(gòu)件通過接口與不斷減小的構(gòu)件與接口所組成的構(gòu)件進(jìn)行交互。從和目的、主題、材料和結(jié)構(gòu)的聯(lián)系上來說，軟件架構(gòu)可以和建筑物的架構(gòu)相比擬。一個(gè)軟件架構(gòu)師需要有廣泛的軟件理論知識(shí)和相應(yīng)的經(jīng)驗(yàn)來事實(shí)和管理軟件產(chǎn)品的高級(jí)設(shè)計(jì)。軟件架構(gòu)師定義和設(shè)計(jì)軟件的模塊化，模塊之間的交互，用戶界面風(fēng)格，對(duì)外接口方法，創(chuàng)新的設(shè)計(jì)特性，以及高層事物的對(duì)象操作、邏輯和流程。