写了个后台管理页， 用了简单的单例模式。类似于
var xxx = { method1: function(){}, method2: function(){}, ... }
想问下有经验的人， 写类型于这样的项目。要怎么组织代码结构，才能更方便的拓展和维护。
后台管理，肯定涉及大量的增删改查，可以手写一个MVVM
一般设计模式都是针对程序的可维护性进行使用的，具体来讲就是争对一些容易发生变化的部分做预防性处理，以至于到后期的维护中不应该修改太多原代码，特别是已经整合好逻辑的代码。有了上面的认识，这时我们就可以想了，你的这个项目要用到大量的增删改查，删可能简单点，不大可能会用到什么特别的设计模式。我们就先从增开始：
1.添加商品： 无外乎各种不同参数的添加和提示，我们至少可以确定未来一定会有变化的是新增商品时，商品具有的参数项目，就比如说我们最开始可能就一个商品名，一个库存，一个文字介绍，一个幻灯片等等，但到后面天杀的产品经理说我们做的项目不够清真，我界的修真用户可能有更多需求，需要多加几个填选项，如提供一个栏目用于客户发布不同规格的商品时显示的价格，或者添加一个栏目方便客户在不同节假日时折扣价格的不同等等。总而言之，需求只会越提越多，不想在后面被这种鬼事情烦死，你就需要一个良好的设计模式来处理相关问题。这里我可以给你提供的一种模式就是中介者模式（可以尽可能避免模块之间的耦合，新栏目的添加仅仅只需要将封装好的模块传入到中介函数中即可，不用在乎其内部是怎么处理的，你所需要做的只是提供统一的接口），以后无论添加多少的参数填选都只需要完成相关的逻辑模块就行。
2.还是添加商品：在上面的功能用了一段时间后，你家产品经理可能已经修成金丹，正想大展威风，刚好好死不死的你又被坑了进去，这次的需求可能是 “要根据不同的产品类型提供相应的参数填选功能”，就比如说 你电子产品类可能需要填详细参数，而游戏点券又不用。这时我们可以用到的也是最常用的就是 “面向对象”，也叫模板方法模式，简单来讲就是继承和重写。 一个爸爸，一堆儿子，不含糊，该谁上就谁上。这种模式相对比较简单。问题是在于代码的复杂度可能会有点蛋疼。
3.修改商品： 其实大部分情况跟新增商品差不多，我们可能需要考虑的是某些特殊需求的时候。就比如说用户现在正在修改商品信息，但是不希望提交后马上生效，而且日后希望可以随时手动控制相关信息的发布。这时你在页面上提供了一个额外的按钮，用于切换信息发布和信息保存两种状态，用于区别在两种不同状态下你对数据不同的处理办法，甚至以后可能还会有定时发布等等。这时你可能需要用到策略模式或者是状态模式，用于处理在不同策略或状态下的行为方法。
4.查商品：最简单的，添加不同的过滤器（如地区，类型，价格等等），跟第1点一样。或者是需要对已经读取到结果的某些数据内容进行一次查找，比如说匹配到“我欲修仙”这几个关键字的产品进行显示，其他去掉。因为你可能要对不同栏目的信息进行逐个匹配，这时你可以用到职责链模式。
总的来说，我列举了一些比较常见的设计模式，但实际开发过程中遇到的问题会更多，就比如说： 你现在需要在新增商品的功能上进行一次更新，需求上在用户每次添加新产品之前，要先做一个检测，判断用户以前是否有填过类似的商品模板，有就提示用户可直接套用，没有则不提示。 但你也许似乎大概仿佛觉得自己快要渡劫了，因为这个模块以前是你的同事负责的，你又不想读他的源代码，这时你可能需要用到装饰者模式来更新相关的代码。在保证功能正常的情况下尽量不去修改源代码。。。。。这样的例子很多很多，关键要对事来操作。至于是否要在项目开始前考虑这么多东西，我认为没必要，因为你根本想不全，你想的和你实际上会碰到的有时候是有差距的，你只能选择一些比较明显的进行规避，就好像我给你写了这么多，也仅仅只停留在某些比较明显的部分，而且我到现在还没写过这一类项目，具体会碰到什么问题我也只能靠猜猜。 所以不要太纠结模式的问题，等什么时候回过神，就什么时候重构代码， 这样可能比较好一点。
后台管理，肯定涉及大量的增删改查，可以手写一个MVVM
一般设计模式都是针对程序的可维护性进行使用的，具体来讲就是争对一些容易发生变化的部分做预防性处理，以至于到后期的维护中不应该修改太多原代码，特别是已经整合好逻辑的代码。有了上面的认识，这时我们就可以想了，你的这个项目要用到大量的增删改查，删可能简单点，不大可能会用到什么特别的设计模式。我们就先从增开始：
1.添加商品： 无外乎各种不同参数的添加和提示，我们至少可以确定未来一定会有变化的是新增商品时，商品具有的参数项目，就比如说我们最开始可能就一个商品名，一个库存，一个文字介绍，一个幻灯片等等，但到后面天杀的产品经理说我们做的项目不够清真，我界的修真用户可能有更多需求，需要多加几个填选项，如提供一个栏目用于客户发布不同规格的商品时显示的价格，或者添加一个栏目方便客户在不同节假日时折扣价格的不同等等。总而言之，需求只会越提越多，不想在后面被这种鬼事情烦死，你就需要一个良好的设计模式来处理相关问题。这里我可以给你提供的一种模式就是中介者模式（可以尽可能避免模块之间的耦合，新栏目的添加仅仅只需要将封装好的模块传入到中介函数中即可，不用在乎其内部是怎么处理的，你所需要做的只是提供统一的接口），以后无论添加多少的参数填选都只需要完成相关的逻辑模块就行。
2.还是添加商品：在上面的功能用了一段时间后，你家产品经理可能已经修成金丹，正想大展威风，刚好好死不死的你又被坑了进去，这次的需求可能是 “要根据不同的产品类型提供相应的参数填选功能”，就比如说 你电子产品类可能需要填详细参数，而游戏点券又不用。这时我们可以用到的也是最常用的就是 “面向对象”，也叫模板方法模式，简单来讲就是继承和重写。 一个爸爸，一堆儿子，不含糊，该谁上就谁上。这种模式相对比较简单。问题是在于代码的复杂度可能会有点蛋疼。
3.修改商品： 其实大部分情况跟新增商品差不多，我们可能需要考虑的是某些特殊需求的时候。就比如说用户现在正在修改商品信息，但是不希望提交后马上生效，而且日后希望可以随时手动控制相关信息的发布。这时你在页面上提供了一个额外的按钮，用于切换信息发布和信息保存两种状态，用于区别在两种不同状态下你对数据不同的处理办法，甚至以后可能还会有定时发布等等。这时你可能需要用到策略模式或者是状态模式，用于处理在不同策略或状态下的行为方法。
4.查商品：最简单的，添加不同的过滤器（如地区，类型，价格等等），跟第1点一样。或者是需要对已经读取到结果的某些数据内容进行一次查找，比如说匹配到“我欲修仙”这几个关键字的产品进行显示，其他去掉。因为你可能要对不同栏目的信息进行逐个匹配，这时你可以用到职责链模式。
总的来说，我列举了一些比较常见的设计模式，但实际开发过程中遇到的问题会更多，就比如说： 你现在需要在新增商品的功能上进行一次更新，需求上在用户每次添加新产品之前，要先做一个检测，判断用户以前是否有填过类似的商品模板，有就提示用户可直接套用，没有则不提示。 但你也许似乎大概仿佛觉得自己快要渡劫了，因为这个模块以前是你的同事负责的，你又不想读他的源代码，这时你可能需要用到装饰者模式来更新相关的代码。在保证功能正常的情况下尽量不去修改源代码。。。。。这样的例子很多很多，关键要对事来操作。至于是否要在项目开始前考虑这么多东西，我认为没必要，因为你根本想不全，你想的和你实际上会碰到的有时候是有差距的，你只能选择一些比较明显的进行规避，就好像我给你写了这么多，也仅仅只停留在某些比较明显的部分，而且我到现在还没写过这一类项目，具体会碰到什么问题我也只能靠猜猜。 所以不要太纠结模式的问题，等什么时候回过神，就什么时候重构代码， 这样可能比较好一点。