.Net Remoting测试小技巧
其实也不能说是小技巧,只是大家可能会没有重视。这是需要先说明的,否则会被我的标题迷惑,因为我要描述的内容,真是寻常无比。
编写Remoting程序,通常分为三部分:远程对象、服务端程序、客户端程序。如果不考虑元数据的安全性,我们会把远程对象的dll生成相同的两份,分别放到服务端和客户端。Remoting在客户端的调用是很简单的,但调试起来就没有那么容易。因为客户端和服务器端分别属于不同的应用程序域,无法设置断点进行单步调试。如果了解NUnit,大家会知道NUnit也是不支持分布式应用程序的调试的,至少是支持得不够好。
所以,在实际做项目的过程中,我更倾向于先调用本地的对象,等调试成功后,再打开Remoting服务,调用远程对象,验证是否正确。举例来说,我要提供访问数据库的远程对象。我会先让该对象在本地运行,并调用其方法。如果一切正常,说明数据库的配置和连接均是正确的。然后再将该调用替换为远程对象。如果程序出错,则可以肯定是Remoting提供的服务出错了,或者是远程对象未按照Remoting的规定,没有派生MarshalByRefObject,或者未提供序列化特性。
最初我使用了最愚蠢的办法,就是写两行调用,一个调用本地对象,一个调用远程对象。然后根据实际的情况,酌情考虑注释某一行代码。如此这般用了一段时间,终于觉得麻烦,迫使我改变方法了。其实很简单,就是为客户端程序的主类中,多写一个构造函数而已,呵呵:)
例如,远程对象是一个访问数据库的Remoting服务,派生MarshalByRefObject的主类名为DBAccessService。那么我首先定义一个枚举,分别标明是属于本地调用还是远程调用:
public enum InvokeMode
{Local=0,Remoting}
对于客户端程序,如果主类为DataBaseOperate,那么就需要增加一个构造函数和远程对象字段:














如此这般,在客户端调用对象时,就可根据设置构造函数中的参数枚举值,灵活地改变客户端调用对象的方式。
其实这种办法也可以用简单工厂模式来完成。不过这个简单工厂生产的产品和通常意义的工厂模式有点不一样哦,因为他们的产品其实是完全相同的。不同的仅仅是创建对象的方式而已。




switch (invokeMode)










然后再调用工厂的静态方法,来获得该对象即可。
两种方法都是一种思想:就是根据需要,选择不同的创建方式(其实前一种方法也可以看作是简单工厂模式的一种变种)。如果只有一个要创建的对象,选前者更为方便;如果需要创建多个对象,用工厂方法提供多个静态方法,应该要灵活一些。
通过上述方法,不仅便于调试,也便于以后代码的修改。如果取消使用Remoting,只需改变参数枚举值即可,其他代码通通不用改变。这个技巧也算是设计模式的一种最简单应用吧。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· .NET Core 中如何实现缓存的预热?
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· AI与.NET技术实操系列:向量存储与相似性搜索在 .NET 中的实现
· 基于Microsoft.Extensions.AI核心库实现RAG应用
· Linux系列:如何用heaptrack跟踪.NET程序的非托管内存泄露
· TypeScript + Deepseek 打造卜卦网站:技术与玄学的结合
· 阿里巴巴 QwQ-32B真的超越了 DeepSeek R-1吗?
· 【译】Visual Studio 中新的强大生产力特性
· 10年+ .NET Coder 心语 ── 封装的思维:从隐藏、稳定开始理解其本质意义
· 【设计模式】告别冗长if-else语句:使用策略模式优化代码结构