Excel导入导出的业务进化场景及组件化的设计方案（上）

1：前言

看过我文章的网友们都知道，通常前言都是我用来打酱油扯点闲情的。

自从写了上面一篇文章之后，领导就找我谈话了，怕我有什么想不开。

所以上一篇的（下）篇，目前先不出来了，哪天我异地二次回忆的时候，再分享分享。 

话说最近外面IT行情飞涨还咋的，人都飞哪去了呢，听说各地的军情都进入紧急状态了。 

 

回归下正题，今天就抽点时间，写写技术文，和大伙分享一下近年在框架设计上的取的一些技术成果。

2：项目背景

在针对运营商（移动、联通、电信、铁塔）的信息类的系统中，由于相关的从业人员习惯于Excel的办公思维。

导致在做该类系统中时，Excel的导入导出功能，几乎成了每个有列表展示的页面上必备功能。

因此，有必要对Excel导入导出进行抽象并组件化设计，以至于后面占了整个开发框架中一个很牛B的位置。

 

而这一切的演进与进化，始于以下这越来越变态的需求：

3：从模板的指定方式看进化 

 

阶段一：由开发方精心设计Excel模板

我们都知道，要把一批数据导进系统中，最基本的做法，就是约定好导入的模板，然后针对精心设计好的模板进行编码。

而客户则按格式填写好数据后，如无意外的就导入系统中了。

如此如此这般这般之后：

对于开发：会选择一种最简单开发的方式，尽量确保每个字段不需要特殊处理都和数据库对的上，不用做过多的额外代码编写。

对于客户：需要按指定的格式填写数据，需要花不少时间。 

 

阶段二：Excel模板的格式由客户指定

后续的调研进展，客户要亲自指定模板中的列及格式。

如此如此这般这般之后：

对于开发：需要按指定的格式去开发，甚至可能缺少某些列，要做一些额外的查询或代码处理。 

对于客户：可以简单的从其它办公的Excel中复制数据到模板，进行简单的修改后导入。 

 

阶段三：从某系统导出Excel数据，要求能直接导入系统

客户越来越牛B了，认为搞模板这东西太复杂了，既然其它系统能导出来，直接弄过去就得了。

如此如此这般这般之后：

对于开发：由于某系统导出的Excel数据，乱七杂八，用API读出来的数据，不符常规则，要做N多兼容处理，工作量翻了N翻。

对于客户：从其它系统导出Excel数据，直接导进系统，真泥玛的省心。

 

阶段四：要求系统中导出的Excel数据列表，修改数据后可以直接导入系统

客户已经超越牛A与C之间了，哥穿越七八张表，用了N个Case和GroupBy及N层子嵌套才弄出来的报表数据，你要给导回基础表去？

如此如此这般这般之后：

对于开发：45度仰角呼唤你爷。

对于客户：我只要某几个字段改了能回去就行。 

 

4：从模板的复杂度看进化

Stage One：单表导入

好简单的说，使用 CYQ.Data 框架（好久没在文章中介绍了，历经几年低调的发展，有机会再写文）中MDataTable的批量功能，一行代码就完事了。

 

Stage Two：多表导入

麻烦开始了，两张表就算了，可是你来2，3，4，5，6，7表，一个导入要关联这么多表，还得理解业务，还要分拆一对N关系，一个导入要整好几天。

如果回头客户说改模板，心里瞬时多了几草泥马穿过。。。

 

Stage Three：要求导出和导入的Excel都有多级表头

又麻烦了，合并的单元头、卧槽还有同名的列头，难道要写死指定第N行的列头就A表名字，N+N行的列头是B表的名字？

如果模板增加字段，换了位置， 心里莫名又多了几只草泥马越过。。。。

 

Stage Four：表头和数据藏在中间，要求能自动忽略上下左的垃圾数据

模板的上面十几行，是一大堆没用的数据，模板的左边和下面，是一些填写的说明（而这些，是其它系统的数据，跟我们做的系统有毛关系啊，但客户就是这么牛B）

所以，又要增加处理，从第几行读数据，列头跨几个行，右边第N行是无效的，心里刹间又多了几只草泥马踩过。。。

 

Stage Five：多Sheet导入

模板增加一个分类列就可以搞定的事，客户打死也不要，非要一个分类一个Sheet，然后全部导入。

所以，你得按Sheet名称自动转换成分类名称，来处理这些事。

还有原来一个Sheet多表的一对N关系，要分拆到N个Sheet里去让你处理导入， 心里哗哗已无数只草泥马踏过。。。

5：总结： 

在正常的需求阶段，理论上是应该引导用户规避掉一些不合理的设计，但现实有时候就是被客户牵着走。。。 

因此，在面对如此这么复杂的场景和变态要求下，如果不设计一套智能组件，则开发成本和开发人员无疑将陷入无限的悲哀中。

好在，我在。 

下一文，将与大伙分享Excel的组件化的设计方案