标签:
看过我文章的网友们都知道,通常前言都是我用来打酱油扯点闲情的。
自从写了上面一篇文章之后,领导就找我谈话了,怕我有什么想不开。
所以上一篇的(下)篇,目前先不出来了,哪天我异地二次回忆的时候,再分享分享。
话说最近外面IT行情飞涨还咋的,人都飞哪去了呢,听说各地的军情都进入紧急状态了。
回归下正题,今天就抽点时间,写写技术文,和大伙分享一下近年在框架设计上的取的一些技术成果。
在针对运营商(移动、联通、电信、铁塔)的信息类的系统中,由于相关的从业人员习惯于Excel的办公思维。
导致在做该类系统中时,Excel的导入导出功能,几乎成了每个有列表展示的页面上必备功能。
因此,有必要对Excel导入导出进行抽象并组件化设计,以至于后面占了整个开发框架中一个很牛B的位置。
而这一切的演进与进化,始于以下这越来越变态的需求:
我们都知道,要把一批数据导进系统中,最基本的做法,就是约定好导入的模板,然后针对精心设计好的模板进行编码。
而客户则按格式填写好数据后,如无意外的就导入系统中了。
如此如此这般这般之后:
对于开发:会选择一种最简单开发的方式,尽量确保每个字段不需要特殊处理都和数据库对的上,不用做过多的额外代码编写。
对于客户:需要按指定的格式填写数据,需要花不少时间。
后续的调研进展,客户要亲自指定模板中的列及格式。
如此如此这般这般之后:对于开发:需要按指定的格式去开发,甚至可能缺少某些列,要做一些额外的查询或代码处理。
对于客户:可以简单的从其它办公的Excel中复制数据到模板,进行简单的修改后导入。
客户越来越牛B了,认为搞模板这东西太复杂了,既然其它系统能导出来,直接弄过去就得了。
如此如此这般这般之后:
对于开发:由于某系统导出的Excel数据,乱七杂八,用API读出来的数据,不符常规则,要做N多兼容处理,工作量翻了N翻。
对于客户:从其它系统导出Excel数据,直接导进系统,真泥玛的省心。
客户已经超越牛A与C之间了,哥穿越七八张表,用了N个Case和GroupBy及N层子嵌套才弄出来的报表数据,你要给导回基础表去?
如此如此这般这般之后:
对于开发:45度仰角呼唤你爷。
对于客户:我只要某几个字段改了能回去就行。
好简单的说,使用 CYQ.Data 框架(好久没在文章中介绍了,历经几年低调的发展,有机会再写文)中MDataTable的批量功能,一行代码就完事了。
麻烦开始了,两张表就算了,可是你来2,3,4,5,6,7表,一个导入要关联这么多表,还得理解业务,还要分拆一对N关系,一个导入要整好几天。
如果回头客户说改模板,心里瞬时多了几草泥马穿过。。。
又麻烦了,合并的单元头、卧槽还有同名的列头,难道要写死指定第N行的列头就A表名字,N+N行的列头是B表的名字?
如果模板增加字段,换了位置, 心里莫名又多了几只草泥马越过。。。。
模板的上面十几行,是一大堆没用的数据,模板的左边和下面,是一些填写的说明(而这些,是其它系统的数据,跟我们做的系统有毛关系啊,但客户就是这么牛B)
所以,又要增加处理,从第几行读数据,列头跨几个行,右边第N行是无效的,心里刹间又多了几只草泥马踩过。。。
模板增加一个分类列就可以搞定的事,客户打死也不要,非要一个分类一个Sheet,然后全部导入。
所以,你得按Sheet名称自动转换成分类名称,来处理这些事。
还有原来一个Sheet多表的一对N关系,要分拆到N个Sheet里去让你处理导入, 心里哗哗已无数只草泥马踏过。。。
在正常的需求阶段,理论上是应该引导用户规避掉一些不合理的设计,但现实有时候就是被客户牵着走。。。
因此,在面对如此这么复杂的场景和变态要求下,如果不设计一套智能组件,则开发成本和开发人员无疑将陷入无限的悲哀中。
好在,我在。
下一文,将与大伙分享Excel的组件化的设计方案
标签:
原文地址:http://www.cnblogs.com/cyq1162/p/4510710.html