标签：
看过我文章的网友们都知道，通常前言都是我用来打酱油扯点闲情的。
自从写了上面一篇文章之后，领导就找我谈话了，怕我有什么想不开。
所以上一篇的（下）篇，目前先不出来了，哪天我异地二次回忆的时候，再分享分享。
话说最近外面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
标签：
原文地址：http://www.cnblogs.com/softidea/p/4515830.html
