Interoperability
ADO.NET
applications can take advantage of the flexibility and broad acceptance
of XML. Because XML is the format for transmitting datasets across the
network, any component that can read the XML format can process data. In
fact, the receiving component need not be an ADO.NET component at all:
The transmitting component can simply transmit the dataset to its
destination without regard to how the receiving component is
implemented. The destination component might be a Visual Studio
application or any other application implemented with any tool
whatsoever. The only requirement is that the receiving component be able
to read XML. As an industry standard, XML was designed with exactly
this kind of interoperability in mind.
Maintainability
In
the life of a deployed system, modest changes are possible, but
substantial, architectural changes are rarely attempted because they are
so difficult. That is unfortunate, because in a natural course of
events, such substantial changes can become necessary. For example, as a
deployed application becomes popular with users, the increased
performance load might require architectural changes.
As the performance load on a deployed application server grows, system resources can become scarce and response time or throughput can suffer. Faced with this problem, software architects can choose to divide the server's business-logic processing and user-interface processing onto separate tiers on separate machines. In effect, the application server tier is replaced with two tiers, alleviating the shortage of system resources.
The problem is not designing a three-tiered application. Rather, it is increasing the number of tiers after an application is deployed. If the original application is implemented in ADO.NET using datasets, this transformation is made easier. Remember, when you replace a single tier with two tiers, you arrange for those two tiers to trade information. Because the tiers can transmit data through XML-formatted datasets, the communication is relatively easy.
As the performance load on a deployed application server grows, system resources can become scarce and response time or throughput can suffer. Faced with this problem, software architects can choose to divide the server's business-logic processing and user-interface processing onto separate tiers on separate machines. In effect, the application server tier is replaced with two tiers, alleviating the shortage of system resources.
The problem is not designing a three-tiered application. Rather, it is increasing the number of tiers after an application is deployed. If the original application is implemented in ADO.NET using datasets, this transformation is made easier. Remember, when you replace a single tier with two tiers, you arrange for those two tiers to trade information. Because the tiers can transmit data through XML-formatted datasets, the communication is relatively easy.
Programmability
ADO.NET
data components in Visual Studio encapsulate data access functionality
in various ways that help you program more quickly and with fewer
mistakes. For example, data commands abstract the task of building and
executing SQL statements or stored procedures.
Similarly, ADO.NET
data classes generated by the designer tools result in typed datasets.
This in turn allows you to access data through typed programming. For
example, consider the following line of code that accesses a data member
in an untyped dataset:
Performance
For
disconnected applications, ADO.NET datasets offer performance
advantages over ADO disconnected recordsets. When using COM marshalling
to transmit a disconnected recordset among tiers, a significant
processing cost can result from converting the values in the recordset
to data types recognized by COM. In ADO.NET, such data-type conversion
is not necessary.
Scalability
Because
the Web can vastly increase the demands on your data, scalability has
become critical. Internet applications have a limitless supply of
potential users. Although an application might serve a dozen users well,
it might not serve hundreds —or hundreds of thousands — equally well.
An application that consumes resources such as database locks and
database connections will not serve high numbers of users well, because
the user demand for those limited resources will eventually exceed their
supply.
Source Collected from msdn
No comments :
Post a Comment