a.Remote Facade Pattern

Motivation
1. 1. To reduce complexity of web service interface or object model.
  2. Provides a coarse-grained facade on fine-grained objects to improve efficiency over a network.
  3. Implemented as webservice.
Summary

- 1. A Remote Facade is a coarse-grained facade [Gang of Four] over a web of fine-grained objects.
  2. None of the fine-grained objects have a remote interface, and the Remote Facade contains no domain logic.
  3. All the Remote Facade does is translate coarse-grained methods onto the underlying fine-grained objects.
  4. In a simple case, like an address object, a Remote Facade replaces all the getting and setting methods of the regular address object with one getter and one setter, often referred to as bulk accessors.

- 1. Use Remote Facade whenever you need remote access to a fine-grained object model. You gain the advantages of a coarse-grained interface while still keeping the advantage of fine-grained objects, giving you the best of both worlds.
  2. The most common use of this pattern is between a presentation and a Domain Model.
  3. Most often you run into this with different processes on different machines.
  4. If all your access is within a single process, you don't need this kind of conversion. Thus, I wouldn't use this pattern.

- 1. Service Facade : It is an SOA patterns that further extend Remote Facade.
  2. Service Layer: Similar pattern but contains domain logic.

1. Remote Facade and State
  1. 1. Remote Facade can be stateful or stateless. A stateless Remote Facade can be pooled, which can improve resource usage and efficiency, especially in a B2C situation. However, if the interaction involves state across a session, then it needs to store session state somewhere using Client Session State or Database Session State, or an implementation of Server Session State.
    2. As stateful a Remote Facade can hold on to its own state, which makes for an easy implementation of Server Session State, but this may lead to performance issues when you have thousands of simultaneous users.
2. Remote Facade and Domain Logic

- - 1. "Remote Facade has no domain logic."
    2. Any facade should be a thin skin that has only minimal responsibilities.

- 1. Remote Facade and Session Facade
    1. Session Facade as putts several Transaction Scripts in a remote interface hence it shouldn't be called a facade at all!
  2. Remote Facade Vs Service Layer

- - 1. Concept of Service Layer is similar to facades. The main difference is that a service layer doesn't have to be remote and thus doesn't need to have only fine-grained methods.
    2. In simplifying the Domain Model, you often end up with coarser-grained methods, but that's for clarity, not for network efficiency. Furthermore, there's no need for a service layer to use Data Transfer Objects (401). Usually it can happily return real domain objects to the client.
    3. If a Domain Model is going to be used both within a process and remotely, you can have a Service Layer and layer a separate Remote Facade on top of it. If the process is only used remotely, it's probably easier to fold the Service Layer into the Remote Facade, providing the Service Layer has no application logic. If there's any application logic in it, then I would make the Remote Facade a separate object.

- - 1. Service Facade is actually a SOA pattern and it further extend Remote Facade