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的組件化的設計方案