Real-Time Examples of Remote Proxy Design Pattern in C#

Back to: Design Patterns in C# With Real-Time Examples

Real-Time Examples of Remote Proxy Design Pattern in C#

In this article, I will discuss Real-Time Examples of Remote Proxy Design Patterns in C#. Please read our previous article discussing Real-Time Examples of the Virtual Proxy Design Pattern in C#. At the end of this article, you will understand the following pointers.

What is the Remote Proxy Design Pattern in C#?
Multiple Real-Time Examples of the Remote Proxy Design Pattern in C#
Advantages and Disadvantages of Remote Proxy Design Pattern in C#
When to use the Remote Proxy Design Pattern in C#?

Remote Proxy Design Pattern in C#:

The Remote Proxy design pattern provides a local representative for an object that resides in a different address space. This is often used in distributed systems, where objects must communicate across network boundaries, like web or remote services. Here’s a simple example illustrating the Remote Proxy pattern in the context of a hypothetical service that retrieves user data:

Subject Interface:

The common interface is implemented by both the Real Subject and the Proxy.

using System;
namespace RemoteProxyDesignPattern
{
    public interface IUserService
    {
        string GetUserName(int userId);
    }
}

Real Subject:

This would be the actual implementation if it were local. For our purposes, let’s imagine this is what the remote service would implement.

namespace RemoteProxyDesignPattern
{
    public class RealUserService : IUserService
    {
        public string GetUserName(int userId)
        {
            // In a real-world scenario, this might pull data from a database.
            return $"User_{userId}";
        }
    }
}

Remote Proxy:

This represents the local object that calls the remote service. Let’s pretend that RemoteMethodCall simulates the remote call.

namespace RemoteProxyDesignPattern
{
    public class RemoteUserServiceProxy : IUserService
    {
        public string GetUserName(int userId)
        {
            // Simulate a remote call to the real service
            return RemoteMethodCall(userId);
        }

        private string RemoteMethodCall(int userId)
        {
            // In a real-world scenario, this would involve networking code
            // that communicates with the remote service.
            // For simplicity, we'll simulate a remote call here.

            RealUserService remoteService = new RealUserService();
            return remoteService.GetUserName(userId);
        }
    }
}

Client Code:

using System;
namespace RemoteProxyDesignPattern
{
    // Testing Remote Proxy Design Pattern
    public class Program
    {
        public static void Main()
        {
            IUserService userService = new RemoteUserServiceProxy();
            string userName = userService.GetUserName(1);
            Console.WriteLine($"Received username: {userName}");
            Console.ReadKey();
        }
    }
}

In this example, when the client code calls the GetUserName method on the RemoteUserServiceProxy, the proxy communicates with the RealUserService to get the data. The RealUserService here is a stand-in for a remote service. In a real-world application, the proxy and the real service communication would likely be through protocols like HTTP, gRPC, or some other remote communication method.

The key idea behind the Remote Proxy pattern is to provide a local object that abstracts and manages the complexities of remote communication, making it appear as though the actual object is local.

Real-Time Example of Remote Proxy Design Pattern in C#

One real-world example of the Remote Proxy design pattern can be seen in web service or API clients. These clients act as local representatives or proxies for remote services. The client-side applications interact with these proxies as local objects, but they manage the communication with the remote service behind the scenes.

Let’s look at a practical example: Imagine you have a weather service that provides current weather information for any city. This service is hosted remotely and exposes an API for consumers.

using System;
using System.Net.Http;

namespace RemoteProxyDesignPattern
{
    //Subject Interface
    public interface IWeatherService
    {
        string GetCurrentWeather(string city);
    }

    //Remote Proxy:
    //This will interact with the remote weather service using an HTTP client.
    public class WeatherServiceProxy : IWeatherService
    {
        private readonly HttpClient _httpClient;
        private const string baseUrl = "https://weatherapi.example.com";

        public WeatherServiceProxy()
        {
            _httpClient = new HttpClient();
        }

        public string GetCurrentWeather(string city)
        {
            var response = _httpClient.GetStringAsync($"{baseUrl}/current?city={city}").Result;
            return response; // This might return a JSON string which can be further deserialized.
        }
    }
    
    // Testing Remote Proxy Design Pattern
    public class Program
    {
        public static void Main()
        {
            IWeatherService weatherService = new WeatherServiceProxy();
            string weather = weatherService.GetCurrentWeather("London");
            Console.WriteLine($"Current weather in London: {weather}");
            Console.ReadKey();
        }
    }
}

In this example:

The WeatherServiceProxy acts as the Remote Proxy.
It encapsulates the logic required to communicate with the remote weather service (like making an HTTP request).
The client code remains clean and focused on its logic, oblivious to the intricacies of network communication, endpoint URLs, HTTP methods, etc.
The actual weather service (the Real Subject in proxy pattern terminology) can be imagined to be a RESTful API hosted on a remote server.

This pattern is common in many modern applications, especially those consuming microservices, third-party APIs, or cloud-based services. It abstracts away the remote communication details and provides the client with a more straightforward, object-oriented interface.

Real-Time Example of Remote Proxy Design Pattern in C#

Let’s understand another real-time example of the Remote Proxy Design Pattern using the context of accessing a remote book inventory system. Imagine a scenario where a bookstore wants to check the availability of a specific book, but the inventory system is hosted remotely.

using System;
using System.Net.Http;

namespace RemoteProxyDesignPattern
{
    //Subject Interface:
    //This is the common interface that both the real subject and the proxy will implement.
    public interface IBookInventory
    {
        int GetAvailableCopies(string isbn);
    }

    //Real Subject (remote system):
    //Although you typically wouldn't have direct access to the real subject in a remote proxy setup, 
    //for the sake of understanding, let's visualize the real system:
    // This represents the actual remote inventory system
    public class RemoteBookInventory : IBookInventory
    {
        public int GetAvailableCopies(string isbn)
        {
            // Logic to retrieve book information from a remote database
            // For simplicity, let's assume a hardcoded value.
            return 10;
        }
    }

    //Remote Proxy:
    //This is the local representative for the remote service.
    public class BookInventoryProxy : IBookInventory
    {
        private readonly HttpClient _httpClient;
        private const string serviceUrl = "https://remotebookinventory.com/api";

        public BookInventoryProxy()
        {
            _httpClient = new HttpClient();
        }

        public int GetAvailableCopies(string isbn)
        {
            var response = _httpClient.GetStringAsync($"{serviceUrl}/availableCopies?isbn={isbn}").Result;
            return int.Parse(response);
        }
    }

    //Client Code
    //This is the bookstore trying to fetch the availability of a book.
    // Testing Remote Proxy Design Pattern
    public class Program
    {
        public static void Main()
        {
            IBookInventory inventory = new BookInventoryProxy();
            int copies = inventory.GetAvailableCopies("978-1234567890");
            Console.WriteLine($"Available copies: {copies}");
            Console.ReadKey();
        }
    }
}

Explanation:

The bookstore wants to know how many copies of a particular book are available. Instead of connecting directly to the remote system, it uses the BookInventoryProxy.
This proxy abstracts the complexities of making a network call to the remote inventory system. When the bookstore asks the proxy for the number of available copies, the proxy makes an HTTP call to the remote service, fetches the data, and returns it to the bookstore.
Here, HttpClient is utilized to simulate network communication. A real-world scenario might involve additional considerations like error handling, timeouts, and authentication.

This pattern is quite common in systems integration scenarios. For instance, when your local system needs to fetch data from a remote system, SDKs provided by services (like AWS SDK, Azure SDK, etc.) often employ this pattern internally. They give your local classes (proxies) to interact with, which, under the hood, manage all the complexities of network communication, serialization, error handling, and more.

Advantages and Disadvantages of Remote Proxy Design Pattern in C#

The Remote Proxy design pattern is a structural pattern that allows for objects to be represented and interacted with as if they are local when, in reality, they exist in a different address space, often on a remote server. Here are the advantages and disadvantages of the Remote Proxy design pattern:

Advantages of Remote Proxy Design Pattern in C#:

Abstraction of Remote Logic: The client code interacts with the proxy object without knowing the intricacies of remote communication, such as network protocols, serialization, error handling, etc.
Centralization of Remote Access: By centralizing remote calls within the proxy, it’s easier to maintain and modify the communication logic, such as changing the endpoint, updating authentication mechanisms, etc.
Separation of Concerns: The client code focuses on the business logic while the proxy manages the communication logic, promoting clean code and the Single Responsibility Principle.
Flexibility: Proxies can provide additional functionalities, like caching, logging, and monitoring, without altering the remote service.
Consistency: The proxy ensures that all remote calls adhere to specific protocols, standards, and practices, ensuring consistent communication.
Security: The proxy can act as an intermediary layer, providing authentication and authorization checks before forwarding requests to the remote service.

Disadvantages of Remote Proxy Design Pattern in C#:

Additional Complexity: Introducing proxies means an additional layer in your application, which can increase the overall complexity.
Performance Overhead: The proxy introduces a level of indirection, leading to slightly increased latency, especially if not optimized or if additional logic (like logging or caching) is added.
Maintenance Overhead: Both the proxy and the remote service need maintenance, which can be challenging if they evolve independently.
Dependency on Network Reliability: If the network is unreliable, the remote proxy might face frequent communication issues, leading to failures in the client application.
Serialization Overhead: when communicating between the proxy and the remote service, data must often be serialized and deserialized. This can introduce performance and data integrity issues.
Harder Debugging: When issues arise, it can be challenging to discern if the problem is within the proxy, the network, or the remote service.

The Remote Proxy pattern is a powerful tool for abstracting away the complexities of remote communication. However, like any design pattern, its appropriateness depends on the specific problem being addressed. When dealing with distributed systems where local representations of remote objects can simplify client code, the Remote Proxy pattern shines. However, it’s essential to be aware of the potential pitfalls, especially performance and maintenance.

When to use Remote Proxy Design Pattern in C#

The Remote Proxy Design Pattern plays a crucial role in various scenarios where an object needs a representative or placeholder to control access to it. This pattern can be extremely beneficial for remote objects in distributed systems. Here’s when to consider using the Remote Proxy Design Pattern in C# (or any other programming language):

Distributed Systems:

Network Communication: When objects need to communicate over a network, you want to abstract away the network communication details, like handling TCP/UDP connections, HTTP requests, or data serialization.
Resource Intensive Operations: If the client-side application can’t afford the resources (memory, CPU) needed to handle certain objects, a proxy residing closer to the resource can be beneficial.

Access Control:

Authentication and Authorization: If certain objects should only be accessed with the proper permissions, a proxy can manage authentication and authorization checks before forwarding requests.

Logging and Audit:

Request Logging: When you want to keep a log of all interactions with an object, a proxy allows you to add logging mechanisms without modifying the actual object’s code.
Usage Metrics: If you need to monitor or gather usage metrics, a proxy can record and report usage details like which methods are being called, by whom, and how often.

Caching:

Response Caching: If repeated calls to certain methods are expensive in terms of time or resources and if the responses don’t change often, a proxy can cache responses and serve subsequent requests from the cache.

Lazy Initialization:

Resource Optimization: When an object is expensive to create and isn’t always needed, a proxy can manage the instantiation of that object and create it only when it’s needed.

Interface Compatibility:

Adaptation: When an object’s interface doesn’t align with the client’s expectations or needs, a proxy can translate or adapt the interface to something the client can work with.

Life-cycle Management:

Reference Counting: A proxy can keep track of the number of references to an object and manage the object’s life cycle, potentially deallocating it when it’s no longer needed.

Real-Time Interaction:

Asynchronous Operation: When working with asynchronous operations, a proxy can manage the operation (like sending requests, handling responses, etc.) while the client continues its work without waiting.

Examples in C# Applications:

WCF Services: In Windows Communication Foundation (WCF), proxies are automatically generated to provide access to remote services.
Web API Clients: When creating HTTP clients for RESTful services (like using HttpClient), encapsulating remote access logic within a proxy class is a common practice.
Middleware: Middleware in ASP.NET Core can be considered a series of proxies that handle requests and responses, adding functionalities like logging, caching, and authentication in a modular manner.

While the Remote Proxy Pattern is extremely useful in the aforementioned scenarios, it’s vital to ensure that it doesn’t introduce unnecessary complexity. It’s crucial to evaluate whether the abstraction provided by the proxy genuinely simplifies development and maintenance without introducing undue overhead or complexity.

In the next article, I will discuss the Real-Time Examples of Cache Proxy Design Patterns in C#. Here, in this article, I try to explain the Real-Time Examples of Remote Proxy Design Patterns in C#. I hope you enjoy this Remote Proxy Design Pattern in Real-time Examples using the C# article.

Dot Net Tutorials

About the Author: Pranaya Rout

Pranaya Rout has published more than 3,000 articles in his 11-year career. Pranaya Rout has very good experience with Microsoft Technologies, Including C#, VB, ASP.NET MVC, ASP.NET Web API, EF, EF Core, ADO.NET, LINQ, SQL Server, MYSQL, Oracle, ASP.NET Core, Cloud Computing, Microservices, Design Patterns and still learning new technologies.