Ecshop Analysis

总体结论

  • ECShop是一个覆盖流程较广,但实现简单的电子商务系统。

技术方面

开发

关于框架

  • ECShop的模板系统是基于修改过的smarty。
  • ECShop的Front Controller层没有清晰地从Model层中分离出来,所以flow的控制是由php页面实现的。
  • 画面跳转逻辑较清晰,分为传统的smarty和json。其中smarty页面上产生的更新操作会在更新页上显示更新结果后再跳转回显示页面。
  • 实现复杂逻辑的页面,往往由多个if-then-else拼接而成,没有进一步分割模块。
  • ECShop的Database Access层没有从清晰地Business Logic层中分离出来。
  • 原始的ECShop源码可能是用基于过程的方式实现的,所以数据访问的部件(db sqls)混在于整个系统。

关于编程策略

  • 面向对象的类是作为函数的包存在,而没有起到面向对象的足够作用。
  • 在源码中带有不少注释,只是注释的方式和范围并没有明确的定义,导致有些地方有注释但是同级的其他地方却没有注释,有些注释是正着说有些注释是反着说。
  • 命名规约不明显
  • 类型约定并不清晰,使得代码中存在大量类型及有无检测
  • 大量重复代码没有抽出成公共库
  • 大量重复代码如果是面向对象模式开发,可作为对象自身维护的一部分,而不需使用的程序员考虑

关于实现细节

  • serialize和unserialize的运用使得ECShop使用简单的表结构就可以完成复杂的逻辑,而且相对灵活性强。但是另一方面由于没有数据库的支持,一些操作的代码繁复。特别是在没有OO或公共函数库的支持的情况下,重复的代码有诸多问题。

运维

  • 系统是一体化的,所以不需要外部系统参照。
  • 需要考虑代码体系。
  • 有csv upload处理,但是基于数据库的批量处理薄弱。

业务方面

购物

商品展现

活动促销

优惠活动提供以下几种模式:

  • 品牌优惠
  • 类别优惠
  • 商品优惠
  • 套餐折扣
  • 赠送礼品和附属品
  • 会员价

多种的优惠提高了销售的灵活性,但是也使系统在所有的价格商品相关的部分重复判断:优惠是否可用,总价是否变化等。

库存管理

库存虽然可以enable/disable,但是没有独立成为模块,所以库存代码也是在各个页面中作为一种分支结构存在。

用户体验

可以考虑的改进

  • 添加controller,把原有的各个page作为一个controller的中转页,添加参数以便符合新controller的要求,并且对于action, function分割具体的处理model。
  • 分割model和business layer,将business分割成组件,剔除重复代码。
  • 添加db access layer。把sql集中到一起;并且使用bind方式访问;返回值尽量成为db映射出的map object,而非每次sql的特殊数组。
  • 传输参数和数据规定object类型,不随意传送随意生成的数组对象。
  • template也封装成和model对应的组件。