职责一处在，莫占他人位

给客户设计了一些评估报表，几经修改，给出表样，交付开发。
 
这份报表上面显示的是每月评估指标值以及他们基于的度量值，当细分到区域时，还需要显示每个区域占总量的百分比。这是个非常简单的报表，没有多想，只是在表样上加上了"占比"列。
 
一段时间以后，看到开发人员做的报表，发现用了一种最直接的方法——将所有界面需要展现的数据都用一条SQL得到，"占比"当然也不例外，这就使的后台的SQL非常复杂。在我们目前的环境中，这当然不是明智的做法，已经有个很专业的报表工具，为什么要将这个可以用工具来处理的逻辑放到后台进行？
 
这是因为目前这个项目在架构方面缺位的缘故，因此开发人员来做这个决策时，如果经验不足，肯定会用一些奇怪的方法，只要能够满足要求就可以，哪里去管架构的合理性呢。而从纯粹架构的角度，这种前端只是将后台发来的数据做展示也是符合"数据与展现分离"的原则，去年，部门里面设计前端也是倾向于如此做法，这似乎是一个更容易理解和接受的设计思路，当然对于前端来说，也是一种看起来省事的设计。
 
可麻烦都集中到后台上去了，记得去年的一个应用，就是使用这样的前端，结果用异常复杂的SQL选取数据，诸如同比、环比这类都要在数据里面计算好，如果遇到趋时分析，还要将原来的纵表转成横表，这也太麻烦了吧。因此，这个应用最后可以说根本无法维护，也就无法去扩展，只要前端稍稍改动，比如加个字段，那些SQL就得重写。
 
其实这种架构是一种两层结构的，虽然符合"数据于展现分离"。而报表工具的角色，不光是充当展示的作用，其实还有处理指标计算逻辑的作用。不过对于一般自己开发前端的项目，因为时间紧迫，哪里顾得上去开发这个中间层？故此，也是不建议从头开发前端的做法，即使不买工具产品，也尽可用些相对成熟的开源产品嘛。
 
早先曾经谈过这个话题，观点很明确，那些已经有人做过的东西，如果你不想去和他竞争，就用他的，不要自己去搞一套。当然受到一群人的反驳，有认为对其他产品太过依赖的，还有觉得还是什么都自己干过瘾。

Nedea 20060420

潜水多年，看了这一贴，终于要说了。

我现在的这个项目已经作了3年了，报表100多个。其中大部分的报表都是在工具中查询、计算、展现（用法1），还有极少的一小部分由于当时纯粹用报表工具做，速度很慢，就采用庆哥今天声讨的方法，计算和大致的展现全部放在数据库中，最后报表工具展现的时候，就一条简单的查询就OK了（用法2）。

但是今年，噩耗传来（客户和项目组头头"密谋"得出的），"把以前所有的报表全部改掉，改用方法2，把计算结果全部放在数据库中"，还把这种架构叫做在数据集市上加一层"应用层"，本人当时就极力反对，但没用。

采用这种架构的弊端太多：

1、降低报表工具的作用，加大后台开发工作，还有无法预知的维护工作。

2、架构的混乱：由于一些少数的报表的数据展现受到输入信息的限制（简单的就是报表的查询条件），不得不采用用法1，根据输入信息即时地查出数据，再在报表工具中计算展现。这时就没有用到"应用层"。

3、我反对的直接原因。100多个有的改了，有的还要重新整理报表的业务逻辑，这么大的修改工程不知需要多少人月啊，不排除这个修改工程会停止，乃至失败

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友