問題描述

寫了個后臺管理頁， 用了簡單的單例模式。類似于

var xxx = { method1: function(){}, method2: function(){}, ...}

想問下有經驗的人， 寫類型于這樣的項目。要怎么組織代碼結構，才能更方便的拓展和維護。

問題解答

后臺管理，肯定涉及大量的增刪改查，可以手寫一個MVVM

一般設計模式都是針對程序的可維護性進行使用的，具體來講就是爭對一些容易發生變化的部分做預防性處理，以至于到后期的維護中不應該修改太多原代碼，特別是已經整合好邏輯的代碼。有了上面的認識，這時我們就可以想了，你的這個項目要用到大量的增刪改查，刪可能簡單點，不大可能會用到什么特別的設計模式。我們就先從增開始：

1.添加商品： 無外乎各種不同參數的添加和提示，我們至少可以確定未來一定會有變化的是新增商品時，商品具有的參數項目，就比如說我們最開始可能就一個商品名，一個庫存，一個文字介紹，一個幻燈片等等，但到后面天殺的產品經理說我們做的項目不夠清真，我界的修真用戶可能有更多需求，需要多加幾個填選項，如提供一個欄目用于客戶發布不同規格的商品時顯示的價格，或者添加一個欄目方便客戶在不同節假日時折扣價格的不同等等?？偠灾?，需求只會越提越多，不想在后面被這種鬼事情煩死，你就需要一個良好的設計模式來處理相關問題。這里我可以給你提供的一種模式就是中介者模式（可以盡可能避免模塊之間的耦合，新欄目的添加僅僅只需要將封裝好的模塊傳入到中介函數中即可，不用在乎其內部是怎么處理的，你所需要做的只是提供統一的接口），以后無論添加多少的參數填選都只需要完成相關的邏輯模塊就行。

2.還是添加商品：在上面的功能用了一段時間后，你家產品經理可能已經修成金丹，正想大展威風，剛好好死不死的你又被坑了進去，這次的需求可能是 “要根據不同的產品類型提供相應的參數填選功能”，就比如說 你電子產品類可能需要填詳細參數，而游戲點券又不用。這時我們可以用到的也是最常用的就是 “面向對象”，也叫模板方法模式，簡單來講就是繼承和重寫。 一個爸爸，一堆兒子，不含糊，該誰上就誰上。這種模式相對比較簡單。問題是在于代碼的復雜度可能會有點蛋疼。

3.修改商品： 其實大部分情況跟新增商品差不多，我們可能需要考慮的是某些特殊需求的時候。就比如說用戶現在正在修改商品信息，但是不希望提交后馬上生效，而且日后希望可以隨時手動控制相關信息的發布。這時你在頁面上提供了一個額外的按鈕，用于切換信息發布和信息保存兩種狀態，用于區別在兩種不同狀態下你對數據不同的處理辦法，甚至以后可能還會有定時發布等等。這時你可能需要用到策略模式或者是狀態模式，用于處理在不同策略或狀態下的行為方法。

4.查商品：最簡單的，添加不同的過濾器（如地區，類型，價格等等），跟第1點一樣?；蛘呤切枰獙σ呀涀x取到結果的某些數據內容進行一次查找，比如說匹配到“我欲修仙”這幾個關鍵字的產品進行顯示，其他去掉。因為你可能要對不同欄目的信息進行逐個匹配，這時你可以用到職責鏈模式。

總的來說，我列舉了一些比較常見的設計模式，但實際開發過程中遇到的問題會更多，就比如說： 你現在需要在新增商品的功能上進行一次更新，需求上在用戶每次添加新產品之前，要先做一個檢測，判斷用戶以前是否有填過類似的商品模板，有就提示用戶可直接套用，沒有則不提示。 但你也許似乎大概仿佛覺得自己快要渡劫了，因為這個模塊以前是你的同事負責的，你又不想讀他的源代碼，這時你可能需要用到裝飾者模式來更新相關的代碼。在保證功能正常的情況下盡量不去修改源代碼。。。。。這樣的例子很多很多，關鍵要對事來操作。至于是否要在項目開始前考慮這么多東西，我認為沒必要，因為你根本想不全，你想的和你實際上會碰到的有時候是有差距的，你只能選擇一些比較明顯的進行規避，就好像我給你寫了這么多，也僅僅只停留在某些比較明顯的部分，而且我到現在還沒寫過這一類項目，具體會碰到什么問題我也只能靠猜猜。 所以不要太糾結模式的問題，等什么時候回過神，就什么時候重構代碼， 這樣可能比較好一點。