Data Access in ADO.NET relies on two components: DataSet and Data Provider.
DataSet
The dataset is a disconnected, in-memory representation of data. It can be considered as a local copy of the relevant portions of the database. The DataSet is persisted in memory and the data in it can be manipulated and updated independent of the database. When the use of this DataSet is finished, changes can be made back to the central database for updating. The data in DataSet can be loaded from any valid data source like Microsoft SQL server database, an Oracle database or from a Microsoft Access database.
Data Provider
The Data Provider is responsible for providing and maintaining the connection to the database. A DataProvider is a set of related components that work together to provide data in an efficient and performance driven manner. The .NET Framework currently comes with two DataProviders: the SQL Data Provider which is designed only to work with Microsoft's SQL Server 7.0 or later and the OleDb DataProvider which allows us to connect to other types of databases like Access and Oracle. Each DataProvider consists of the following component classes:
The Connection object which provides a connection to the database
The Command object which is used to execute a command
The DataReader object which provides a forward-only, read only, connected recordset
The DataAdapter object which populates a disconnected DataSet with data and performs update
Sunday, October 28, 2007
ADO.Net Overview
Most applications need data access at one point of time making it a crucial component when working with applications. Data access is making the application interact with a database, where all the data is stored. Different applications have different requirements for database access. VB .NET uses ADO .NET (Active X Data Object) as it's data access and manipulation protocol which also enables us to work with data on the Internet. Let's take a look why ADO .NET came into picture replacing ADO
ADO.NET provides consistent access to data sources such as Microsoft SQL Server, as well as data sources exposed through OLE DB and XML. Data-sharing consumer applications can use ADO.NET to connect to these data sources and retrieve, manipulate, and update data.
ADO.NET cleanly factors data access from data manipulation into discrete components that can be used separately or in tandem. ADO.NET includes .NET Framework data providers for connecting to a database, executing commands, and retrieving results. Those results are either processed directly, or placed in an ADO.NET DataSet object in order to be exposed to the user in an ad-hoc manner, combined with data from multiple sources, or remoted between tiers. The ADO.NET DataSet object can also be used independently of a .NET Framework data provider to manage data local to the application or sourced from XML.
ADO.NET provides consistent access to data sources such as Microsoft SQL Server, as well as data sources exposed through OLE DB and XML. Data-sharing consumer applications can use ADO.NET to connect to these data sources and retrieve, manipulate, and update data.
ADO.NET cleanly factors data access from data manipulation into discrete components that can be used separately or in tandem. ADO.NET includes .NET Framework data providers for connecting to a database, executing commands, and retrieving results. Those results are either processed directly, or placed in an ADO.NET DataSet object in order to be exposed to the user in an ad-hoc manner, combined with data from multiple sources, or remoted between tiers. The ADO.NET DataSet object can also be used independently of a .NET Framework data provider to manage data local to the application or sourced from XML.
Friday, October 19, 2007
ASP.Net State Managment
Application
Application object was generally used when some data was to be stored which all users could use. The size of the data was not really a constraint since there would be only a single copy of that data. The data would be stored for the life of the application. In ASP 3.0, the Application object was generally used to store pieces of data that changed rarely such as contents of menu or Database connection strings (mainly read only data).
In ASP.NET, such configuration data as database connection strings are best stored in config files. One thing to consider if you are using the Application object is that any writes to it should be done either in its Application_OnStart event (in global.asax). Since the config files are XML files, they can be changed whenever required.
Session
Session data is valid only for a particular user session. The size of data is again not a constraint, but it is to be kept to a minimum to make the application more scalable.
The major disadvantages with Session was that it uses cookies and in ASP 3.0, it tied the user to one particular Web Server since session data could not shared in Web farms or a clustered environment. With ASP.NET, storing sessions on an external state server or a database for managing session data.
Even then, Session object is inefficient way to store data since the data is still stored in memory even after the user has stopped using the site. This can affect the scalability on busy web sites. The Cache object allows more control on release of memory and is more suited for large data values. However, For small amounts of data, the Session object can be a perfectly valid place to store user-specific data that needs to persist only for the duration of the user's current session.
Even when not in use, sessions carry some overhead for an application. Performance can be enhanced if session is turned off on pages, which don’t use them. Also, setting session state to read-only can also optimize pages that read but do not write data to sessions.
Cookies
The biggest advantage of cookies is that the data can be persisted for a variable amount of time. The data can be persisted with for the life of the browser window or if required, for months or years. Cookies are generally very small since they are maintained on the client and have to be transferred to the server whenever that data is required. Hence the contents should be as less as possible. It is a powerful way to maintain state even in clustered environment or a web farm, which is the reason why most web sites on the net use them.
Cookies are small text files kept on the client machine which can be easily deleted by the user plus the contents are not encrypted, hence sensitive information should never be stored in cookies.
Hidden Form Fields
Hidden Form fields sent with the posting of form to the server is generally used to store user specific data. The size of the data is not a constraint. This technique was used more often than not in ASP 3.0, but now made redundant by the new techniques introduced in ASP.NET like Web Controls and ViewState. These techniques are discussed further.
QueryString
QueryStrings like hidden form fields are user specific data. Its lifecycle can be as brief as a single request or it can be maintained through out the application. The size of the data is a major constraint, it cannot be more than 1K. Another major constraint is that, since the data is passed with the URL , the data is visible to the user and hence no sensitive information is stored in QueryStrings unless it is encrypted to remove human-readability. Also, Server.UrlEncode should be used to encode characters that are not valid in URLs. However, they still continue to be a very good alternative to pass information between page requests. DataGrids, which is a ASP.NET web control uses querystrings in it’s hyperlink columns.
For long-term data storage, Cookie, Session, or Cache are more appropriate options than QueryStrings.
New State Management techniques with ASP.NET
Cache
Cache data is specific to the single user, a subset of users, or even all users. This data persists for multiple requests. It can persist for a long time, but not across application restarts. Also, data can expire based on time or other dependencies. It can hold both large and small amounts of data effectively.
It offers incredible flexibility, versatility, and performance, and is therefore often a better choice than Application or Session for persisting data within an ASP.NET application. It is simply a name-value collection, but by using a key value that is specific to a user, you can make the cached values user-specific. The data in the Cache can be given an expiration period that is absolute, sliding, or based on changes to a file. One of the more powerful features of the Cache object is its ability to execute a callback when an item in the cache expires.
The Cache object has a lot more functionality than most of the other objects.
Context
The Context object holds data for a single user, for a single request, and it is only persisted for the duration of the request. The Context container can hold large amounts of data, but typically it is used to hold small pieces of data because it is often implemented for every request through a handler in the global.asax.
ViewState
ViewState is again a user specific technique and is valid for a particular ASPX page. It can hold any amount of data but it should be kept to the minimum it adds to the size of end HTML to the client browser.
Web Controls use View State to automatically maintain state between requests to the same page. The size of the ViewState can be seen by viewing the source of the page and checking for the hidden form field “__VIEWSTATE”. By default, the ViewState is turned ON, so it should be turned OFF for all web controls, that don’t need their data to be persisted across requests. ViewState can also be disabled for an entire page by adding EnableViewState="false" to the @Page directive.
Web.config and Machine.config Files
These files are basically XML files. The data in these files is common for the entire application, which is available for the entire life of the application. The size of the data is usually limited. Configuration settings are best kept in these files. Each ASP.NET application uses a Web.config file to set many of its properties, and each server has a Machine.config file located in its system folder that is used as a basis for all applications. These settings are used as defaults unless overridden. Configuration information is read whenever the application starts, and is then cached. Since it is cached, the application can read this data very quickly, so you should not be concerned that your application will have a bottleneck because it has to constantly refer to a text file for some integral information. Any changes to the config files are reflected only on application restart. Database connection information, default image paths, and paths to XML data files are some of the more common pieces of data that are stored in the Web.config file.
Application object was generally used when some data was to be stored which all users could use. The size of the data was not really a constraint since there would be only a single copy of that data. The data would be stored for the life of the application. In ASP 3.0, the Application object was generally used to store pieces of data that changed rarely such as contents of menu or Database connection strings (mainly read only data).
In ASP.NET, such configuration data as database connection strings are best stored in config files. One thing to consider if you are using the Application object is that any writes to it should be done either in its Application_OnStart event (in global.asax). Since the config files are XML files, they can be changed whenever required.
Session
Session data is valid only for a particular user session. The size of data is again not a constraint, but it is to be kept to a minimum to make the application more scalable.
The major disadvantages with Session was that it uses cookies and in ASP 3.0, it tied the user to one particular Web Server since session data could not shared in Web farms or a clustered environment. With ASP.NET, storing sessions on an external state server or a database for managing session data.
Even then, Session object is inefficient way to store data since the data is still stored in memory even after the user has stopped using the site. This can affect the scalability on busy web sites. The Cache object allows more control on release of memory and is more suited for large data values. However, For small amounts of data, the Session object can be a perfectly valid place to store user-specific data that needs to persist only for the duration of the user's current session.
Even when not in use, sessions carry some overhead for an application. Performance can be enhanced if session is turned off on pages, which don’t use them. Also, setting session state to read-only can also optimize pages that read but do not write data to sessions.
Cookies
The biggest advantage of cookies is that the data can be persisted for a variable amount of time. The data can be persisted with for the life of the browser window or if required, for months or years. Cookies are generally very small since they are maintained on the client and have to be transferred to the server whenever that data is required. Hence the contents should be as less as possible. It is a powerful way to maintain state even in clustered environment or a web farm, which is the reason why most web sites on the net use them.
Cookies are small text files kept on the client machine which can be easily deleted by the user plus the contents are not encrypted, hence sensitive information should never be stored in cookies.
Hidden Form Fields
Hidden Form fields sent with the posting of form to the server is generally used to store user specific data. The size of the data is not a constraint. This technique was used more often than not in ASP 3.0, but now made redundant by the new techniques introduced in ASP.NET like Web Controls and ViewState. These techniques are discussed further.
QueryString
QueryStrings like hidden form fields are user specific data. Its lifecycle can be as brief as a single request or it can be maintained through out the application. The size of the data is a major constraint, it cannot be more than 1K. Another major constraint is that, since the data is passed with the URL , the data is visible to the user and hence no sensitive information is stored in QueryStrings unless it is encrypted to remove human-readability. Also, Server.UrlEncode should be used to encode characters that are not valid in URLs. However, they still continue to be a very good alternative to pass information between page requests. DataGrids, which is a ASP.NET web control uses querystrings in it’s hyperlink columns.
For long-term data storage, Cookie, Session, or Cache are more appropriate options than QueryStrings.
New State Management techniques with ASP.NET
Cache
Cache data is specific to the single user, a subset of users, or even all users. This data persists for multiple requests. It can persist for a long time, but not across application restarts. Also, data can expire based on time or other dependencies. It can hold both large and small amounts of data effectively.
It offers incredible flexibility, versatility, and performance, and is therefore often a better choice than Application or Session for persisting data within an ASP.NET application. It is simply a name-value collection, but by using a key value that is specific to a user, you can make the cached values user-specific. The data in the Cache can be given an expiration period that is absolute, sliding, or based on changes to a file. One of the more powerful features of the Cache object is its ability to execute a callback when an item in the cache expires.
The Cache object has a lot more functionality than most of the other objects.
Context
The Context object holds data for a single user, for a single request, and it is only persisted for the duration of the request. The Context container can hold large amounts of data, but typically it is used to hold small pieces of data because it is often implemented for every request through a handler in the global.asax.
ViewState
ViewState is again a user specific technique and is valid for a particular ASPX page. It can hold any amount of data but it should be kept to the minimum it adds to the size of end HTML to the client browser.
Web Controls use View State to automatically maintain state between requests to the same page. The size of the ViewState can be seen by viewing the source of the page and checking for the hidden form field “__VIEWSTATE”. By default, the ViewState is turned ON, so it should be turned OFF for all web controls, that don’t need their data to be persisted across requests. ViewState can also be disabled for an entire page by adding EnableViewState="false" to the @Page directive.
Web.config and Machine.config Files
These files are basically XML files. The data in these files is common for the entire application, which is available for the entire life of the application. The size of the data is usually limited. Configuration settings are best kept in these files. Each ASP.NET application uses a Web.config file to set many of its properties, and each server has a Machine.config file located in its system folder that is used as a basis for all applications. These settings are used as defaults unless overridden. Configuration information is read whenever the application starts, and is then cached. Since it is cached, the application can read this data very quickly, so you should not be concerned that your application will have a bottleneck because it has to constantly refer to a text file for some integral information. Any changes to the config files are reflected only on application restart. Database connection information, default image paths, and paths to XML data files are some of the more common pieces of data that are stored in the Web.config file.
Advantages of ASP.NET
- Separation of Code from HTMLTo make a clean sweep, with ASP.NET you have the ability to completely separate layout and business logic. This makes it much easier for teams of programmers and designers to collaborate efficiently. This makes it much easier for teams of programmers and designers to collaborate efficiently.
- Support for compiled languagesdeveloper can use VB.NET and access features such as strong typing and object-oriented programming. Using compiled languages also means that ASP.NET pages do not suffer the performance penalties associated with interpreted code. ASP.NET pages are precompiled to byte-code and Just In Time (JIT) compiled when first requested. Subsequent requests are directed to the fully compiled code, which is cached until the source changes.
- Use services provided by the .NET FrameworkThe .NET Framework provides class libraries that can be used by your application. Some of the key classes help you with input/output, access to operating system services, data access, or even debugging. We will go into more detail on some of them in this module.
- Graphical Development EnvironmentVisual Studio .NET provides a very rich development environment for Webdevelopers. You can drag and drop controls and set properties the way you do in Visual Basic 6. And you have full IntelliSense support, not only for your code, but also for HTML and XML.
- State managementTo refer to the problems mentioned before, ASP.NET provides solutions for session and application state management. State information can, for example, be kept in memory or stored in a database. It can be shared across Web farms, and state information can be recovered, even if the server fails or the connection breaks down.
- Update files while the server is running!Components of your application can be updated while the server is online and clients are connected. The Framework will use the new files as soon as they are copied to the application. Removed or old files that are still in use are kept in memory until the clients have finished.
- XML-Based Configuration FilesConfiguration settings in ASP.NET are stored in XML files that you can easily read and edit. You can also easily copy these to another server, along with the other files that comprise your application.
Monday, October 15, 2007
What is Microsoft.NET platform?
Microsoft .NET is a software development platform based on virtual machine based architecture. Dot net is designed from the scratch to support programming language independent application development. The entire .NET programs are independent of any particular operating system and physical hardware machine. They can run on any physical machine, running any operating system that contains the implementation of .NET Framework. The core component of the .NET framework is its Common Language Runtime (CLR), which provides the abstraction of execution environment (Physical machine and Operating System) and manages the overall execution of any of the .NET based program.
Subscribe to:
Posts (Atom)
