|only for RuBoard|
With evolution comes new, and often great things. Such is the case with the evolution of ADO into ADO.NET. The prime benefits can be broken down into five categories: Interoperability, Maintainability, Programmability, Performance, and Scalability.
As XML becomes more widely accepted, the benefits of the XML-based persistence and transmission of ADO.NET become more obvious. ADO.NET is designed to take advantage of the acceptance of XML. Because the work being done out-of-sight, out-of-mind is in XML, any component that can parse XML can use ADO.NET. Programming languages and lack of compatibility no longer stand in the way. With ADO.NET, a PERL component can pass an ADO.NET DataSet to a C# component, which can manipulate it and pass it to an ASP.NET Web Form written in Visual Basic.NET. Throughout the whole process, the data is transmitted as an XML file and materialized as a DataSet without need for concern.
Even if the component being used cannot parse XML, that component can still play a part. Since the DataSet is being transmitted as an XML file, it can be saved to the file system or retransmitted to another component without doing any damage to the file.
The Web and Internet exchange have come a long way since they became widely accepted by the non-programmer community. Every day more and more people get on the Internet, and every day businesses around the world need to find ways to maintain their Web site infrastructure to handle the increased traffic. Commonly, they do this by dividing the Web site structure into layers to even out the processing demand across multiple servers. Perhaps the presentation processing, business logic, and data services are all moved to separate servers, as in typical three- tier architecture. Maybe the business logic layer is subdivided to multiple servers.
Using ADO.NET makes this type of division a little easier. The layers of the solution must be able to communicate. With ADO.NET, they can communicate through XML-based DataSet s, making the communication a little less painful.
ADO.NET enables developers to write code against data using strong-typed programming, in which things of interest to the user become more evident. In traditional weak-typed programming, the things most important to the developer become more evident, such as the table and cells in the following example:
AcctNum = Table("Customer").Cells("AccountNumber")
ADO.NET enables programmers to manipulate data through strong-typed programming. Under this style, the AccountNumber becomes a property of the Customer object. From a programmer's point of view, Customer might refer to a DataTable and AccountNumber might refer to a DataColumn of that table.
AcctNum = Customer.AccountNumber
This type of programming makes the vocabulary more evident, making the code easier to read. A non-programmer could look at this code and infer it's meaning easily.
As well as being easier to read, strong-typed code is easier to write. Among the benefits are the possibilities of automatic statement completion in a code editor. When the programmer types the following, a drop-down list appears, and AccountNumber is one of the options to be selected, as seen in Figure 2.2:
AcctNum = Customer.
Web applications are inherently disconnected; the client does not maintain an active connection to the server, and the server does not maintain an active connection to the data source. ADO.NET DataSet s offer performance advantages over traditional ADO disconnected RecordSet s. In the past, when data was passed from one component to another, the application's performance took a heavy hit due to the cost of COM marshalling. The values in the RecordSet had to be converted to data types recognized by COM. As a result, there was a significant processing cost. In ADO.NET, this data type conversion isn't required because you're simply passing an XML file.
In any Web solution, scalability is a huge concern. Everyone wants Web traffic to increase, and as it does the solution needs to accommodate the higher levels of throughput. Often, applications will perform well for a small number of users, instilling a false sense of confidence. As the user base grows, application performance can suffer because the users are fighting over a limited number of resources, such as database connections, records locked by other users, etc.
ADO.NET inherently encourages you to work in a disconnected manner, retrieving the data that is required and releasing the resources immediately. Because you can pull your data into a disconnected DataSet in the form of an XML file, scalability is increased without the need for additional hardware. Database locks and active connections are released, giving additional users access to the resources.
|only for RuBoard|