Proxy Pattern (代理模式)
The Proxy Pattern provides a surrogate or placeholder for another object to control access to it
－ Design Patterns: Elements of Reusable ObjectOriented Software
在 GoF 的书中对 Proxy 模式的定义为替某个对象提供一个替身以控制外界对这个对象的访问而这个被替身代理的对象 (被代理者)可能是远端的对象创建时需要高成本或大计算量的对象或需要安全控制的对象
图 此图为 Proxy 模式的经典类图
_Shell / Programcs
using System;
namespace __Shell
{
//用户端程序
class Program
{
static void Main(string[] args)
{
//用户把 Proxy (代理者) 视为 RealSubject (真实的对象) 来操作
Proxy proxy = new Proxy();
proxyRequest();
ConsoleRead();
}
}
//代理者被代理者共同实现的接口
abstract class Subject
{
public abstract void Request();
}
//被代理者真实的对象把复杂性封装在此
class RealSubject : Subject
{
//真正做事的方法把复杂性封装在此用户无须知道细节
public override void Request()
{
ConsoleWriteLine(真实的请求);
}
}
//代理者
class Proxy : Subject
{
RealSubject realSubject;
public override void Request()
{
if (realSubject == null)
{
realSubject = new RealSubject();
}
realSubjectRequest();
}
}
}
/*
执行结果
真实的请求
*/
上方图 的 Class Diagram以及「Shell (壳)」示例中我们有一个 Subject 抽像类这是 RealSubject 和 Proxy 共同的接口好让任何用户都可将 Proxy 对象 (代理者) 视为 RealSubject 对象 (被代理者亦即真实的对象) 来处理
其中 RealSubject 是真正做事的对象它是被 Proxy 代理的对象它的方法是真正做事的函数并会将一些复杂的工作封装在其方法里而无须让客户端程序知道实现细节为何而 Proxy 中的同名称方法 (Request 方法)则可做一些逻辑判断比如上例中我们做了 realSubject 是否为 null 的 if 判断亦即只有客户程序第一次调用此函数时才去创建 RealSubject 对象
客户端和 RealSubject 的互动都必须透过 Proxy也由于 Proxy 和 RealSubject 实现了相同的接口所以客户在任何需要 RealSubject 的地方都可以用 Proxy 取而代之此外Proxy 也控制了客户端对 RealSubject 的访问其目的如同本帖一开始所说的因为 RealSubject 可能是网络上远端机器上的对象创建时需要高成本或需要安全控管及经过认证才能访问的对象其原理类似于下图 的 HTTP Proxy Server 情景Clientside 想要前往 Internet 取得 Web Server 上的信息时可透过 Proxy Server 帮忙处理其中 Web Server 就如同 RealSubject (被代理者)而 Proxy Server 就如同 Proxy (代理者)
图 基于代理的远程访问示意图
Proxy Pattern 依照功能和目的运行环境的不同可概略分成以下几种
远程代理 (Remote Proxy)替网络上机器与机器之间的请求 (request)做「发送 / 接收」和编码加密…等工作让用户端程序只要调用这个代理就能做远端调用如Java RMIWeb ServiceNET RemotingNET WCF其中 Web Service 和 WCF会在引用的客户端程序中产生 App_WebReferences 文件夹一些档案和代理类这些档案即为此种远程代理
保护代理 (Protection Proxy; Access Proxy)检查调用者是否有权限去访问真实的对象例如用户是否有输入正确的密码以通过认证
智能引用代理 (Smart Reference Proxy)当对象被调用时提供一些额外的操作例如记录对象被调用的次数
虚拟代理 (Virtual Proxy)让一个资源消耗较大的对象只有在需要时才会真正被创建或让真实对象只有在第一次被调用时才创建
其他例如CopyOnWrite ProxyCache ProxyFirewall ProxySynchronization Proxy等 [] [] []
在 GoF 中所举的例子是 Virtual Proxy举了一个文档中内嵌图片的范例 [] []若图片是在文档 (如PDFPowerPoint) 的其中某一页用户刚打开文档时并不需要载入图片可先用一个 ImageProxy代替真实的图片被载入当用户滚动滚动条转到文档特定的页数时才真正从硬盘载入图片以求开启此文档时能加快速度让用户对此软件有较好的体验
图 虚拟代理 (Virtual Proxy) 在 GoF 示例的类图与本帖图 的原理相同
如上图 及下方代码所示当文档被开启时ImageProxy 对象会代替 (代理) Image 对象被载入在用户还没转到图片所在的页数时也就是还没调用 ImageProxy 的 draw 方法时图片并不会被载入因此可加速文档的开启节省内存的使用当用户转到图片所在页数时ImageProxy 的 draw 方法才会被调用此时才真正去创建 Image 对象从硬盘中载入图片在此例的 draw 方法里我们实现了「虚拟代理」只有在方法「第一次」被调用时才创建资源消耗大的 Image 对象以节省内存控制创建成本昂贵的资源
_VirtualProxy_Image / Programcs
using System;
using blogsWizardWuSample;
//客户端程序
class Program
{
static void Main(string[] args)
{
//当文档被打开时ImageProxy 对象会代替(代理) Image 对象被载入
IGraphic image = new ImageProxy(风景图jpg);
ConsoleWriteLine(文档被打开真实的图片尚未被载入);
ConsoleReadLine();
ConsoleWriteLine(用户已把滚动条滚到特定页数图片此时才从硬盘载入);
imagedraw(); //真正要显示图片了
ConsoleReadLine();
}
}
//服务器端程序
namespace blogsWizardWuSample
{
//此为「代理者被代理者」共同的接口
public interface IGraphic
{
//用来画图的方法
void draw();
}
//被代理者真实的对象把复杂性封装在此
public class Image : IGraphic
{
private byte[] data;
public Image(String fileName) //构造函数
{
//载入图片把复杂性封装起来
//data = loadImage(fileName);
ConsoleWriteLine(开始载入图片);
}
public void draw()
{
//绘制图片在屏幕上把复杂性封装起来
//drawToScreen(data);
ConsoleWriteLine(图片已成功绘制在屏幕上);
}
}
//代理者
public class ImageProxy : IGraphic
{
private String fileName;
private Image image;
public ImageProxy(String filename) //构造函数
{
thisfileName = filename;
image = null;
}
//等到真正要显示图片了这个 ImageProxy 的 draw 方法才会被调用
//此时才会真正去创建 Image 对象并从硬盘中载入图片
public void draw()
{
//虚拟代理仅在方法第一次被调用时才创建资源消耗大的 Image 对象
if (image == null)
{
image = new Image(fileName);
}
//实际去绘制图片在萤幕上
imagedraw();
}
}
} // end of namespace
/*
执行结果
文档被开启真实的图片尚未被载入
用户已把滚动条滚到特定页数图片此时才从硬盘载入
开始载入图片
图片已成功绘制在屏幕上
*/
代理的主要目的之一是把复杂性封装起来让客户端程序在引用上更容易而不需要顾虑藏在身后这些复杂的逻辑如上方这个示例我们可以把「载入图片绘制图片在屏幕上」这些较复杂的 NET API 引用代码都封装在「被代理者」这个真实 Image 对象的几个自定义方法里
此外我们也可用相同于本示例的逻辑去实现「保护代理 (Protection Proxy)」的观念例如要求用户必须输入正确的密码先通过认证 (Authentication) 后才能访问 RealSubject 对象调用其方法相关的范例有兴趣的读者可自行去「C# Design Patterns」这本书籍的 OReilly 英文官方网站上 []下载第二章的源代码
接下来的第三个示例为「数据访问代理」的 ASPNET 例子 [] []用来取得 Northwind 数据库中 Employees 表的记录总数其类图如下图 和本帖第一第二个示例的类图略有不同它是将 RealSubjectProxy 合而为一变成单一个 DbCommandProxy 类其左侧的 DbContext 类只是用来协助解决复杂性的问题包括取得 nfig 的数据库连接字符串建立数据库的连接
这个 DbCommandProxy 类实现了 NET 用来执行 SQL 语句的原生 IDbCommand 接口 []我们为了将复杂性问题具体的数据库连接方式隔离出来因此另外提供了一个 DbContext 类并将这些动作都搬移至 DbContext 类去处理以另一种设计理念实现了 Proxy Pattern
图 示例 _DbProxy / Defaultaspxcs 的类图
_DbProxy / Defaultaspxcs
using System;
using blogsWizardWuSample;
using SystemData;
using SystemDataCommon;
using SystemConfiguration;
//客户端程序
public partial class _Default : SystemWebUIPage
{
protected void Page_Load(object sender EventArgs e)
{
IDbCommand command = new DbCommandProxy();
commandCommandText = SELECT COUNT(*) FROM Employees;
//显示 Employees 表的记录总数
thisLabelText = commandExecuteScalar()ToString();
}
}
//服务器端程序
namespace blogsWizardWuSample
{
//这个类并非「被代理者」此为自定义 DbCommandProxy 类的辅助类
//将具体建立数据库连接…等较复杂的部分提取出来隔离在这个类里去处理
class DbContext
{
private string strProviderName;
private string strConnectionString;
public DbContext(string name) //构造函数
{
//取得 nfig 里的数据库连接字符串名称
ConnectionStringSettings setting = ConfigurationManagerConnectionStrings[ConnString_SqlClient];
thisstrProviderName = settingProviderName;
thisstrConnectionString = settingConnectionString;
}
public DbConnection CreateConnection()
{
DbProviderFactory factory = DbProviderFactoriesGetFactory(thisstrProviderName);
DbConnection connection = factoryCreateConnection();
connectionConnectionString = thisstrConnectionString;
return connection;
}
}
//将「代理者被代理者」合而为一 (另一种做法)
//此类同时为 RealSubject 和 Proxy 的类
public class DbCommandProxy : IDbCommand
{
private DbContext context;
private string strCommandText;
public DbCommandProxy(string name) //构造函数
{
if (stringIsNullOrEmpty(name)) throw new ArgumentNullException(name);
ntext = new DbContext(name);
}
public DbCommandProxy() : this(default) { } //构造函数
public object ExecuteScalar()
{
using (DbConnection connection = contextCreateConnection())
{
connectionOpen();
DbCommand command = connectionCreateCommand();
commandCommandText = thisstrCommandText;
commandCommandType = CommandTypeText;
return commandExecuteScalar();
}
}
public string CommandText
{
get { return thisstrCommandText; }
set { thisstrCommandText = value; }
}
//IDbCommand 接口未被实现的成员
}
} // end of namespace
Proxy Pattern 适用的情景
对象创建的代价比较高
仅在操作被请求时创建对象
对象需要访问控制如: 权限验证或访问的同时去执行检查或簿记工作
需要访问远程站点
被访问时需要执行一些逻辑判断的动作
Proxy Pattern 的优点
降低对象使用的复杂度
增加对象使用的友好度
提高程序的效率和性能 (如同 HTTP 的 Proxy Server)
Proxy Pattern 的缺点
和一些 Pattern 一样Proxy Pattern 会造成系统设计中类的数量增加
Proxy Pattern 的其他特性
Proxy Pattern 的结构类似上一篇帖子的 Decorator Pattern (装饰模式)但是目的不同
Decorator Pattern 替对象加上行为而 Proxy Pattern 则是控制对象的访问
Proxy Pattern 的关系是在设计阶段就确定好了的是事先知道的而 Decorator Pattern 却可以动态地添加
