More often than not, an n-Tier has a tier that needs to communicate across a network. More often than not, network latency issues are beyond the control of the software development team. However, there are a few weapons in the software development arsenal that can at least mitigate the effect of a slooooow underlying network.
For example:
A persistence tier (like hibernate or nHibernate) needs to constantly talk to the data tier (such as a database) – which usually resides behind a firewall (possibly on a different domain / network altogether).
A service layer typically services multiple consumer layers (typically UI layers) – e.g. a WebAPI service layer could service an MVC web app as well as a WPF/WinForms based desktop app. The Service layer need not reside in the same domain as the presentation layer – leading to the need to send responses across a network.
What is common to these scenarios is the need for a tier to communicate with another tier across a network (potentially across firewalls).
This calls into play the available network bandwidth – as well as network availability – both of which can be unpredictable. It becomes imperative to design your software in a way that is bandwidth conscious – and works toward reducing the number of network calls. This involves :
a) Combining calls that are made by client objects to server objects (Facade pattern) as well as
b) Combining the data sent from the clients to the server (Data Transfer Object Pattern)
THE FAÇADE PATTERN
One of the most popular patterns to fine tune the NUMBER of cross network calls, a Facade (aka SESSION façade for web apps) reduces multiple network calls to the same server object. It combines multiple calls into one call (combines fine grained methods into a coarse grained larger method).
In OO terms, a Facade uses object composition to combine multiple systems into one class. The Code example below combines three subsystem calls into one call:
class Facade
{
private SubSystemOne _one;
private SubSystemTwo _two;
private SubSystemThree _three;
public Facade()
{
_one = new SubSystemOne();
_two = new SubSystemTwo();
_three = new SubSystemThree();
}
public int MethodCombo(float paramfloat, int paramint, string paramstring)
{
Console.WriteLine("\nMethodCombo() ---- ");
_one.MethodOne(paramfloat);
_two.MethodTwo(paramint);
return _three.MethodThree(paramstring);''
}
}
/// The 'Subsystem One Class' class
class SubSystemOne
{
public void MethodOne(float paramfloat)
{
Console.WriteLine(" SubSystemOne Method");
}
}
class SubSystemTwo
{
public void MethodTwo(int paramint)
{
Console.WriteLine(" SubSystemTwo Method");
}
}
class SubSystemThree
{
public int MethodThree(string paramstring)
{
Console.WriteLine(" SubSystemThree Method");
return Convert.ToInt32(paramstring);
}
}
}
THE DTO (DATA TRANSFER OBJECT) PATTERN
This pattern goes hand in hand with the Facade Pattern. If one is trying to turn multiple fine-grained calls into a larger single coarse grained call, one needs to combine various input and output parameters. In OO terms, simply define a DTO class that contains all the parameters needed for the coarse-grained (combo) service methods (as shown in the Facade example above).
public class DataTransferObject
{
public OutDTO Facade(InDTO params) {
OutDTO outout;
//code goes here
return output;
}
}
public class InDTO {
//a list of different parameters
private float paramfloat
private int paramint;
private String paramstring;
.
.
.
//getters and setters
}
public class OutDTO {
//a list o different parameters of any type
private int paramint;
}
SUMMARY
While troubleshooting performance of n-Tier applications, one has to consider network calls (excessive) between any two tiers as a potential bottleneck.
Often, overcoming the bandwidth limitation is not an option (due to network/ hardware restrictions). However, software can be designed to be more conscientious about the limited bandwidth – using patterns such as the Façade (session façade for web apps) and the Data Transfer Object (DTO) pattern.