关于“假导出Excel功能实现，按CSV格式快速导出功能代码参考”的一篇回复

吉日同志的原贴见：/article/6947918.html

我的回复：

（1）：哥们的代码看起来也有很多重载.但是重复代码太多,而且类中各功能职责不清楚,很托沓.

吉日的回复：

@mywork
大哥，我好像很在意这个，不知道哪里有错误了，我就本着单一职责写的代码，自己没体会出来哪里写错了，希望高手能指点。

@mywork
实在是没能看出来，哪里不单一了，希望能高人能指点。

我的回复：

那我说几处吧,哥们别不爱听.
1. 重复代码太多.
目前我就发现三处"StreamWriter.Flush();
StreamWriter.Close();"
是否可以归并?而且在写数据时,未考虑如果IO写操作异常怎么办?
2. 功能职责不清晰,功能划分不合理
ExportExcel(DataGridView dataGridView, DataView dataView, string directory, string fileName)中有一段判断目录是否存在的代码,那个FileExist中又有一段判断文件是否已经存在的东西,是否可以归一化处理?
3. 类耦合性太强
ServiceManager.Instance.OrganizeService.GetDT
BaseOrganizeTable.FieldParentId/BaseOrganizeTable.FieldSortCode;
AppMessage.Format/AppMessage.MSG0236/AppMessage.MSG0000
BaseSystemInfo.StartupPath
BaseExportCSV
BaseBusinessLogic.SelectedColumn
说实话一个简单的功能,要调用这么几个类,可真够麻烦的.
而且在一个方法中BaseSystemInfo.StartupPath 要调用两次.如果那个BaseSystemInfo.StartupPath 是个计算出来的属性,那么性能也要考虑.
4. 类设计过度
ExportCSV(DataSet dataSet, string fileName)
目前我为止,我还不知道一个CSV文件要容纳多张表数据时还要如何用.
5. 特殊情况未处理
BaseExportCSV.ExportCSV(dataGridView, dataView, file);
Process.Start(file);
如果此时文件IO操作未完成,启动新进程会出现文件被占用问题.不信可以试一下长数据.
6. 静态类太多,不利于维护/扩展
这似乎是个美学问题,谁让微软还让大家还能使用静态类?不过现在本人现在除了设置类和扩展方法用静态类之外,其他情况几乎不用静态类了.

声明一点,我不是砸场子的.以上所说仅算是一家之言.
其实你这么多的代码,最终仅两个功能即可替代
(A)导出DataTable或DataView或DataGridView的数据源数据为StringBuilder,参数可以考虑选择特定分隔符,不限于",";
(B)保存StringBuilder为指定路径文件,中间判断目录是否存在,不存在创建,文件如果存在,则覆盖,参数可以考虑Encoding.

以上两个方法都可以扩展方法形式存在.进一步减少编码时代码量.

再建议一次,StreamWriter streamWriter 推荐用using()方式调用,省心省力.
另:一个通用的功能,确实应该考虑处理特殊情况.

期待吉日出来解释我说的那几种情况的原因.

后来我等了两天，吉日也没有回复。

下一遍我发一个基于Gembox.Spreadsheet 2.9 的真导出的功能实现。