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
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