Welcome Guest!
Create Account | Login
Locator+ Code:

Search:
FTPOnline Channels Conferences Resources Hot Topics Partner Sites Magazines About FTP RSS 2.0 Feed

email article
printer friendly
get the code
more resources

Design an Effective Data-Access Architecture
.NET offers new options for accessing your data, forcing you to decide two things when you design the interface that exposes this content.
by Dan Fox

For this solution: Visual Studio .NET, ADO.NET, C#, VB

With the release of Visual Studio .NET (VS.NET) and the .NET Framework, a good number of organizations have begun architecting and implementing .NET applications. Many, if not most, of these applications will consume and expose data residing in relational database management systems, such as Microsoft SQL Server and Oracle. This implies these applications will rely on ActiveX Data Objects .NET (ADO.NET), the set of classes in the .NET Framework that supply the programming models to manipulate data.

In this article, I'll discuss several ADO.NET techniques you can apply to two major design decisions architects and developers face when they use ADO.NET in a multitier architecture. Implementing these techniques enables corporate development organizations and independent software vendors (ISVs) to increase their codes' reusability and portability while reducing development costs.

Figure 1 Get the Overview

The techniques I'll cover assume your organization uses a basic application architecture, where the presentation services are abstracted from the business and data access services (see Figure 1). You'll note that in this logical architecture the data services tier consists of classes (written in C#, Visual Basic, or any .NET language), which expose methods and properties that manipulate data housed in one or more data stores. I'll refer to these classes as data-access classes. Abstracting the data-access logic into a self-contained set of services (or tier) increases the reusability, maintainability, and security of both the code itself and the data it accesses. This is because the data-access classes are loosely coupled with the rest of the application and, therefore, can be taken out of the application and reused more easily. They can also be modified without affecting the rest of the application, and can be secured independently through role-based security (RBS) in the .NET Framework.

With this architecture established, the design decisions when implementing the data services tier are narrowed to two: how to present the external interface of the data services, and how to implement its internal interface.

Back to top












Java Pro | Visual Studio Magazine | Windows Server System Magazine
.NET Magazine | Enterprise Architect | XML & Web Services Magazine
VSLive! | Thunder Lizard Events | Discussions | Newsletters | FTP Home