电子商务网站,前后台是否该分离?

awai 2011-08-21

做电子商务网站,一般都涉及到前后台,前台是给用户用的(营销+销售系统),后台给公司员工用的(业务支撑系统)。

在项目开发初期,技术负责人往往倾向于,将它们混在一起。我曾经也是这样,但问题在后期就慢慢凸显了。

我曾经写过电子商务网站和企业应用开发的区别(12),和这个一起看,应该会比较好理解我的观点。

一、从系统部署的角度考虑

在项目开发阶段,因为基本上很少涉及部署(迁移到产品环境),所以部署问题目前没有凸显。

当网站上线后,在网站运营阶段(即系统维护阶段),特别是运营一个月后,部署的效率和稳定性,会越来越影响到网站的需求响应性(解决一个网站bug的速度)。

三年前,我开发公司网站时,也是将前后台合并到一个工程,最后还是不得不分离,只通过数据库作为前后台的桥梁。因为你不知道调整一个前台小功能,是否会影响后台(回归测试?);你也不知道前台部署好后,后台是否会受到影响。

网站上线后,前台需求的变更还是很频繁(改进用户体验),因为绝大多数时候是改变页面展现,并不需要后台做相应变更。把后台代码重新部署一遍只会带来隐患。

网站重新部署,一般是选择凌晨6点左右。而后台部署,只要不是在白天工作时间就行了。

网站前台对性能要求很高,系统很可能会因为这个重构。但后台系统,用户数量很少,几乎没有性能要求。

顺便说一下,系统会有大量的Job,如统计、价格更新,这类模块建议不要和Web一起,应该单独部署。

二、从软件过程角度

因为网站前台和后台业务系统,面向的是完全不同的两类用户(消费者和企业员工),它们的需求和需求获取过程完全不同。

对于前台,界面原型即需求,页面/用户行为驱动开发。对于后台,是数据和流程驱动开发:Table+Form+Flow。

也就是说,前台和后台,是两种需求分析和设计人员,甚至是两种设计师(后台的界面不要求美观,很死板,但前台对设计师要求很高),再或者是两种开发人员(如前台PHP,后台Flex+Java)。

公司业务人员很容易理清后台业务,但对前台用户的心理和行为的分析,一般都不能胜任。这也是为什么我要将网站需求分析和设计的工作全部包揽。

三年前,我也是让业务人员设计网站模块,一塌糊涂。最后还是我自己设计全部界面原型,只需要征求业务人员的意见,他们不写任何文档。

面向互联网用户的软件开发方法学,和面向企业用户的开发方法学,有着天壤之别。但目前项目组是用同一种模式(企业应用开发过程),这是很危险和低效的。目前在行业里还没有成熟的互联网软件开发方法学,只有做过两类开发,才能总结出经验和教训。

三、从软件开发角度

如果说选择将前后台合并,是因为代码重用。那么重用的也只是一些简单的Domain(pojo),如Book类。但对于后台,用到Book类,是比较纯粹的Book(如图书管理),但里面却夹杂着大量的无关的、前台用到的属性,如评分、用户留言、评价、相关图书、其它用户购买过的图书等等,导致后台维护起来非常困难。

像用户收藏夹,这一很复杂的核心功能,和后台业务系统几乎没有关系。

如果说前后台只是重用最简单的Domain,那这种技术层面的重用又有多大价值呢?像图书查询,前台和后台的业务逻辑、复杂度完全不是一个级别(前台更复杂),没有任何的重用性。

前台几乎都是数据展现(无状态操作),后台主要是数据操作。也就是说,你前台大量的代码都是查询,和后台的写入几乎没关系,不存在重用性。

像基础代码库,如用户性别、仓库城市等,主要是后台,前台只是用到其中非常小一个子集,完全可以复制方式。

另外,前台不建议用Hibernate,因为它的优势在数据持久化,也就是增删改查的“增删改”,对于查(List+Detail),还是原生sql便捷,不拖泥带水。

我上面只是抛砖引玉,很想听听大家的意见,想必很多人在互联网公司做应用开发,你们或你们公司大牛是如何处理这个问题的?

(广告)如果你对大型电子商务系统的设计和开发,有浓厚的兴趣,不妨看看这里。

相关推荐