我为什么支持Ubercart，而不是Commerce

身边的很多Drupal开发者，都转投Commerce阵营了，很多人问我，或者告诉我，Commerce是未来的趋势，我怎么看这个问题。

Commerce是很不错，在两者之间进行选择的时候，我犹豫过很久，但是我最终选择了Ubercart，这是有很多原因的。

Commerce的源代码，早期的版本，我从头到尾的读过一遍，Ryan Szrama关于Commerce的早期文章，架构、原理，我也都读过，Ryan Szrama在Drupal社区，也是我极推崇的一个开发者，但是我为什么没有追随Commerce而去呢？

Commerce在多个方面，对Drupal6版的Ubercart做了改进，采用了最新的Entity API，完整的测试代码，相当多的文档，还有commerce guys这样背后的一个商业公司作为支持；Acuqa，Lullabot在他们的文章中，对Commerce做了大力推广。实际上，从Drupal7出来以后，Commerce的推广力度远远大于Ubercart。

这些，我们都会看到，相反支持Ubercart的声音，在整体的全球社区，在中国的Drupal社区，都是弱于Commerce的。在这种情况下，很多人倒向Commerce，这是再正常不过的事情了。为什么我还这么坚定的支持Ubercart？

首先，我们看到，Commerce和Ubercart两者之间，最重大的一个区别，那就是产品的处理方式不同，在Commerce里面，产品是一个实体类型；在Ubercart里面，它是附加到内容类型上的。很多人认为，Commerce做的好，这是有道理的，也有很多人认为，Commerce这方面做过了头，我就是持后面的这种态度。比如对于一本图书，在Commerce上面，我需要创建一个图书内容类型，同时需要创建一个图书产品类型，然后将图书这个产品类型，通过实体引用关联到图书内容类型上来，这个时候，问题就出来了，我到底是将字段添加到图书产品类型上去呢，还是添加到图书内容类型上面去？Commerce开发了entity inline form模块，很好的改进了这类问题，但是我认为，他并没有从根本上解决这个问题。一本图书，当你拿到手中阅读的时候，它是商品吗？它不是商品，只有当你从书店里面购买它的时候，它才是商品，从经济学，从自然的角度出发，只有当图书具有价格这个属性，可以被用来销售时，它才是商品。因此，我的理解是这样的，当一个实体具有价格属性的时候，就是商品；这与Commerce里面默认的，商品本身就是一种实体，而且可以有不同的商品类型；这是两种不同的思想，我认为，我的想法更接近于Ubercart。

Drupal7下，是否完全采用Entity API，不是一个模块好坏的唯一标准。尽管在Drupal8里面，Entity API进入了内容，所有的东西都在向Entity Field API转换。但是，我们不能在Drupal7下，认为一个东西，完全采用了Entity Field API，就比那些不采用的好。首先，Drupal核心，就没有完全采用Entity，比如说区块，联系表单。很多第三方模块，有的采用了，有的部分采用了。Commerce完全采用，Ubercart部分采用了。完全采用，有完全采用的好处，好处有哪些呢？操作一个字段的值的时候方便了很多，Entity API做了封装；有哪些坏处呢？就是说，在性能上有所牺牲，跑的慢了一点了。Commerce的说明上说，扩展性强，我要补充一点，性能上有所牺牲，这是很多资深的开发者，都知道的事情。

Commerce完全采用了Views，包括购物车页面，也是用Views做的，Commerce的结算页面，也比Ubercart改进了很多。首先，Ubercart的购物车，同样可以基于Views实现，结算页面的改进，Ubercart同样能够完成Commerce的效果，没有人阻止Ubercart的社区的人做这件事情。

说到购物车，在Commerce里面，购物车里面的内容，就已经属于订单了，这是对Ubercart的一个改进。但是我并不看好这个设计，这样将会在一个实际的站点生成很多的订单，只要用户放在购物车里面，就生成一个订单，向购物车里面添加商品的人很多，结算的人不多；在一个商场里面，你推着购物车，里面装满了商品，但是你突然接到一个紧急的电话，跑了出去，回家了。现在，购物车里面的商品，是属于一个订单么？显然这是不成立的，Commerce这样做，是为了程序上的方便，但是过于理想，没有考虑实际情况，淘宝、京东、当当，我没有见过哪个大一点的网上商店，是采用的这种模式。

Commerce的安装量远超Ubercart了？如果你看Drupal7下面的安装量，尽管Commerce的安装量，整体没有Ubercart多，但是在Drupal7下面，已经远超Ubercart。我想说的是，你看到的这些是事实，没错，但是你还需要看到一点，commerce_kickstart的安装量，就有快9000了，这是一个发行版，卖衣服的。我不认为，地球上，有8600+多个网站在使用Drupal卖衣服，我认为里面的95%的站点，就是一个Demo站点，很多人只是把commerce_kickstart装了起来，去掉了Logo，换成自己的，然后向客户说，这是他搭建的，借此拿项目做罢了，但是真的拿到大的项目的时候，大部分都是搞不定的。Commerce比Ubercart多出来的安装量，是有泡沫的，扣除这些泡沫，两者依然是旗鼓相当的局面。毕竟，基于commerce_kickstart去做一个网站，比基于一个纯Drupal从头搭建起来，更麻烦，除非他要的就是一个卖衣服的网站。

Commerce guys的目标，就是在Drupal的社区，只有一个电子商务模块；我们都知道这个目标。如果只有一个电子商务模块，如果只有了Commerce以后，那会怎么样呢？没有了竞争，没有了改进的动力，剩下的只有商业利益。Commerce guys并没有将它们在Ubercart上面的所有成果贡献给Ubercart社区，他们做了保留，同样，他们为了自己的利益，同样会在Commerce的开发过程中，做些保留。

Commerce Guys的员工，是从自己的工作时间挤出那么一些来维护相关模块的；而我看到的Ubercart的当前维护者，牺牲了自己大量的周末，休假的时间，来维护改进Ubercart；Ubercart向Drupal8的升级，从2013年初就开始了，而Commerce向Drupal8的升级，到现在还没有动静。当我得知，longwave，在2013年初，就开始升级Ubercart到Drupal8的时候，我看到了希望，我看到了Drupal8下，Ubercart仍然会继续发展。Commerce社区的人，也有人提出到Drupal8的升级，commerce的官方回答是，这个将会从2014年3、4月份才会开始。Commerce是一个兔子，在Drupal7下，跑的很远，Ubercart是一个乌龟，改进的速度慢，但是一直没有听过。

很早以前，我写过支持Ubercart的文章，现在写一篇。期间，我们对Ubercart做了一些改进工作，比如Ubercart3.5的完整汉化，升级了网银在线、银联在线等支付模块。到目前为止，Ubercart的中文化，做的是比Commerce好的，支付模块也比Commerce多，支付宝、财富通、银联在线、网银在线、邮政的在线支付等等。如果你在用Commerce搭建一个电子商务站点的话，如果你迟迟搞不定的情况下，建议你尝试一下Ubercart，这个中文文档更多，支付模块、运费模块更多，当然也更简单易用。

Lullabot的drupalize改版，他们在Drupal6下面，用的是Ubercart，升级到了Drupal7。在Drupal7下，他们不再采用Ubercart了；但是他们同样没有采用Commerce。Lullabot的人，不看好Ubercart，他们在升级的时候，同样没有采用Commerce，他们这个网站也是提供销售功能的，搭建的时候，肯定考虑过Commerce，但是他们也没有采用。他们肯定看到了Commerce，也有不好的一面。