Implement a Data Access Layer for Your App with ADO.NET

Implementing data access functionality is a core activity of most developers working with the .NET Framework, and the data access layers they build are an essential part of their applications. This article outlines five ideas to consider when building a data access layer with Visual Studio .NET and the .NET Framework. The tips include taking advantage of object-oriented techniques and the .NET Framework infrastructure by using base classes, making classes easily inheritable by following guidelines, and carefully examining your needs before deciding on a presentation method and external interface.

 Rule 1: Use Object-oriented Features
Rule 2: Adhere to the Design Guidelines
Rule 3: Take Advantage of the Infrastructure
Rule 4: Choose Your External Interface Carefully
Rule 5: Abstract .NET Framework Data Providers 

If you're developing a data-centric application targeting the Microsoft® .NET Framework, you'll eventually need to create a data access layer (DAL). You probably know that there are benefits of building your code in the .NET Framework. Because it supports both implementation and interface inheritance, your code can be more reusable, especially by developers across your organization using different Framework-compliant languages. In this article, I'll present five rules for developing a DAL for your .NET Framework-based applications.

Before I begin, I should note that any DAL you build based on the rules discussed in this article will be compatible to the traditional multitier or n-tier application favored by developers on the Windows® platform. In this architecture, the presentation layer consists of Web Forms, Windows Forms, or XML Web Services code that makes calls to a business layer that coordinates the work of the data access layer. This layer consists of multiple data access classes. Alternatively, the presentation layer may make calls directly to the DAL in cases where business process coordination is not required. This architecture is a variant of the traditional Model-View-Controller (MVC) pattern and in many ways is assumed by Visual Studio® .NET and the controls that it exposes.

 

For More Read: http://msdn.microsoft.com/en-us/magazine/cc188750.aspx