框架，从另外一个角度说，就是一个半成品的应用程序，既然如此，框架在运行的过程中也会遇到诸多的异常、错误情况，我们需要将这些情况记录下来，以便在发生问题时为我们的诊断提供必要的帮助。
最最开始，那还是在ESFramework的前身即EnterpriseServerBase的时候，由于当时只是将EnterpriseServerBase作为一个类库，而并没有提升到一个框架的高度，所以是没有必要为之配备一个日志记录器（Logger），就像你从来不曾看到在使用.NET类库时还必须传个日志记录器给它，以使.NET类库中的API碰到额外情况时能够记录下错误信息。类库中的API遇到额外情况时通常是抛出异常或返回错误码（C API的常用方式）。
到了框架这一层，就不能仅仅只是抛出异常、或返回错误码这么简单了。原因在于，几乎所有的框架都有IOC的能力（正是这种IOC能力才能称之为框架，才能称之为半成品的应用），即，不是由你去调用框架的API，而是框架调用你写好的方法或接口。在这种情况下，控制权发生了转移，框架成了主动的角色。既然如此，如果框架运行抛出异常的话，这个异常该由谁去截获了？所以，框架中具有IOC能力的那些类/组件（言外之意，一个框架中并非所有的组件/类都有IOC能力，很多组件/类都类似于普通类库中的API）在遇到异常情况时不能简单的抛出异常了事，更好的办法当然是主动地记录异常日志。
从EnterpriseServerBase上升到ESFramework一个很重要的变化就是为之配备一个日志记录器，即我们这里将要讲到的IEsbLogger。IEsbLogger接口非常简单：
ESFramework并没有给出IEsbLogger的任何实现，这个实现由应用来完成，你可以选择将日志信息记录到数据库、也可以记录到文本文件、甚至可以通过消息队列发送到专门分析处理异常日志的服务器上。而且，你还可以对不同ErrorLevel的信息进行不同的分类处理等等。IEsbLogger.Log方法中的location参数表明了该异常发生的位置，通常是类似于“ESFramework.NetWork.SomeClass.SomeMethod”等字符串。
ESFramework并不记录所有异常，因为有些异常，框架能够自行处理。比如，Tcp用户突然断开连接，此时对应连接上的读写操作将会抛出异常，而ESFramework会将此异常理解为用户掉线而触发相应的事件来通知相关的关注者（比如，ITcpUserManager）。ESFramework记录那些重要的、不可忽略的、对应用程序的稳定可能产生影响的异常，比如，FS和AS之间的Tcp连接池中断等。
最后，简单说明一下ErrorLevel枚举上的EnumDescription特性的作用，该特性用于在枚举和枚举的描述之间能够互相解释和转换，比如我们实现IEsbLogger.Log方法，将日志写入数据库，可是第三个参数level是个枚举值，该如何记录了？我们可以通过EnumDescription.GetFieldText（）方法将其转换成对应的描述，比如，ErrorLevel.Fatal枚举值转换为“致命的”这样一个字符串，这样就可以方便的存入数据库或写入文本了。EnumDescription的定义位于ESFramework的BaseElement目录下，主要参考并简化了“大尾巴狼”朋友的EnumDescription实现，感谢“大尾巴狼”的好点子。
感谢关注！
转到 ：ESFramework 可复用的通信框架（序）
最最开始，那还是在ESFramework的前身即EnterpriseServerBase的时候，由于当时只是将EnterpriseServerBase作为一个类库，而并没有提升到一个框架的高度，所以是没有必要为之配备一个日志记录器（Logger），就像你从来不曾看到在使用.NET类库时还必须传个日志记录器给它，以使.NET类库中的API碰到额外情况时能够记录下错误信息。类库中的API遇到额外情况时通常是抛出异常或返回错误码（C API的常用方式）。
到了框架这一层，就不能仅仅只是抛出异常、或返回错误码这么简单了。原因在于，几乎所有的框架都有IOC的能力（正是这种IOC能力才能称之为框架，才能称之为半成品的应用），即，不是由你去调用框架的API，而是框架调用你写好的方法或接口。在这种情况下，控制权发生了转移，框架成了主动的角色。既然如此，如果框架运行抛出异常的话，这个异常该由谁去截获了？所以，框架中具有IOC能力的那些类/组件（言外之意，一个框架中并非所有的组件/类都有IOC能力，很多组件/类都类似于普通类库中的API）在遇到异常情况时不能简单的抛出异常了事，更好的办法当然是主动地记录异常日志。
从EnterpriseServerBase上升到ESFramework一个很重要的变化就是为之配备一个日志记录器，即我们这里将要讲到的IEsbLogger。IEsbLogger接口非常简单：
public
interface
IEsbLogger
{
void Log( string msg , string location ,ErrorLevel level) ;
bool Enabled{ set ;}
}
[EnumDescription( " 异常/错误严重级别 " )]
public enum ErrorLevel
{
[EnumDescription( " 致命的 " )]
Fatal,
[EnumDescription( " 高 " )]
High ,
[EnumDescription( " 普通 " )]
Standard ,
[EnumDescription( " 低 " )]
Low
}
{
void Log( string msg , string location ,ErrorLevel level) ;
bool Enabled{ set ;}
}
[EnumDescription( " 异常/错误严重级别 " )]
public enum ErrorLevel
{
[EnumDescription( " 致命的 " )]
Fatal,
[EnumDescription( " 高 " )]
High ,
[EnumDescription( " 普通 " )]
Standard ,
[EnumDescription( " 低 " )]
Low
}
ESFramework并没有给出IEsbLogger的任何实现，这个实现由应用来完成，你可以选择将日志信息记录到数据库、也可以记录到文本文件、甚至可以通过消息队列发送到专门分析处理异常日志的服务器上。而且，你还可以对不同ErrorLevel的信息进行不同的分类处理等等。IEsbLogger.Log方法中的location参数表明了该异常发生的位置，通常是类似于“ESFramework.NetWork.SomeClass.SomeMethod”等字符串。
ESFramework并不记录所有异常，因为有些异常，框架能够自行处理。比如，Tcp用户突然断开连接，此时对应连接上的读写操作将会抛出异常，而ESFramework会将此异常理解为用户掉线而触发相应的事件来通知相关的关注者（比如，ITcpUserManager）。ESFramework记录那些重要的、不可忽略的、对应用程序的稳定可能产生影响的异常，比如，FS和AS之间的Tcp连接池中断等。
最后，简单说明一下ErrorLevel枚举上的EnumDescription特性的作用，该特性用于在枚举和枚举的描述之间能够互相解释和转换，比如我们实现IEsbLogger.Log方法，将日志写入数据库，可是第三个参数level是个枚举值，该如何记录了？我们可以通过EnumDescription.GetFieldText（）方法将其转换成对应的描述，比如，ErrorLevel.Fatal枚举值转换为“致命的”这样一个字符串，这样就可以方便的存入数据库或写入文本了。EnumDescription的定义位于ESFramework的BaseElement目录下，主要参考并简化了“大尾巴狼”朋友的EnumDescription实现，感谢“大尾巴狼”的好点子。
感谢关注！
转到 ：ESFramework 可复用的通信框架（序）
