如何設計商務邏輯?

 

       軟體設計總是很難捉摸,設計雖然不一定決定軟體生死,但對軟體的開發週期起著非常重要的作用.那怎樣的設計能適應軟體的變更修改呢?針對我個人而言只能答不知道…因為我在設計的時候只針對現有存在的問題出發,但在後期軟體的變更所產生的東西總讓人不知所措.雖然設計很難,但有著豐富經驗的設計人員總會知道什麼時候應該幹些什麼,而他們的出發點往往不是考慮得非常周全,而是把代碼結構變得越簡單越好.業務變還是不變我們控制不了,但如何讓代碼在變更的情況可以方便維護和修改我們還是有一定的能力的.

       詳話就不多說了,最近似乎很多人談三層設計的問題;我來熱鬧一下,但我談的沒有這麼廣,緊緊是從商務邏輯設計上來說(細節決定成敗).

先看以下代碼吧:

public void Create(string username, string email) {

 

        }

 

        public void Create(User user) {

 

        }

其實兩個方法完成的功能都是一樣的,但兩者確有著不同之處.對於我個人而言後者對方法約定變更的風險比較低,因為User類提供資訊擴充的提供一些保障.是不是什麼情況都這樣幹呢,顯然下面的就沒有多大意義了.

        public bool Login(string username, string pwd) {

 

        }

 

        public bool Login(User user) {

 

        }

所以有一點我們可以緊記,程式是死的但人是活的.

以上是邏輯對外的,那邏輯內部呢?同樣的方法

    public void Create(string username, string pwd) {

            //insert username,userpwd

            //dal.call(username,userpwd)

        }

 

        public void Create(User user) {

            //DBContext.Add(user)

        }

以上代碼兩者的差別又在那裡呢,這就留給有興趣的朋友發言討論了

 

還有一個話題:我們如何知道做出來的東西能滿足以後的需要呢?如果能做到那唯一的可能就是業務的變化是按我們所假設的方向發展下來,但我們是不是永遠都這麼好運?如果我們的運氣不好那怎樣辦?這個時候估計只有簡單可維護的代碼才能把我們從井裡救出來…

 

這文章只是提個引子並不是想說這樣做設計才是對的,因為設計方法沒有最好只有更好.讓我們在不停的實踐中進步吧.