On the Way to Mastering ASP.NET: Introducing Custom Entity Classes

source:

http://msdn.microsoft.com/asp.net/default.aspx?pull=/library/en-us/dnaspp/html/CustEntCls.asp

begin:

Karl Seguin
Microsoft Corporation

March 2005

Summary: There are situations for which untyped DataSets may not be the best solution for data manipulation. The goal of this guide is to explore an alternative to DataSets: custom entities and collections. (32 printed pages)

Contents

Introduction
Problems with Datasets
Custom Entity Classes
Object-Relational Mapping
Custom Collections
Managing Relationships
Beyond the Basics
Conclusion

Introduction

The days of ADODB.RecordSet and the oft-forgotten MoveNext are gone, replaced by the powerful and flexible capabilities of Microsoft ADO.NET. Our new arsenal is the System.Data namespace, featuring lightning-fast DataReaders, feature-rich DataSets, and packaged in a capable object-oriented model. It's no surprise that we have such tools at our disposal. Any 3-tier architecture relies on a solid Data Access Layer (DAL) to elegantly connect the data layer to the business layer. A quality DAL helps promote code reuse, is key to good performance, and is totally transparent.

As our tools have evolved, so too have our development patterns. Saying goodbye to MoveNext was more than ridding ourselves of cumbersome syntax; it opened our minds to disconnected data, which in turn had a profound impact on how we built applications.

While DataReaders might have been familiar (they behave a lot like RecordSets), it didn't take long for us to venture forward and explore DataAdapters, DataSets, DataTables, and DataViews. It was our growing skills at exploiting these new objects that changed how we developed. Disconnected data allowed us to utilize new caching techniques, and thus greatly improve the performance of our applications. The capability of these classes allowed us to write smarter and more powerful functions, while at the same time reducing, sometimes considerably, the amount of code required for common activities.

There are a number of situations for which DataSets are particularly well suited, such as prototyping, small systems, and support utilities. However, using them in enterprise systems, where ease of maintenance is more important than time to market, may not be the best solution. The goal of this guide is to explore an alternative to DataSets that is geared towards this type of work: custom entities and collections. Other alternatives exist, but none provide the same capability or have more backing. Our first task will be to look at the shortcomings of DataSets in order to understand the problem we are trying to solve.

Keep in mind that every solution has its own advantages and disadvantages, so it's possible that the drawbacks of DataSets are going to be more palatable to you than those of custom entities (which we'll also discuss). You and your team must decide which solution is better suited to your project. Remember to consider the total cost of a solution, including the nature of requirements to change and the likelihood that you'll spend more time in post-production than actually developing code. Finally, note that when I refer to DataSets, I don't mean typed-DataSets, which indeed solve some of the shortcomings associated with untyped-DataSets.

Problems with Datasets

Lack of Abstraction

The first and most obvious reason to consider alternatives is the DataSet's inability to decouple your code from the database structure. DataAdapters do a great job of making your code blind to the underlying database vendor (Microsoft, Oracle, IBM, …) but fail to abstract away the core component of a database: tables, columns, and relationships. These core database components are also the core components of the DataSet. DataSets and databases share more than just common components; unfortunately, they also share their schema. Given the following select statement:

SELECT UserId, FirstName, LastName

   FROM Users

We know that values will be available from the UserId, FirstName, and LastName DataColumns within our DataSet.

Why is this so bad? Let's look at a basic everyday example. First we have a simple DAL function:

'Visual Basic .NET

Public Function GetAllUsers() As DataSet

 Dim connection As New SqlConnection(CONNECTION_STRING)

 Dim command As SqlCommand = New SqlCommand("GetUsers", connection)

 command.CommandType = CommandType.StoredProcedure

 Dim da As SqlDataAdapter = New SqlDataAdapter(command)

 Try

  Dim ds As DataSet = New DataSet

  da.Fill(ds)

  Return ds

 Finally

  connection.Dispose()

  command.Dispose()

  da.Dispose()

 End Try

End Function



//C#

public DataSet GetAllUsers() {

 SqlConnection connection = new SqlConnection(CONNECTION_STRING);

 SqlCommand command = new SqlCommand("GetUsers", connection);

 command.CommandType = CommandType.StoredProcedure;

 SqlDataAdapter da = new SqlDataAdapter(command);

 try {

  DataSet ds = new DataSet();

  da.Fill(ds);

  return ds;

 }finally {

  connection.Dispose();

  command.Dispose();

  da.Dispose();

 }            

}


文章整理：西部数码--专业提供域名注册、虚拟主机服务

http://www.west263.com

以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!