ERP 的複雜度不在單一功能有多難,而在同一件事被重述太多次、乘以太多張表、再乘以太多次客製。
這個系列談的不是怎麼用框架做一張表單,而是怎麼設計一套能驅動上百張表單的框架:唯一真相放在定義而非程式碼,資料庫結構、SQL、多前端畫面、驗證與計算、多語系、多租戶與客製化都從同一層定義衍生。
三十篇分八章,從為什麼談起,依序走過定義層、資料存取與快取、業務邏輯與 API、多租戶與客製化、傳輸安全與稽核、資料語意,最後回到案例對帳與全圖。案例用 Northwind 驗證,但案例是佐證,不是主角。
談機制與取捨,不寫使用教學;每個設計的代價會跟它的好處寫得一樣清楚。
Day 5 劃過定義驅動那條路的邊界:跨表關連一律單欄位等值、接的一定是實體資料表。報表、統計、批次匯入超出這個範圍,SQL 就自己寫,任何框架都得留這條路。...
打開一張表單,框架要讀的定義不只一份:FormSchema、TableSchema、FormLayout、ProgramSettings、LanguageRe...
ERP 系統的每一次請求都要先回答兩件事:誰在呼叫、他在哪一家公司。框架若不統一管理,這兩個問題會長進每一段業務邏輯的開頭,變成到處複製的樣板程式碼。 框架的...
定義表達得了的行為,一行程式都不必寫。表達不了的那些才需要接手:這張單據送出前要檢查什麼、存完之後要通知誰、刪除前什麼情況不准刪。框架給的接手方式是繼承業務物...
昨天談的擴充點,全部掛在某一個具體的 Business Object 上。往前推一步的問題是:一個呼叫進到後端,框架怎麼知道要建哪一個型別、那個型別收到的參數...
昨天談的是一個呼叫進來之後,框架怎麼知道要建哪一個型別。再往前推一格的問題是:這個呼叫本身長什麼樣子。一套上千張表單的系統對外要開出的方法數以千計,而其中絕大...
昨天談的是一次呼叫送進伺服端之後怎麼被處理。同一份合約在呼叫端這一側也得有人負責:有的呼叫端連的是網路另一頭的伺服器,有的跑在後端邏輯的同一個行程裡,兩邊要呼...
一次呼叫失敗分兩種。一種是業務規則正常擋下來的,訂單沒有選客戶、狀態不允許這樣轉,這段訊息是寫給使用者看的;另一種是程式沒有預期到的例外,訊息裡可能有伺服器的...
一套 ERP 幾乎不存在裝了就用這回事。同一套定義交付給三家公司,這家要把「客戶」叫成「經銷商」,那家的訂單畫面要少三個欄位,還有一家存檔前要多一道信用額度檢...
一套系統賣到多個地區,欄位標題、表單名稱、下拉選項的文字都要跟著語言換。這是做過國際化的人都處理過的題目,而 .NET 的標準答案是 .resx:字串放進資源...