[轉載] Dynamics 365 Business Central開發實戰-2:為何要用Extensions和VSCode來進行開發

<< 以下為轉載文章。。。>>

2019/6/9
在上一篇文章中,我們已經把需求 (規格) 的第 1–4 項做掉。也許你覺得非常簡單,不過就是加加欄位;也許你覺得要熟悉這個 Framework 需要時間,例如 Page Action 或是各種 Properties (如上一篇有設定的 Table relation) 的運作方式。在我們繼續客製下去之前,我們要來討論兩個議題。

第一個議題有關於新一代的客製方法論 Extensions。還記得我們的 Business Central 開發原則第一條:”能不客製就不客製” 嗎? 客製其實是有負擔的,而這個負擔最明顯的會是在我們要將系統升級時。想像我們現在是用 Business Central 2019 Spring 的版本來做客製。原本系統標準的程式碼假設有十萬行好了。這時候,我們東加一行西加一行,或是像前面前篇一樣在既有的 Table 或是 Page 上面加欄位。直到 2020 年秋季,客戶想要升級成最新的 Business Central。但是這時標準的程式碼可能已經跟以前不同、標準的功能變多了、或是總共已經有了十一萬行程式碼了,怎麼辦?這時我們就要做 Code merge。以最新版本的 Business Central 做為基底,然後把我們所做的客製一個一個加上去。
可想而知,當一個系統重度客製時,要這樣將動到標準物件的客製程式碼搬過去然後再做系統測試,非常的麻煩耗時。反而是我們之前新加的 Table 50000, Page 50000 這種新物件,直接搬過去就好了!反正他也沒有所謂的 “新版標準物件” 會跟他衝突。Extensions 就是在這個情況下被提出的解決方案。想要在標準的 Table “G/L Account” 加欄位嗎,沒問題,你就做一個新物件 “Table Extension” 50000 就好了!這個 Table Extension 在定義時我們就定義它擴展 (Extends) 了 Table “G/L Account”。所有要在 “G/L Account” 新加的欄位都放在這個 Table Extension 50000 中,而系統編譯 (Compile) 時會自動將 Table “G/L Account” 和 Table Extension 50000 連結在一起。當然,Page 的概念也是一樣,會有一種 Page Extension 的物件,你可以在裡面放入想呈現的客製欄位,或是新的 Page Action。最棒的是,在升級時,我們只要把這些 Table Extensions, Page Extensions 通通打成一包,掛載到開發環境中就可以了!

Page Extension 中加入客製 Page Action

第二個議題我們來討論有關於 CSIDE 裡面過多使用 “Properties” 來做開發的方式。即除了程式碼之外,魔鬼常常藏在某個物件、某個欄位的 Properties 中。這種開發模式除了讓程式設計師不好在既有的客製上繼續開發之外,也讓人不好 Debug。筆者一開始接觸 CSIDE 時,非常不習慣要到 C/AL Globals 或是 C/AL Locals 去定義變數。為什麼一定要藏起來呢,不能像 C++ 一樣直接定義 int x = 5; 嗎?以當今程式開發的潮流,程式碼的呈現要易於協作、閱讀,或是放在 Github 做版本控管;而在強大的 Code Editor,如 VSCode 的輔助之下,也使這種文本式的開發模式變得更有效率。如果有接觸過 Web 開發的程式設計師,不妨想像我們放棄以前在 Dreamweaver 上拉一拉讓它產生 HTML 和 CSS,而是現在的直接在 Sublime Text 上(或是任何你喜歡的 Code Editor) 硬幹程式碼。

在 VSCode 上直接利用 AL 語言開發 Business Central 的 Extensions。也可以藉它他的開發環境直接連結 Github 做版本控管
在下一篇文章中,我們會繼續在 CSIDE 中完成 5~8 項的客製,也將會觸及到 Business Central 最重要的開發觀念:Event-driven, Publishers, Subscribers 的設計模式。
*********************************************************************************
<< 以上文章,經作者 Ray 同意,轉載自 https://medium.com/@nturay0321 >>

發佈留言