昨天結尾說今天回到案例，把這些機制逐項歸位。

Day 1 說整套 Northwind 的八張表單裡只有一張需要自己寫程式，並答應系列收尾前把整套應用攤開逐項對帳；那一張裡裝了什麼，Day 3 已經交代過。今天把每一個行為拆開，看每一段由誰負責。

本篇說明：

1. 系統行為的三個層次與各自的判準
2. 一張表單長出來的東西，各層次分別出現了什麼
3. 每一次呼叫都會跑的那些，應用各付出了什麼
4. 手寫的程式剩下哪些、怎麼收斂到框架，以及刻意不走定義的地方

一、系統的行為分三個層次

系統裡的每一個行為拆開之後，每一段都落在下面三個層次之一：

一個行為可以跨好幾個層次

以明細的金額為例，拆開來分屬三個層次：

所以下一節的表上，有幾列寫的是「定義加框架內建」。

表上記的是現況

後面幾張表記的是案例現在的樣子，不一定是該在的位置。該在哪裡，用 Day 2 的判別法判斷：全世界的 ERP 做起來是不是都一樣，一樣的由框架做，不一樣的留給應用。上面那個加總就是例子，每一家都一樣，現在卻還寫在應用程式碼裡。

定義也不全是應用寫的

共用與紀錄兩個分類的 TableSchema 直接用框架的預設；部門、員工、稽核規則與權限那幾張，是照 Day 4 的做法從框架預設複製過來，員工另外加了兩個欄位。

二、一張表單長出來的東西

Day 2 列過由定義衍生的東西：多數是產生，另一種是拿宣告的規則與算式去求值。實際跟著一張表單出現的行為，比那份清單多幾項：

加一張表單要碰的地方全部落在定義那個層次：一份 FormSchema、每張實體資料表一份 TableSchema、一份 FormLayout、DbCategorySettings 一列、ProgramSettings 一列、MenuSettings 一項。前三項是新檔案，後三項各加一行。建表的程式也不必動，它照 DbCategorySettings 登錄的表逐一建立或升級。

定義那個層次也會出錯，而且不會有人報錯。明細的 discount 只宣告了型別、沒有給位數，於是它建成一個小數位數為零的欄位；案例用的 SQLite 會原樣保存小數，折扣又全部是零，所以從來沒踩到。

至於應用程式碼那個層次：八張表單裡七張是零行。ProgramSettings 上那七列只寫了 ProgId 與顯示名稱，代表整條流程走預設。

三、每一次呼叫都會跑的那些

下面這些事每一次呼叫都會發生，最後一欄是應用為它付出的：

另外有一組機制，案例用得很少：

• 沒有用到：業務外掛、權限模型、計量單位主檔，以及外掛設定的維護介面
• 接上了但只有一份：客製層、多語系與幣別主檔，案例仍然是一家公司、一份客製、一種幣別，譯文也只有訂單那一張

它們要等到「第二個」出現才划得來：第二家公司、第二種語言、第二個角色、第二種幣別。所以這一組不能算進「框架替應用省下的」，它們是這套設計比較貴的部分，在第二個出現以前，付出去的成本看起來像純粹的浪費。

四、手寫的程式剩下哪些

訂單那五件事

OrderBO 只覆寫了框架切出來的其中兩個步驟：取一筆新資料，以及存檔之前。後者長這樣：

protected override void DoBeforeSave(SaveContext context)
{
    base.DoBeforeSave(context);   // FormRule 與 ValueExpression 先在這裡跑完

    var dataSet = context.DataSet;
    var master = OrderDataSet.MasterRow(dataSet);

    OrderDataSet.RequireAtLeastOneDetail(dataSet);
    EnforceStatusRules(dataSet, master);
    AssignOrderNumber(master);
    OrderDataSet.ComputeTotal(dataSet);
}

這裡是四件，第五件在取新資料那一步：

從應用收斂到框架

表單自訂的邏輯與客製，會沿著同一條路往框架收：

應用外殼

伺服端除了訂單，其餘程式都在描述這個部署，跟表單無關：

• 多資料庫：程式裡只註冊資料庫驅動，案例用的是 SQLite。共用、公司、紀錄三個分類在 DatabaseSettings 各有一筆連線，目前都指向同一個檔案。要拆成不同資料庫只改這份設定，換一家資料庫再加上驅動的註冊，表單定義都不必動。
• 其餘：主機接線、開發用的跨來源設定、空的控制器子類、示範帳號，以及建表與塞示範資料。

前端那一側

前端同樣跟表單無關：

• 多前端：桌面、瀏覽器、iOS、Android 共用一個 UI 專案，各自只有幾行開機程式碼，宣告只走遠端、指定端點與金鑰存在哪裡。
• 透過 Connector 呼叫後端：表單要用的每一個動作都有對應的方法。送出時帶上 API 金鑰與登入拿到的令牌，內容先壓縮再加密；瀏覽器那一個拿不到加密用的金鑰，只做到壓縮。
• UI 專案裡沒有為某一張表單寫的檔案：裝表單的容器拿的是 ProgId，導覽清單從 MenuSettings 長出來。表單從八張變八十張，這一側不用改。

哪些地方是刻意不走定義的

• 真正的業務判斷：案例上只有狀態轉換一件
• 報表與批次的 SQL：多表 JOIN、彙總、動態條件、效能調校，硬套定義只會更複雜，框架給的是一條自己寫 Repository 的路
• 深度的畫面客製：FormLayout 描述的是欄位怎麼排，不是一個儀表板該長什麼樣

這幾塊是邊界，不是待辦。待辦是框架還沒做完的部分，例如訂單編號與跨列加總。

小結

八張表單裡七張是零行，應用外殼與前端都跟表單有幾張無關。

三個層次跟表單數量的關係各不相同。定義那個層次線性成長，而且它該這樣長，因為每一張表單本來就有自己的欄位、自己的關連、自己要顯示什麼。框架內建那個層次是常數，一次呼叫要做的事不會因為表單變多而變多。應用程式碼那個層次跟的是規則，不是表單：框架還沒接住的每一條，每一張用到它的表單都得寫一次，最後該留下的只有每一家各自不同的那幾條。

訂單那五件事裡，有四件遲早可以離開應用：訂單編號等框架收斂，至少一列明細與明細加總等定義能跨列計算，訂單日期那一行直接刪掉。狀態轉換會一直留下，因為每一家都不同。Day 3 結尾說的「只在真正需要判斷的地方寫」，在這個案例上指的就是它。

明天是最後一天，把三十天的東西收成全圖。

本系列同步發表於 HackMD，完整目錄