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

原创 2004年07月23日 09:59:00

<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" /><?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

   MSDN Home >  MSDN Library >  .NET Development >  ADO.NET > 

 

Page Options

 

 

 

 

DATA ACCESS

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

Dan Fox

 

This article assumes you're familiar with ADO.NET, Visual Basic .NET, and C#

Level of Difficulty 1 2 3

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

 

<?xml:namespace prefix = w ns = "urn:schemas-microsoft-com:office:word" />f 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.

Rule 1: Use Object-oriented Features
  The most fundamental object-oriented task is creating an abstract base class using implementation inheritance. This base class can include services that all your data access classes can use through inheritance. If the services are generic enough, they can be reused through the distribution of your base class throughout your organization. For example, in the simplest case, your base class can handle the creation of a connection object for your derived classes, as shown in Figure 1.

Figure 1 Simple Base Class

Figure 2 Serviced Component Base Class

Figure 3 Tracing Configuration

Figure 4 Custom Exception Class

Figure 6 Using a Custom Class

Figure 7 ProviderFactory


  As you can see in this figure, the DALBase class is marked as MustInherit (abstract in C#) to ensure that it is used in an inheritance relationship. The class then includes a private SqlConnection object instantiated in the public constructor, which accepts the connection string as a parameter. The protected Connection property then allows derived classes to access the connection object, while the Dispose method from the IDisposable interface ensures that the connection object is disposed.
  Even in the following simplified example you can begin to see the usefulness of abstract base classes:

Public Class WebData : Inherits DALBase

 

    Public Sub New()

         MyBase.New(ConfigurationSettings.AppSettings("ConnectString"))

     End Sub

 

     Public Function GetOrders() As DataSet

 

         Dim da As New SqlDataAdapter("usp_GetOrders", Me.Connection)

         da.SelectCommand.CommandType = CommandType.StoredProcedure

         Dim ds As New DataSet()

 

         da.Fill(ds)

         Return ds

 

     End Function

 

End Class

In this case, the WebData class inherits from DALBase and, as a result, does not need to worry about instantiating the SqlConnection object, but simply passes the connection string to the base class via the MyBase keyword (or the base keyword in C#). The WebData class's GetOrders method can access the protected property using Me.Connection (this.Connection in C#). While this example is relatively simple, as you'll see in Rules 2 and 3, the base class can provide other services as well.
  An abstract base class is especially useful when your DAL needs to run in a COM+ environment. In this case, since the code required to allow the component to use COM+ is more complicated, it makes sense to create a serviced component base class like the one shown in Figure 2.
  In this code, the DALServicedBase class includes essentially the same functionality as in Figure 1, but additionally inherits from ServicedComponent in the System.EnterpriseServices namespace and includes attributes to indicate that the component supports object construction, transactions, and statistics tracking. The base class then takes care of catching the construction string configured in the Component Services Manager and once again creating and exposing the SqlConnection object. It's important to note that when a class inherits from DALServicedBase, it also inherits the settings for the attributes. In other words, a derived class will also have its transaction option set to Supported. If the derived class wants to override this behavior, it has the option of redefining the attribute at the class level.
  In addition, your derived classes should avail themselves of both overloaded and shared methods where appropriate. There are essentially two scenarios where overloaded methods (a single method with multiple signatures) are used. First, they can be used when a method needs to accept arguments that vary in their types. The canonical examples of this type in the Framework are the methods of the System.Convert class. For example, the ToString method includes 18 overloaded methods that accept one argument, each of which is of a different type. Second, overloaded methods can be used to expose signatures with increasing numbers of arguments, but not necessarily arguments of different types. This type of overloading turns out to be very effective in a DAL since it can be used to expose alternate signatures for data retrieval and modification. For example, a GetOrders method can be overloaded so that one signature accepts no arguments and returns all orders, while an additional signature accepts an argument that indicates that the caller wants to retrieve only specific customer orders, as shown in the following code:

Public Overloads Function GetOrders() As DataSet

Public Overloads Function GetOrders(ByVal customerId As Integer) As

    DataSet

A good implementation tip in this case is to abstract the functionality of the GetOrders method into a private or protected method that can be called by each of the overloaded signatures.
  Shared methods (static in C#) can also be used to expose fields, properties, and methods that are accessible to all instances of your data access classes. Although shared members cannot be used with classes that use Component Services, they can be useful for read-only data that can be retrieved in the shared constructor of your data access class and then read by all instances. Be careful when using shared members for read/write data since multiple threads of execution may be vying for access to the shared data.

Rule 2: Adhere to the Design Guidelines
  In the online documentation that ships with Visual Studio .NET there is a topic titled "Design Guidelines for Class Library Developers", which covers the naming conventions for classes, properties, and methods in addition to patterns for overloaded members, constructors, and events that you should follow. One of the primary reasons you should follow the naming conventions is the cross-language inheritance provided by the .NET Framework. If you are building a DAL base class in Visual Basic? .NET, you'll want to ensure that developers using other languages compatible with the .NET Framework can inherit from it and easily understand how it works. By adhering to the guidelines I've outlined, your naming conventions and constructs won't be language specific. For example, you'll notice in the code samples in this article that camel casing (first word lowercased, plus intercaps) is used for the arguments to the methods, Pascal casing (each word uppercased) is used for the methods, and the base class has the Base suffix to denote that it is an abstract class.
  A corollary to the .NET Framework design guidelines are the general design patterns like those documented in the book Design Patterns by the Gang of Four (Addison-Wesley, 1995). For example, the .NET Framework uses a variant of the Observer pattern called the Event pattern that you should follow when exposing events in your classes.

Rule 3: Take Advantage of the Infrastructure
  The .NET Framework includes classes and constructs that can assist in handling generic infrastructure-related tasks such as instrumentation and exception handling. Combining these concepts with inheritance through your base class can be quite powerful. For example, consider the tracing functionality exposed in the System.Diagnostics namespace. In addition to the Trace and Debug classes, this namespace also includes classes derived from Switch and TraceListener. The Switch classes, BooleanSwitch and TraceSwitch, can be configured to be turned on and off both programmatically and through the application's configuration file. In the case of TraceSwitch, multiple levels of tracing can be exposed. The TraceListener classes, TextWriterTraceListener and EventLogTraceListener, direct the output of the Trace and Debug methods to a text file and event log, respectively.
  As a result, you can add tracing functionality to your base class to make it simple for the derived classes to log messages. In turn, the application can control whether tracing is enabled using the application configuration file. You can add this functionality to the DALBase class shown in Figure 1 by including a private variable of type BooleanSwitch and instantiating it in the constructor:

Public Sub New(ByVal connect As String)

    _connection = New SqlConnection(connect)

    _dalSwitch = New BooleanSwitch("DAL", "Data Access Code")

End Sub


  The arguments to BooleanSwitch include its name and description. You can then add a protected property to turn the switch on and off and a protected property to format and write a trace message using the WriteLineIf method of the Trace object:

Protected Property TracingEnabled() As Boolean

    Get

        Return _dalSwitch.Enabled

    End Get

    Set(ByVal Value As Boolean)

        _dalSwitch.Enabled = Value

    End Set

End Property

 

Protected Sub WriteTrace(ByVal message As String)

    Trace.WriteLineIf(Me.TracingEnabled, Now & ": " & message)

End Sub


  In this way, derived classes don't have to know about the switch and listener classes themselves and can simply call the WriteTrace method when a significant event occurs in the data access class.
  To create a listener and turn it on, the application configuration file can also be used. Figure 3 shows a simple configuration file that turns on the DAL switch just shown and directs its output to the file DALLog.txt through a TextWriterTraceListener called myListener. Of course, you can also programmatically create your own listener by deriving from the TraceListener class and including the listener directly in your DAL.
  A second bit of infrastructure that you should certainly be taking advantage of is structured exception handling (SEH). At the most basic level, your DAL can expose its own Exception object inherited from System.ApplicationException and can additionally expose custom members. For example, the DALException object shown in Figure 4 can be used to wrap exceptions thrown by code in the data access classes. The base class can then expose a protected method to wrap the exception, populate the custom members, and throw it back to the caller, as follows:

Protected Sub ThrowDALException(ByVal message As String, _

  ByVal innerException As Exception)

    Dim newMine As New DALException(message, innerException)

 

    newMine.ConnectString = Me.Connection.ConnectionString

    Me.WriteTrace(message & "{" & innerException.Message & "}")

    Throw newMine

End Sub


  In this way, derived classes can simply call the protected method, passing in the data-specific exception (typically a SqlException or OleDbException) that was intercepted and adding a message that pertains to the particular data domain. The base class wraps the exception in a DALException and throws it back to the caller. This allows the caller to easily capture all exceptions from the DAL using a single Catch statement.
  As an alternative, take a look at the Exception Management Application Block Overview published on MSDN?. This framework couples the publishing of exceptions with application logging through a set of objects. In fact, you can plug your own custom exception classes into this framework by inheriting them from the BaseApplicationException class provided in the .NET Framework.

Rule 4: Choose Your External Interface Carefully
  As you design the methods of your data access classes, you need to consider how they will accept and return data. For most developers, there are three primary choices: using ADO.NET objects directly, using XML, and using custom classes.
  If you're going to expose ADO.NET objects directly, you can employ one of two programming models. The first includes the DataSet and DataTable objects, which are useful for disconnected data access. Much has been written about the DataSet and its associated DataTables, but this is most useful when you need to work with data that's been disconnected from the underlying data store. In other words, a DataSet can be passed between the tiers of your application, even when the tiers are physically distributed, as is the case when the business and data services tiers are placed on a cluster of servers that are separate from the presentation services. Additionally, DataSet objects are ideal for returning data through XML-based Web Services because they're serializable and thus can be returned in a SOAP response message.
  This is different from accessing data using classes that implement the IDataReader interface, such as SqlDataReader and OleDbDataReader. These data readers are used to access data in a forward-only, read-only manner. The big difference between the two is that the DataSet and DataTable objects can be passed between application domains (and thus between processes on the same or separate machines) by value, whereas the data reader can be passed around, but is always done so by reference. Take a look at Figure 5, in which Read and GetValues are executed in the server process and their return values copied to the client.


Figure 5 Remoting Data Readers

  This diagram highlights how a data reader lives in the app domain in which it was created and all access to it results in a round-trip between the client and server application domain. This means that your data access methods should return data readers only when they are executing in the same app domain as the caller.
  When using data readers, there are two other issues to consider. First, when you return a data reader from a method in your data access class, you need to think about the lifetime of the connection object associated with the data reader. By default, the connection remains busy while the caller is iterating through the data reader. Unfortunately, when the caller is finished, the connection remains open and is therefore not returned to a connection pool (if connection pooling is enabled). You can, however, instruct the data reader to close its connection when its Close method is called by passing the CommandBehavior.CloseConnection enumerated value to the ExecuteReader method of command objects.
  Second, in order to decouple your presentation layer from a particular Framework data provider (such as SqlClient or OleDb), the calling code should reference the return value using the IDataReader interface rather than the concrete type, such as SqlDataReader. In this way, the presentation layer won't have to change if your application moves from an Oracle to a SQL Server? back end and the return type of a method in the data access class changes.
  If you want your data access classes to return XML, you can choose from the XmlDocument and XmlReader classes in the System.Xml namespace, which are analogous to the DataSet and IDataReader. In other words, your methods should return an XmlDocument (or XmlDataDocument) when the data is to be disconnected from its source, whereas XmlReader can be used for streamed access to XML data.
  Finally, you can also decide to return custom classes with public properties. These classes can be marked with the Serialization attribute so they can be copied across application domains. Plus, you'll likely need strongly typed collection classes if you want to return multiple objects from your methods.
  Figure 6 contains an example of a simple Book class and its associated collection class. You'll notice that the Book class is marked with Serializable to enable "by value" semantics across application domains. This class implements the IComparable interface so that when it is included in a collection class, it will be sorted by Title by default. The BookCollection class derives from ArrayList in the System.Collections namespace and shadows the Item property and Add method in order to restrict the collection to only Book objects.
  By using custom classes you get complete control of how the data is represented, developer productivity through strong typing and IntelliSense?, and no caller dependency on ADO.NET. However, this approach requires more code since the .NET Framework does not contain any object-relational mapping technology (other than typed DataSet objects that are essentially derived DataSet classes). In these cases, you'll typically create a data reader in your data access class and use it to populate the custom class.

Rule 5: Abstract .NET Framework Data Providers
  The final rule specifies why and how you should abstract the .NET Framework data provider used internally in your DAL. As I've mentioned, the ADO.NET programming model exposes distinct .NET Framework data providers including SqlClient, OleDb, and others available on the MSDN Online Web site. While this design results in improved performance and the ability for providers to expose data-source-specific functionality (such as the ExecuteXmlReader method of the SqlCommand object), it forces you to decide which provider to code against. In other words, a developer typically chooses to use SqlClient or OleDb and then writes code directly against the classes in the respective namespace.
  If you want to change the .NET Framework data provider, you'll need to recode your data access methods. To avoid this, you can use a design pattern known as the Abstract Factory. Using this pattern, you can build a simple class that exposes methods to create the primary .NET Framework data provider objects (command, connection, data adapter, and parameter) based on information identifying the .NET Framework data provider passed into the constructor. The code in Figure 7 shows a simple C# version of this class.
  In order to use this class, the code in your data access classes would need to program against the various interfaces that the .NET Framework data providers implement, including IDbCommand, IDbConnection, IDataAdapter, and IDataParameter. For example, in order to fill a DataSet with results from a parameterized stored procedure, you could use the following code inside a method of your data access class:

Dim _pf  As New ProviderFactory(ProviderType.SqlClient)

Dim cn As IDbConnection = _pf.CreateConnection(_connect)

Dim da As IDataAdapter = _pf.CreateDataAdapter("usp_GetBook", cn)

 

Dim db As IDbDataAdapter = CType(da, IDbDataAdapter)

db.SelectCommand.CommandType = CommandType.StoredProcedure

db.SelectCommand.Parameters.Add(_pf.CreateParameter("@productId", _

    DbType.Int32, id))

 

Dim ds As New DataSet("Books")

da.Fill(ds)


  Typically, you would declare the ProviderFactory variable at the class level and instantiate it in the constructor of the data access class. Additionally, its constructor would be populated with the provider read from a configuration file, rather than hardcoded, as shown here. As you can imagine, the ProviderFactory would be a great addition to your DAL base class and can then be included in the assembly and distributed to other developers.
  You can choose to take it a step further and encapsulate common ADO.NET code that developers write over and over. In fact, Microsoft has released a Data Access Application Block that performs this function for SQL Server (see Data Access Application Block Overview).

Conclusion
  In the era of Web Services, more and more applications will be built to manipulate data from an isolated application layer. If you follow some basic rules and commit them to habit, writing data-access code will be faster, easier, and more reusable, save you trips to the server, and allow you to keep your data separate.

 

 

 

苹果审核reject理由大全(3):获取用户信息、IAP商店

拒绝理由1.获取用户信息2.审核人对IAP商店的质疑—————–1.获取用户信息———————苹果认为用户信息涉及隐私,如果未经用户允许获取用户信息,会被reject。 但是,审核人员有可能过度使用...
  • imanapple
  • imanapple
  • 2015年08月11日 19:47
  • 2334

被AppStore拒绝理由(一)

July 8, 2015 at 7:06 AM 发件人 Apple 17.1 - Apps cannot transmit data about a user without obtainin...
  • tubiebutu
  • tubiebutu
  • 2015年07月08日 09:47
  • 2952

VS C# ADO.NET代码连接Access数据库

在Visual Studio2013 C#中以编程方式操作Access数据库,一般使用OleDb进行连接: 1.首先添加两个引用(使用using): using System.Data.OleDb; ...
  • c1481118216
  • c1481118216
  • 2016年05月31日 00:50
  • 3609

iOS App被拒常见原因

博主github地址: https://github.com/leicunjie (1)Information Needed We began the review of your app ...
  • samuelandkevin
  • samuelandkevin
  • 2016年08月16日 11:37
  • 10322

iOS开发------iOS 10 由于权限问题导致崩溃的那些坑

6月份的WWDC大会结束有一段时间了,相信很多开发者也是在努力工作的闲时用着Xcode8 Beta版学习着新的特性吧。 使用Xcode写自己的东西有一段时间了,在使用Xcode8编程时不得不说我特别喜...
  • RunIntoLove
  • RunIntoLove
  • 2016年08月01日 18:39
  • 26209

使用Application来实现数据的共享

如果我们的一个的应用程序有俩个入口。那么如果我们在这个应用程序的一个入口中修改了数据的话,那么我们应该怎么做才能使另外的一个入口也可以接收到或者说是及时响应到应用程序的数据的改变呢?本节的内容主要就是...
  • li12412414
  • li12412414
  • 2016年07月09日 17:20
  • 1057

IOS App上传App Store 由于使用第三方支付而被拒绝的解决方案

最近在做项目时,涉及用户付费。于是就找来了支付宝和微信支付的集成教程,按照要求分别开通各自开发平台的开发者账号和商户号。在后台加入了支付的支持,一步步的集成和测试,通过后打包上传到App Store ...
  • txinhuacdn
  • txinhuacdn
  • 2016年09月29日 09:51
  • 21626

Hbuilder云打包iOS App定位弹窗描述问题

Hbuilder开发的App用到了定位权限,上架AppStore审核被拒,反馈问题如下: Guideline 5.1.1 - Legal - Privacy - Data Collectio...
  • sy_love2010
  • sy_love2010
  • 2018年01月12日 14:19
  • 96

ASP.NET MVC 4用ADO.NET实体数据模型连接数据库

ADO.NET实体数据模型连接数据库,既可用来连接SQL Server数据库,也可以用来来接MySQL数据库,非常便捷方便,使用此法在代码具体实现的时候也很方便。     为了正常连接MySQL数据库...
  • vjudge
  • vjudge
  • 2015年04月24日 12:54
  • 2760

app审核遇到的坑

Guideline 2.2 - Performance - Beta Testing –不能出现 test,demo,beta 这些字眼 Your app contains references ...
  • liwenjie0912
  • liwenjie0912
  • 2017年08月31日 11:22
  • 3214
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Implement a Data Access Layer for Your App with ADO.NET
举报原因:
原因补充:

(最多只允许输入30个字)