這個主題是寫給外行人和新人看的，沒有嶄新或厲害的高深內容。

只是以個人角度的，軟體開發的歷史的一個經驗縮影而已。

分兩段，一段是web2.0時代以前的商業應用軟體開發經驗，後面一段則是web2.0時代以後的，大概是相同目的的應用軟體開發經驗。

只是相對簡單的商業應用軟體開發，組合語言或驅動程式的韌體與底層通訊應用程式等等就不在涵蓋範圍內，因為傻蛋那方面沒多少經驗啦。

本篇為下篇。

繼續吧。

上面提到Web2.0與智慧型手機時代讓整個生態有了很大變化。

但除此之外還要提到一個叫Ruby on Rails的技術與其帶來的對應文化，與物件導向後續產生的設計模式風潮的MVC設計模式開始談起。

Ruby on Rails，以下簡稱RoR，是一個開發框架，而不是某一個程式語言工具那樣。

這個框架是用來快速開發網頁應用程式。

核心理念是，不要Java那樣繁瑣的系統設定，反正都是要開發那樣的網站，就用一些慣例來取代設定，讓開發標準的網站可以很省工。

只從這個角度來說，RoR是非常成功的。

開發一個簡單的內容網站，使用RoR，可以很快，因為該有的都有現成整合好的了。

會員帳號登入，甚至是關鍵字查詢與緩存的機制等等，有一整套的配套措施，連數據庫版本如何管理都是一整套有前人先做好的。

然後這個框架使用了所謂的MVC設計模式。

MVC，Model View Controller這個設計模式傻蛋是比較後來才聽到的。

物件導向設計後冒出了一大堆所謂的設計模式。

這個MVC也是一種設計模式，針對網站應用開發的設計模式吧。

那是因為當時新工作使用的是叫做MVP的號稱更新更新進的設計模式，Model View Presentor這樣的設計模式。

說真的，剛接觸的時候，兩個還真的是傻傻分不清楚。

直覺的印象是，把系統固定切成三塊，總比所有邏輯通通混在一起要來得好對吧？

所以不管是控制器調用數據去更新畫面還是表現器調用數據去服務畫面，大概都是差不多意思，應該就是把數據隔離在一層，使用者互動介面隔離在一層，把兩者分開，感覺好像就是那樣吧？

真的，這個設計模式超流行，所以到處都是MVC。

甚至傻蛋自己在設計api應用程式介面的時候，也讓介面的架構看起來像MVC，實際上，後來搞懂後，應該只能稱為偽MVC。

好，那MVC到底是什麼？

其實應該是，系統就是一些簡單的數據模型，然後系統的功能結構和這個數據模型是對應的，每個模型或者說物件導向的一個物件類別，其對應的增刪改查都有各自的網頁網址慣例的固定格式，查詢還分成單筆和列表那樣，然後數據變化畫面呈現就跟著變化，那個View就是數據搭配樣板規則自動產生對應網頁，就是用這樣的慣例來構成一個系統。

就以udn部落格這樣的網站功能為例，前台功能使用MVC搭配RoR的那樣的框架，開發起來會很簡單。

某些用得特別熟練的人搞不好幾個小時就弄好一個有差不多功能的部落格網站了。

Model就文章，相簿，與訪客留言三個主要的。

文章裡面還可以再針對一篇文章留言，另外文章還有作者自訂文章分類，還有文章推薦，訪客留言有留言和針對留言的回覆。

其他的就是作者的個人資料設定，以及登入帳密功能，大概就是這樣吧。

MVC的設計基本上就會是，文章列表，一篇文章的內頁，新增一篇文章的新增頁面，修改一篇文章的的編輯頁面，刪除一篇文章的連結，都會配置一個網址規則，如/posts就是文章列表，/posts/1是id為1的那篇文章內頁，文章內頁的網誌根據網頁動作是get/post/put/patch/delete自動判斷是要查看還是新增修改刪除那樣。

都是用約定成俗的方式設計就好了。

然後一個網站就真的開發出來了喔！

好棒對不對？

新增的文章還會寫入數據庫，開發的人還不用學習有點複雜的數據庫操作DML的語法，只需要學會一些簡單的物件操作指令就可以了，很酷對吧？

很多人是這麼覺得的。

以前，需要花很多時間分析設計開規格然後花很長時間才能開發出來的一個網站，用RoR這樣的框架可以很快就完成上線。

於是這種設計模式就大為風行。

我們看到其他程式語言的流行開發框架，大部分基於MVC設計模式的框架，大部分都是很用力的借鑑參考RoR這個框架的實務做法，模仿出來的。

可以說很大比例的Web開發框架都是對RoR的致敬，模仿的程度高低不同而已。

所以MVC與RoR很棒，對嗎？

如果需求就是簡單的部落格前台，那答案是肯定的。

但如果需求更加複雜，有更多需要被滿足的功能，還有後台需要和更複雜的交互多角色的各種使用情境的話，答案其實會剛好相反。

事實上，除了少數簡單的內容型應用，套用MVC的架構，實際上只是給自己增加諸多限制而已。

Veiw與Model邏輯上需要對應，這是限制，打破的話那個規則就全亂了。

Model要綁數據庫表格也是一個很大的限制。

還需要網址規則的配合，整個架構都必須如此。

通常需要開發後台功能的時候就會打結了。

因為關聯變複雜了，加上同一個Model有不同權限角色共用的情境，那些規則就沒有一開始想得那麼簡單，要套用相同的慣例的設計方式就會很卡。

所以，後來才又出現MVP與MVVM的新設計模式，說穿了也就是把View與Model的對應綁定打破而已。

如果我們回到單機應用程式開發的那個經驗來看，這些都是本來不存在的限制。

畫面該怎樣設計就怎樣設計，那是看業務面需求是什麼，不需要那麼多慣例，也不需要和網址規則有捆綁。

好不好維護完全看設計的人是否有良好的模組化設計思維而已，其實這個道理一直都適用，不論是否是物件導向，不論是否使用MVC之類的設計模式，不論使用者介面是傳統應用程式還是網頁的操作介面，那都是一樣的。

所以就商業軟體應用來說，其實應該不需要MVC，或許才比較貼合實務的情況才對。

不過呢，如php的Laravel，很多人用的Web框架大部分都是很RoR風格的。

網頁系統架構是RoR風格是一回事。

前面提到，隨著智慧手機的App需求，系統的API化也是新趨勢。

那API怎麼設計?

很有趣的，有一個叫Restful的API設計風格，基本上也很向RoR致敬。

RoR風的MVC網站，可以用猜網址來做某些操作，網址通常對應使用者介面。

而restful的API基本上就是那個風格的設計，只差其沒有使用者互動的介面，而是用簡單的json文字格式作為API回應的格式而已。

所以呢？

Restful風格的API，可以簡單理解為存取網址和數據模型要有高度關聯那樣。

然後呢？

在RoR風的網站裡面也可以支援API的服務喔，設計風格還一模一樣，很厲害吧？

所以最終版的最長見的現代網站，結構通常都是這樣的，外面一層MVC，網址對應畫面功能，同時網址內的/api下面又放了一層提供api服務的功能，最後呢，我們前面說到，讓網頁可以不用每動一下就整頁重新閃一下載入的非同步呼叫，就是MVC的View直接提供一個位置，然後再用前端框架的物件去實現那些需要非同步呼叫的功能，那些功能再呼叫自己提供的Restful設計風格的api，最常見的網站多半是這樣的解決方案的框架。

上面那個句子很長，覺得好像很複雜很麻煩，實際上呢，也的確是很複雜很麻煩。

不需要非同步操作的功能，就是Model的數據搭配後端樣版套版產生動態網頁回傳就好，需要流暢的互動操作體驗的就去套用前端框架由前端框架去產生畫面。

有那裡不一樣與麻煩的地方？

那是真的很麻煩。

傻蛋剛開始碰ASP.net的時候，碰到那種需要Ajax非同步呼叫的或前端簡單檢查輸入的情況，常會碰到問題。

有些數據是瀏覽器前端才有，有些則是跳頁時後端頁面在服務器處理時才能存取獲得的。

兩個情境的數據是不互通的。

微軟早期使用了一個簡單的叫ViewState的方案，只要簡單的開啟，前後端的數據就互通了，很方便。

但那個方案是要付出代價的，如果頁面是一個較大的表格如排班表格，有垂直水平卷軸那樣的大表格，開啟ViewState這個簡單的動作可能會導致每一次頁面動作往後面主機傳輸數據量會變得非常大。

大到完全不切實際的程度，每點一下就要傳輸數十MB的數據，這完全不能用來開發產品，只能用來做玩具而已。

在以前，只需要考慮畫面元素與事件，照著事件去寫程式就好，很簡單。

現在，一個頁面要分兩個階段。

第一個階段是剛收到後端開啟時，那個時候收到的請求可以直接便利的在主機存取後端數據庫與其他遠端資源，然後再根據拿到的數據來動態產生要回傳給前端的html，同時還要把前端之後要做非同步互動需要的功能需要的前端程式碼也一起回傳回去。

第二階段是後端網頁計算處理完成返回後才開始。

此時前端的瀏覽器會動態載入一些前端框架需要的程式碼，可以存取前端瀏覽器的本地數據，以及透過api存取同一個系統以及外部第三方的功能，再根據收到的結果決定是部分更新畫面上的數據，又或是真的要跳頁，重新跳到另一個後端頁面整頁重新處理一次那樣。

覺得很繞口對吧？

其實如果簡單的開發所謂的單頁應用的話，那麼，前端就是同一個開發情境，和後端唯一的關聯就是透過api，這樣前後端分離的話，其實情境相對就簡單很多。

傻蛋照自己的直覺，開發的系統就是這樣做前後端分離的，使用者介面就是前端全權負責，至於系統最後有效的狀態與數據庫存取更新都是後端負責。

原本傻蛋以為前端開發和後端的分離整合應該多半是這樣做的。

實際上並不是喔。

而是那些MVC後端網頁再夾一個前端物件那樣的結構搞出來的，網站的結構還是用後端網頁決定，前端通常只是一個頁面的樣板的取代而已，實際上要理解整個流程與生命週期，會因此更複雜。

反之如果整個網站前端介面就是獨立的，那網站的使用者介面設計其實就和App沒兩樣了，根據需求設計畫面，該呼叫api時呼叫對應api就好。

所以所以呢？

目前比較常見的，應該還是前後端耦合的RoR風格的MVC設計網站再綁前端框架的解決方案為主吧。

可能就是因為這樣，網站開發的學習曲線，又因此而開始變陡了。

從一開始的好簡單可以好快就弄出一個很像樣的網站，到最後要弄出一個功能要扭過去轉過來好幾折才能做出來，其實應該是退步的吧。

軟體應用程式的開發，就傻蛋個人的體驗，並不是一直進步的。

有時候就是平白的變複雜了。

不懂的時候，看人家都說我們要設計Restful的api，可能就覺得那是厲害的東西，照著做應該也會很厲害很有用。

然而若非簡單的公開資料，Restful風格根本沒有帶來什麼好處，特別是後面還要套權限檢查機制時更是如此。

我只是要把想要的軟體應用開發出來而已。

還是要回歸目的，能滿足客戶的需要，進一步提高開發效率，減少維護的複雜度與成本，要修改時能夠靈活的修改，這才是最重要的事吧？

很難講。

如果大家都用某種風格的開發方式，只有你不用，那要找開發人員就會比較麻煩，或是找工作時會比較麻煩，不是嗎？

不過無論如何，知道現在的軟體開發框架大概的現況，或許可以減少一些莫名其妙的不明覺厲吧，又或是對於自己想要什麼，卻不知道怎麼開始，能多一點線索吧。

有時候不是你笨，而是這個世界複雜得太瘋狂了，那樣而已。