一个自己写的组件--异常报告(2):组件的重构和配置
2008-07-03 20:40 GUO Xingwang 阅读(1765) 评论(4) 编辑 收藏 举报 在上一篇文章中我对异常报告组件MyDebuger做了一个一般性的介绍并用简单的C#对其进行了实现,发表之后网友们提出了一些建议,也提出了一些Bug。在这里,非常感谢来自你们的建议,我从中领略到了社区对于软件开发的重要性,社区的意见是宝贵的。其中有一位朋友说"虽然能看懂但是代码逻辑混乱,应该好好重构下",还有人说那个Debuger.Debug()方法中的obj为空的问题.自己仔细的考虑了一下,可能确实比较混乱,于是在这一篇文章中我将着力讲述我对MyDebuger组件是怎样进行重构的,并对上一节提到的配置问题进行了实现(实现的可能不太好,但是已经基本满足需求了).花了一整天时间,希望这次会好一点。
1.组件的重构
对于组件的重构我主要是在原来的基础上对异常提交处理部分进行了抽象,采用了Factory Method模式(灵感来源与博客园上的一篇叫《解读设计模式----工厂方法模式》,http://www.cnblogs.com/beniao/archive/2008/04/13/1145936.html,作者:beniao).对于异常发掘机部分我采用了一个Singleton模式,个人觉得这两个模式比较适合我的组件,理由是:对于Factory Method我们希望可以通过配置决定采用哪个Creator;这正好是我所需的,对于Singleton模式的应用自然由于系统中只要有一个这样的发掘机就已经足够了(以单例模式运行比较好),再者我增加了一个参数用来记录发现的异常是第几个,这是一个统计参数,有可能输出,于是我就在这个单例中增加一个计数器解决了这个问题的,这也是单例带来的好处.希望这两个模式没有被我滥用。
重构后的解决方案结构如下:
刚才提到了异常发掘机,可能有的朋友不是很清楚,那么现在就让我们来认识一下项目中的几个文件(类,我开发这个组件时基本上是一个类写到一个文件中,个别除外例如Config.cs)的具体作用吧,其中组件中一个很重要的部分就是异常发掘机(Detector,由于是单例,使用Detector.GetCurentInstance()获得),形如:

Common.cs:这里封装了一个ContextWraper类型,主要用于异常消息的传递方便。
Debuger.cs:属于最高层的使用部分,收集相应的异常信息.当方法捕获到异常时使用Debuger.Debug()方法进行处理就可以了。
Detector.cs:这就是所谓的异常发掘机,实际上它是一个Singleton,里面封装了异常消息的处理,对外提供事件接口,用户可以自定义处理程序,当系统中出现异常时,即Debuger.Debug()被调用时(或其它方式)将会触发事件,被触发的事件由用户自定义的处理程序进行处理,例如:

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17


2

3

4

5

6

7

8

9

10

11

12

在处理模式上通过配置可以采用兼容异常处理程序方式进行处理,即自定义处理程序和组件提供的处理程序同时进行或只有自定义处理程序执行。此外异常发掘机对外还提供了一个操作默认异常处理程序的操作接口。
IOutput.cs和OutputCreator.cs实现了Factory Method的抽象部分,我们需要的处理程序实现IOutput接口,再提供一个相应的Creator,最后通过配置文件指定就可以与组件的主体部分一起工作了。
EventLogsOutputCreator.cs和EventLogsOutput.cs是上面的抽象部分的一种实现,同时也是MyDebuger的默认异常处理程序。
ExceptionContextEventArgs.cs:这个我想就不用说了吧。Config.cs:配置处理部分,主要是提取出配置项并以强类型方式提供给程序使用,文件里定义了一个类型转换器,下面会具体介绍。

2.组件的配置
配置可以给软件带来灵活性和可扩展性,通过配置的都属于变化的部分,当用户需求改变时,我们不用修改代码和重新编译,只要简单的修改一下配置文件就可以了。配置文件一般做成软件和人都可以看懂的文件,一般以XML文件存储比较适合,配置项的选取很重要,如果一个配置项一直没有修改过,那就还不如约定好,约定在一定条件下确实胜于配置(约定胜于配置).哈哈,扯得有点远了。
.Net平台下应用程序的配置部分是比较繁琐的,如果不好好研究一下真的很难弄懂,它的配置处理一般使用System.Configuration名称空间,但是在引用里显示的是System.configuration,字母c是小写的,不知道微软为什么这么做?哈哈,甭管它了。先看看我的配置是怎么做的吧!根据MyDebuger组件的需求,我目前设计了如下配置项:
2

3

4

5

6

其中各个部分的含义如下:
Attribute |
Type |
description |
default |
|
defaultOutputApply |
bool |
用来配置outputCreators中的Creator是否生效,主要是为用户已经对发掘机事件进行了处理之后还是否保留默认的处理方式,为true时表示同时生效,为false表示只有用户程序生效 |
true |
|
outputCreators |
outputCreatorsCollection |
异常发掘机采用的所有处理程序的挂接 |
Windows事件日志处理 |
|
name |
string |
处理程序的名称 |
||
outputCreator |
OutputCreator |
处理程序,格式如下:“名称空间,类名称,程序集” |
||
Add Remove Clear |
string |
标准的.Net配置节点的增删,清空方式 |
为了这个配置还要写上几个类(好像有个scdl.exe工具专门可以生成代码,不过没有找到,干脆自己写一个吧) :

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

99

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

其中OutputCreatorConverter用于从上面的配置项中将OutputCreator生成强类型的OutputCreator而提供的类型转换器.这样使用就行了。
配置的使用很简单,我们只需要在应用程序(Winform,Console,WebForm,WS等都没问题)App.config或Web.config文件中增加下面的配置部分就可以了:

2

3

4

5

6

7

8

9

10

11

其中type="MyDebuger.MyDebugerSettingsSection, MyDebuger"为定义在Config.cs中的配置处理类,说明使用强类型进行了处理。
这个组件已经实现了,源代码提供给大家,如果有时间我可以写一个异常处理程序,然后通过配置与这个组件一起工作。感兴趣的朋友也可以自己实现。
总结:在做面向对象的软件的设计时,最重要的一点就是封装变化点,哪里变化封装哪里!
组件源代码和Demo测试:
MyDebuger_SRC20080703.RAR
【来源】:http://thriving-country.cnblogs.com/
本文版权归作者和博客园共同所有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文链接。