You are here

我为什么支持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,也有不好的一面。

 

论坛:

支持一下

我一边看老葛一边再改这个网站啊!布局瞬间变成两栏了。

半年前我是新手,到现在还是! 中间有好长时间没有学习drupal了,现在又来了,因为我看到drupal才是我应该坚持学下去了!

我是iOS程序员,我学习drupal更加偏重与services,不知道老葛有什么好的建议让我更快速地掌握。