Dumbcat's Note

MVC在軟體工程中是個常見的詞彙，它所代表的是一種 架構模式(architectural pattern) ，例如Repository、Layered、Client-Server、Pipe & Filter都是一些常見的架構模式，架構模式是一種概念，用於解釋與描述軟體架構的一些必要的膠合元素(cohesive elements)。 MVC模式通常用於開發使用者介面的應用程式，由資訊呈現給使用者與從使用者接受的方式，來區分資訊在軟體內部的表達方式；MVC架構的目的是在於實現動態程式設計，降低後續對程式的修改、擴充的難度，簡化程式的架構，並且提升程式的重用性。 在MVC架構中軟體系統分為三個部分，模型(model)、視圖(view)、控制器(controller)；然而如同前面所說的， MVC是一個概念，並不是一個模型或者標準，這使得許多框架在實作自己的MVC架構時，對於三者所負責的功能或多或少有些許不同 (其中個議題引起相當大的迴響，模型與視圖之間到底會不會互動，有興趣可以參考— MVC是一個巨大誤會 )；撇開三者間太細節的定義，大致上可以區分三者的功能為: 控制器(controller): 介於模型與視圖之間，負責處理整個應用程式的流程控制。 模型(model): 負責資料的處理，例如資料庫的存取、資料的驗證與稽核等。 視圖(view): 提供使用者視覺化的介面，接收使用者的輸入或回覆應用程式的結果。 上圖是我認為比較客觀的MVC架構的流程圖；視圖會接收來自使用者透過介面所給的輸入，視圖會將這些輸入資料給控制器，控制器會將資料轉交給合適的模型，模型將資料處理完後所得的資訊傳給控制器，控制器會把資訊給合適的視圖呈現給使用者。 最後仍然必須再次強調，MVC是一個概念而不是標準，不同的語言、不同的框架在實作MVC模式時都會有不一樣的地方；重點在於如何實現動態程式設計，提升應用程式的擴充性與重用性，並降低其複雜度。

MQTT的全名為Message Queuing Telemetry Transport，為IBM和Eurotech共同製定的通訊協定，MQTT是為物聯網所設計的M2M通訊協定，網路頻寬與硬體需求非常少，是極為輕便的通訊協定。MQTT通訊協定是基於TCP/IP連線，並提供自有的不同QoS(Quality of Service)層級的訊息傳遞，適用於網路連線不佳的環境、CPU較弱的嵌入式裝置。 MQTT的封包分為三個部分，分別為Fix Header, Variable Header, Payload，在PUBLISH與SUBSCRIBE封包中，QoS會在Fix Header中定義；對於MQTT封包的詳細內容可以參考MQTT官方文件第二章：MQTT Control Packet format。 QoS定義訊息傳送的品質，確保發布的訊息有被確實接收，MQTT定義的QoS分為0、1、2三個等級，在程式撰寫時會在Publisher發送訊息與Subscriber發起訂閱時指定各自的QoS等級： 0：At most once 訊息最多傳送一次，不會確認訊息傳送的結果，不會儲存訊息；如果Subscriber已中斷連線，或如果Broker故障，則該訊息就會會遺失。 在下圖中，Publisher並不能確認Broker是否有收到訊息，同樣的Broker也不能確定Subscriber是否有收到訊息。 1：At least once 一律會傳送訊息至少一次，如果傳送端未接收到確認通知，則會再次傳送訊息並設定DUP(duplicate)旗標，直到接收到確認通知為止。 如下圖，Publisher會在封包Header中加入packet identifier識別碼，訊息發送給Broker之後，Broker會回傳PUBACK(publish acknowledgment) 封包給Publisher，其中也有相同的packet identifier識別碼，讓Publisher確認訊息已經確實送達；同樣的方式也作用在Broker與Subscriber之間。 接收端在處理訊息之後，會從接收端中刪除訊息。如果接收端是Broker，則會將訊息發佈至其Subscriber。如果接收端是Subscriber，則會將訊息遞送至其應用程式。刪除訊息之後，接收端會傳送確認通知至傳送端。 ...

Asynchronous Programing 一開始要先清楚何謂同步與非同步，同步比較簡單，就像是我們去銀行辦事情，你填好單子交給行員，之後你必須在行員的櫃台一直等他完成作業，無論是開戶、領款、或者存款，這樣就是同步作業；你的程式送出request之後必須一直等待到response，才可以做其他事情。 而非同步作業時常與多執行緒作業畫上等號，實際上是不同的，多執行緒就像是有六十個人要在銀行開戶，所以銀行開了10個櫃台來處理這60個作業，但是每個櫃台實際上還是執行著上面說的同步作業。 而非同步作業是你今天要開戶，填好單子給行員之後，你可以去隔壁買飲料，點完飲料你可以去隔壁買衣服，店員幫你包裝衣服的時候你可以去7-11繳個電話費，然後飲料店叫到你的號碼了你回去拿飲料，服飾店員說你的衣服包好了你回去拿衣服，最後回到銀行剛好叫到你的號碼再去櫃檯拿你的存摺；對於程式而言， 你的程式送出request之後，到收到response之間，程式可以去做其他事情。 當瞭解同步與非同步作業之後，會延伸一個問題，你要對誰送出的request跟誰會送給你response?對於這個程式角色他必須有一個特性，它必須一直都存在，當你送出一個request之後，它會接收、處理，然後回覆給你一個response，當你再次送出一個request的時候，它也會重複同樣的程序，就像一個等待你的request的迴圈一樣；這樣的設計模式(Design Pattern)有個名字叫反應堆模式(Reactor Pattern)，或者叫事件迴圈(Event Loop)、 Select迴圈(Select Loop) 。 下面這張圖就說明了反應堆迴圈的執行方式－等待事件、處理事件的無限迴圈；這個反應堆在程式執行期間會一直存在著，你給他一個request，就是一個event，它會處理完，給你response，然後繼續安靜的等待下一個request。 Callback Function 接著說明一下callback function，在一般的程式中，你寫了一個function，然後你在程式碼中呼叫這個function，我們可以稱為「call」一個function；如果你寫了一個function，然後把這個function的指給了某一個套件、框架、或者其他的程式，這個function在合適的時間，會由這些套...