| A Data Access Layer to Persist Business Objects Using Attributes and Reflection |
| The Code Project |
| Then I came up with the idea of creating classes that would say how they should be persisted in the database. I would use attributes to say what database table my object should be persisted to, as well as other attributes to say what are the properties that should be mapped to table columns. From now on to update my code after a change in the solution I would only change the business object class. |
|
| ADO.NET 2.0 Feature Matrix |
| MSDN |
| ADO.NET 2.0 includes a new base-class provider model, features for all providers, and changes to System.Data.SqlClient. Get an overview of these new features, examples of their use, and a chart of which features are provider-neutral and SqlClient-specific. |
|
| ASP.NET Data Shaping |
| MSDN |
| Is it possible to port this model to Web Forms and get automatic synchronization between two DataGrid server controls? This is the question I will try to answer in this month's column. |
|
| Auto-Generating Wrapper Classes for Stored Procedures, Part 1: Using the AutoSproc Tool |
| MSDN |
| Get an overview of the AutoSproc code generation tool and how it works. The AutoSproc tool (based on classes exposed from the System.Reflection.Emit namespace) saves you time by using reflection to auto-generate wrapper classes for stored procedure calls. |
|
| Auto-Generating Wrapper Classes for Stored Procedures, Part 2: The Internals of the AutoSproc Tool |
| MSDN |
| Review the AutoSproc tool, which uses a code generation technique using classes from the System.Reflection.Emit namespace. It is assumed that the reader is fully conversant with the System.Reflection namespace, but not System.Reflection.Emit or CIL. |
|
| Build a Universal DAL Component |
| DotNetJunkies |
| Think about the possibilities of a component in the data access layer (DAL) of your application that didn't care what .NET Data Provider you were using. It could work just as easily with the SQL Server Data Provider or the OleDb Data Provider, or any other potential .NET Data Providers that could surface in the future. A DAL component that you could use against an Access 2000 database in development, and against a SQL Server database in production. In this tutorial, Doug shows how to build a universal data |
|
| Building a Custom Data Provider for Use with the .NET Data Access Framework |
| MSDN |
| The System.Data.dll assembly in the .NET Framework contains namespaces whose base classes can be used to create custom data providers. These namespaces also define a number of data access interfaces and base classes that let developers create data providers that will interoperate with other custom providers. Using the ADO.NET classes Connection, Command, DataReader, and DataAdapter, writing a provider is easier than writing one for OLE DB. This article explains these classes and their implementation, and how they can be used to write a variety of different kinds of data providers. |
|
| Building a DataNavigator Control |
| MSDN |
| The list of ASP.NET rich data-bound controls is a long one, but it's not all-encompassing. You won't find any Microsoft® .NET counterpart for the Data control—a scrollable and updateable binding context that data-bound controls could rely on to refresh their user interface. The original Data control allowed for simple movements—first, next, previous, and last. It worked on top of a Recordset object and exposed the UpdateRecord method to save changes according to the capabilities of the currently selected type of cursor. While not the perfect programming tool, the Data control was especially good at building simple user interfaces for tables used internally for administrative purposes. |
|
| Building a Universal DAL Component |
| DotNetJunkies |
| Think about the possibilities of a component in the data access layer (DAL) of your application that didn't care what .NET Data Provider you were using. It could work just as easily with the SQL Server Data Provider or the OleDb Data Provider, or any other potential .NET Data Providers that could surface in the future. A DAL component that you could use against an Access 2000 database in development, and against a SQL Server database in production. |
|
| Designing an Extensible DAL |
| DotNetJunkies |
| Filip walks you through how to design an extensible DAL. |
|
| Exposing Proprietary Data the .NET Way |
| MSDN |
| The .NET Framework comes with the OLE DB managed provider, which is meant to be a bridge that gives you immediate access to all the existing OLE DB providers. This component saves your current investments, as applications can continue successfully calling into existing OLE DB providers. The point, though, is another. In .NET, exposing proprietary data requires a more thoughtful choice, mostly because you have multiple and equally powerful options from which to choose.
|
|
| Generic Coding with the ADO.NET 2.0 Base Classes and Factories |
| MSDN |
| Learn more about the new functionality in ADO.NET 2.0 that enables you to create generic data access code. |
|
| Generic Data Provider |
| The Code Project |
| Generic Data Provider. An approach to make applications database independent. |
|
| Inside .NET Managed Providers |
| MSDN |
| When compared to full-fledged OLE DB providers, Microsoft .NET managed providers have a lot to offer. First off, they deliver a simplified data access architecture that often results in improved performance without the loss of functional capabilities. Furthermore, .NET managed providers directly expose provider-specific behavior to consumers through methods and properties. They also involve a much smaller set of interfaces than OLE DB providers. Last but not least, .NET managed providers work within the boundaries of the Common Language Runtime (CLR) and require no COM interaction. For SQL Server 7.0 and SQL Server 2000, the managed provider hooks up directly to the wire level, gaining a substantial performance advantage. |
|
| Using an ADO.NET DataSet as a Reporting Services Data Source |
| MSDN |
| Learn how to build a data processing extension for Reporting Services that enables you to use an ADO.NET DataSet as a data source. |
|
| XmlClient Managed Provider |
| The Code Project |
| This is my first attempt at writing a Managed Provider. The idea behind it was to allow users of the Managed Provider to be able to fill DataSets from XML in a homogeneous way. This way you could mix XML and database data together without having to know exactly which is from which. |
|