Let's go back for a moment to using ADO.NET. To read data from remote sources from a middle-tier component, you need to open a Connection object to each of the different data sources that you want to communicate with and query each one of them independently for the data that you want to extract.
As Figure 8-1 shows, when taking this approach, the middle-tier code has to deal with querying each of the different data sources using each data source's access API and merging the collected result sets into a single result set.
Figure 8-1. Architectural model for reading data from remote sources at the middle tier.
Reading Data from Remote Data Sources Using ADO.NET at the Middle Tier
Your middle-tier application must connect to each of the different data sources using the appropriate data access provider. For example:
Then your middle-tier application must use a DataSet object to hold all the data coming from the different data sources, as in the following code snippet. (The code in this section is included in the sample files as MiddleTier.vb.txt.)
Dim salesData as New DataSet() oracleDA.Fill(salesData) excelDA.Fill(salesData) sqlDA.Fill(salesData)
To summarize, by implementing the remote access at the middle tier, every time the sales data is required, the application needs to:
The middle tier deals with the fact that the data is distributed in different physical locations.
Sometimes merging the data in the middle tier is not as easy as shown in this example because it might come in different formats and representations. The code needed to manipulate heterogeneous data sources is not always the same in .NET Framework programming. For example, if you need to retrieve data from a text file, you probably would use the classes inside the System.IO namespace, but if you need to retrieve data from Active Directory, you probably would use the classes inside the System.DirectoryServices namespace. The programming model for the classes inside these two namespaces is very different.