近期開發基于以太坊的智能合約，為實驗室的分布式電商系統提供可信的“第三方信用擔保”功能。

由于初期項目需求變動會比較頻繁，并且智能合約一經發布于區塊鏈上就無法修改，即使智能合約中有Bug需要修復或者業務邏輯變更，它也不能直接在原有的合約上直接修改再重新發布。因此在即將發布第一版之前，需要結合業務場景考慮合理的升級改造機制。

初版的智能合約主要包括如下功能：

1. 買家創建訂單，合約記錄訂單基本信息并且需要買方向合約支付交易費用
2. 賣家取消訂單，賣家在發貨前可以取消訂單，合約自動將交易費用退回給買家
3. 賣家發貨，合約記錄相應訂單的物流信息，修改訂單狀態
4. 買家確認收貨，合約將交易費用轉移至賣家，并且修改訂單狀態為已完成
5. 基本的訂單查詢功能

通過簡單的需求介紹，可以看出合約中會保存著交易費用，訂單數據以及基本的電商交易流程動作。

起初寫的智能合約全部集中在一個contract，里面會保存交易費用，訂單數據以及電商交易的全部流程。一旦發布就不能修改（哪怕是添加一個方法，修改方法邏輯以及數據中添加新的字段，，，），因為重新發布新的合約之后，之前的訂單數據以及交易費用全部在舊的合約中，從工程的角度來看，同時維護新舊合約（也許好多個舊合約，，，，）簡直不能更糟糕。

因此決定將業務邏輯和數據從合約代碼層面就做好分離，即合約分為了兩類：邏輯合約以及數據合約。邏輯合約通過訪問數據合約獲得數據，并對數據做邏輯處理，然后寫回數據合約，專注于對數據的邏輯處理和對外提供服務。邏輯合約不存儲任何狀態；數據合約專注于數據結構定義與所存儲數據的讀寫接口。

邏輯合約與數據合約存在操作關系，邏輯上分為四類：

1. 邏輯合約與數據合約 1對1
2. 邏輯合約與數據合約 1對多
3. 邏輯合約與數據合約 多對1
4. 邏輯合約與數據合約 多對多

根據本項目的業務場景，采取邏輯合約與數據合約1對1的關系（后續業務復雜，可以改造為多對1），綜上，初期的設計圖如下：

首先進行數據與邏輯的分離。

數據合約包括狀態，以及每個狀態對應讀寫方法（set&&get），部分代碼如下：

邏輯合約因為僅包含業務邏輯，不會存儲任何的數據狀態，因此使用Solidity的library進行編寫。

library的好處是它是單實例，只會更新一個library文件，不會像contract那樣因為各種依賴產生‘漣漪’效應，對于經常變動的業務邏輯代碼，使用library每次更新會節省大量gas消耗。

library是需要被合約調用才能執行的，調用library的contract（下面簡稱A），使用的delegatecall方法，因此library執行的上下文環境在A中，也就是library的msg.sender是A，并且可以直接修改A中的storage。直白說，A調用library，就是把library的代碼import到自己的內部執行了。

因為業務邏輯合約使用了library編寫，library的調用是需要合約觸發的，因此需要一個入口合約，來去調用library操作數據合約，而且對于本項目的實際需求，上面將數據以及邏輯進行分離后，忘記了一個重要的方面，就是資金存儲，引入入口合約后，正好解決了這個問題，客戶端調用入口合約代碼，將資金充入入口合約，并且由入口合約進行資金的轉移過程。