Noah Subrin's DEV Blog
Technology for Business minds

The Proxy Pattern

Print the article

This entry was posted on 12/3/2006 9:17 AM and is filed under Design Patterns.

This week in my SRA-U Design Patterns class we discussed the Proxy Pattern. The Proxy Pattern provides a surrogate or placeholder for another object to control access to it. Proxies are prevalent in the software world today. In fact, using WCF (Windows Communication Foundation), all access to services is performed through proxies. When we call a web service, the client does not call the web service directly, but instead calls a class exposed by a proxy class. At times, we may work in an environment behind a firewall, and the customer has access to the Internet and other network resources through a proxy server.

In our class, we discussed three variations of the Proxy Pattern, the remote proxy, the virtual proxy, and the protection proxy. A remote proxy provides a local representative for an object in a different address space. In the Microsoft world prior to the .Net Framework 3.0, this was performed the .Net Remoting API. In Java, it is done by the RMI package.  In the .Net Framework 3.0, Remoting can exist side by side with WCF, or existing investments in Remoting can be migrated to WCF. In most remoting applications, we typically see a client side application (.exe), a dll shared between client and server, and an implementation of some services. This might a dll or an .exe.  A good discussion of remoting and WCF is written by Ingo Rammer and available at this url http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/NETremoteWCF.asp.  A virtual proxy controls access to a resource that is expensive to create. Consider the scenario where an application may download large files over a slow connection. We may wish to display a placeholder and/or message to the user while the file is downloading, until the actual resource becomes available. A protection proxy controls access to a resource based on access rights. Imagine a design scenario of an online matchmaking service that exposes a "hot or not" feature. We wouldn't want a user to set the HotOrNot Rating for themselves. We could design a solution based on reflection that see who is invoking the method, and prohibit a user from calling this method. Feel free to download the slide deck here .

Next week is the final class session in this semester. I will be reviewing some previous patterns, as well as discussing compound patterns, including the MVC (model view controller).






 

 

What did you think of this article?




Trackbacks
Trackback specific URL for this entry
  • No trackbacks exist for this entry.
Comments
    • No comments exist for this entry.
Leave a comment

Submitted comments will be subject to moderation before being displayed.

 Enter the above security code (required)

 Name

 Email (will not be published)

 Website

Your comment is 0 characters limited to 3000 characters.