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