这个问题看起来很简单，实际做的时候碰到很多问题：
1. 怎么判断命令的响应结束？
最开始就是简单的在循环中判断NetworkStream.DataAvailable，如果没有了就结束读取。
最初的时候运行还可以，只是偶尔出些莫名其妙的响应，并且很少出错。
后来测试internet上的服务器，问题出来了。几乎没有一个正确返回。最好的情况不过是读回了echo。
看样应该等远程服务器响应结束，但是怎么判断响应结束呢？如果网络不痛快，一个字节一个字节的返回数据，该怎么判断？后来决定，对每个响应都去判断它是否完全返回命令结果。即使出错，也要判断有完整的出错信息才算完事。
2. 事情又来了，每个命令有不同的返回结果，怎么判断响应正确？
有些时候结果的行数都不确定。而且有些操作结果是在中间，出现了这个标志行，并不说明命令结束，可能后面的结果还没回来呢！
最后发现倒推法比较合适。就是倒数N行，应该是我要的正确操作提示。或者倒数M行，是错误提示。
这样可以确保后面的行数都已经返回，避免和下个命令的结果混淆在一起。
3. 怎样判断指定行是否需要的信息？
开始用string比较。后来发现Telnet服务器也很聪明，经常会返回一些动态的东西。后来用正则表达式，牺牲了一点效率。
4. 事务
Telnet要和数据库联合操作，操作要同步。这个比较简单，在事务中先操作数据库，再操作telnet, 出错了Rollback数据库事务。Telnet多个步骤之间没有事务了 :(
5. 测试
写后台模块，没有Main方法。用Nunit再方便不过了。
用JGTM提到的编译后事件检查编译结果，调试用调试的启动程序。还用过hbifts优化过的插件，用的不多，有前面两种方式已经差不多了。
一开始把测试代码和类写在一起，甚至是一个类里面，有些偷懒。后来在重构的时候，这些散落的测试代码成了绊脚石，失败的尝试。有人反应运行AOP的代码需要nunit模块，对于用户会比较头痛。
后来单独分离出来一个测试Project, 而且测试代码中，并不是对每个方法都去测试，因为有些测试会调用相关模块。也许这种测试不能算是完全的测试，对我来说，有点象调试工具和重构的Assert。
nunit里面有个[Ignore(“Passed“)]标记很好用，测试过的类为了节省时间，可以把整个TestFixture忽略掉。
6. AOP
因为是业务模块，CBO AOP就发挥了一点小作用。记得以前在Java下面操作事务要写很多try..catch..finally..用EJB又要做复杂配置。现在解放了，基本上配置几个Attribute就搞定了。基本上可以专注于业务逻辑了。
1. 怎么判断命令的响应结束？
最开始就是简单的在循环中判断NetworkStream.DataAvailable，如果没有了就结束读取。
最初的时候运行还可以，只是偶尔出些莫名其妙的响应，并且很少出错。
后来测试internet上的服务器，问题出来了。几乎没有一个正确返回。最好的情况不过是读回了echo。
看样应该等远程服务器响应结束，但是怎么判断响应结束呢？如果网络不痛快，一个字节一个字节的返回数据，该怎么判断？后来决定，对每个响应都去判断它是否完全返回命令结果。即使出错，也要判断有完整的出错信息才算完事。2. 事情又来了，每个命令有不同的返回结果，怎么判断响应正确？
有些时候结果的行数都不确定。而且有些操作结果是在中间，出现了这个标志行，并不说明命令结束，可能后面的结果还没回来呢！
最后发现倒推法比较合适。就是倒数N行，应该是我要的正确操作提示。或者倒数M行，是错误提示。
这样可以确保后面的行数都已经返回，避免和下个命令的结果混淆在一起。
3. 怎样判断指定行是否需要的信息？
开始用string比较。后来发现Telnet服务器也很聪明，经常会返回一些动态的东西。后来用正则表达式，牺牲了一点效率。
4. 事务
Telnet要和数据库联合操作，操作要同步。这个比较简单，在事务中先操作数据库，再操作telnet, 出错了Rollback数据库事务。Telnet多个步骤之间没有事务了 :(
5. 测试
写后台模块，没有Main方法。用Nunit再方便不过了。
用JGTM提到的编译后事件检查编译结果，调试用调试的启动程序。还用过hbifts优化过的插件，用的不多，有前面两种方式已经差不多了。
一开始把测试代码和类写在一起，甚至是一个类里面，有些偷懒。后来在重构的时候，这些散落的测试代码成了绊脚石，失败的尝试。有人反应运行AOP的代码需要nunit模块，对于用户会比较头痛。
后来单独分离出来一个测试Project, 而且测试代码中，并不是对每个方法都去测试，因为有些测试会调用相关模块。也许这种测试不能算是完全的测试，对我来说，有点象调试工具和重构的Assert。
nunit里面有个[Ignore(“Passed“)]标记很好用，测试过的类为了节省时间，可以把整个TestFixture忽略掉。
6. AOP
因为是业务模块，CBO AOP就发挥了一点小作用。记得以前在Java下面操作事务要写很多try..catch..finally..用EJB又要做复杂配置。现在解放了，基本上配置几个Attribute就搞定了。基本上可以专注于业务逻辑了。
