Benefits of ADO.NET
ADO.NET offers several advantages over other data access solutions. These benefits fall into the following categories:
ADO.NET applications can take advantage of the flexibility and broad acceptance of XML. Because XML is the format for transmitting datasets among components and across tiers, any component that can read the XML format can process an ADO.NET dataset. As an industry standard, XML was designed with exactly this kind of interoperability in mind.
Programmers can manipulate objects of the ADO.NET model through typed programming. Typed programming is programming in which the types of things that are important to users are recognized by the programming environment or by the programming language itself.
For example, consider the following line of code, which uses generic (non-typed) programming:
If TotalCost > Table("Customer").Column("AvailableCredit")
The code contains words such as "Customer" and "Available Credit" that are interesting to the end user, but it also exposes implementation details, such as "Table" and “Column."
In a nutshell, typed programming is a style of programming in which the end-user words figure prominently to convey business logic. For example, consider this next line of code, which uses typed programming in ADO.NET:
If TotalCost > DataSet1.Customer("Jones").AvailableCredit
This line of code is equivalent to the earlier line that used non-typed programming. In the typed code, the code is easier to read: A business analyst with little or no programming experience can grasp the meaning of the condition being tested without having to filter out the programmer vocabulary in the conventional line of code.
The typed code is also easier to write, because statement completion is provided. For example, "AvailableCredit" is among the list of choices for completing the following statement:
IF TotalCost > Customer.
In addition, the typed code is safer, because it provides for the compile-time checking of types. For example, suppose that AvailableCredit is expressed as a currency value. If the programmer erroneously assigns a string value to AvailableCredit, the typed environment reports the error to the programmer during compile time. In a weakly typed programming environment, the programmer would not learn of the error until run time.
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.
Because any ADO.NET application employs disconnected access to data, it does not retain database locks or active database connections for long durations and offers performance advantages.
The .NET Framework security system provides fine-grained, method-level control over what applications can and can’t do based on who wrote the code, what it’s trying to do, where it was installed from, and who is trying to run it.
The .NET Framework security infrastructure encompasses features to handle both authentication of users and code access security that enforces security permissions on code based on trust policy. An extensible library of cryptographic functions provides easy access to hashing and encryption from managed code, including digital signatures for XML. All existing security mechanisms in the platform exist with and provide the foundation for on which.NET Framework builds.
The .NET Framework offers security through two high-level categories: code access security and role-based security. Code access security is the mechanism by which developers can specify the level of access their code should have to resources and operations. Role-based security is used for controlling permissions based on the user identity.
Code access security is deeply integrated into the .NET Framework, and it provides security enforcement of different levels of trust on different code—even different pieces of code within the same running application. For example, code from the Internet should be trusted less than code from a reliable vendor. Many security problems result from less trusted code getting outside the confines meant to secure it. Since the runtime has control of execution of all managed code, it continues to enforce restrictions for anything the less trusted code might do.
Code access security is built on an evidence-based security policy system that grants to code the appropriate permissions. A permission object represents the right to do some operation—for example, to write a file, to display on the screen, and so forth. The evidence for any code—its location, digital signature, and so forth—is presented to the security policy system for it to make a trust decision based on policy established by the administrator. If an application attempts to perform a protected operation, a security check will demand that the code and all of its callers have the necessary permissions to perform that operation. The check of all callers is important to prevent less trusted code from somehow tricking more trusted code into performing a privileged operation. The .NET Framework can force managed code to pass a process called verification to enforce security on it. Verification ensures that the code uses only well-defined interfaces in interacting with other objects, which prevents access to unauthorized memory.
Role-based security is based on two fundamental concepts: authentication and authorization. Authentication is the process of validating a set of user credentials against an authority. If the credentials are valid, that user is said to have an identity. Authorization is the process of using that identity to grant access to or protect a resource.
Applications can authenticate users with any authentication protocol, including Basic, Digest, Microsoft Passport, Integrated Windows authentication (formerly known as Microsoft Windows NT® LAN Manager, or NTLM, which supports Kerberos), or forms-based authentication. The application program is written the same way no matter what type of authentication is used. Moreover, additional user-defined authentication providers can be plugged into this uniform architecture if needed. For example, a customer database with user names and passwords can easily be used as a new authentication provider.
A cryptographic library provides easy-to-use hash, encryption, decryption, and random number generation. Encryption support for several symmetric and asymmetric algorithms is included. In addition, Microsoft is tracking the emerging XML digital signature standards work and will have methods to sign and verify signed XML.