Based on. NET platform's layered architecture combat (seven-outside)-the first implementation of the data access layer __.net

      yesterday's article is based on. NET platform's layered architecture Combat (vii)--the first implementation of the data access layer: After the release of Access+sql, many friends have made comments and suggestions to my program, thank you in the first place ... In particular, the   Golden Ocean (Jyk) has made a lot of constructive comments about my procedure.
      I have summed up the main shortcomings of yesterday's program:
      1.Connection object not closed
      2.DataReader object did not close
      3. Too many similar code, resulting in code redundancy.

      1th of these problems, there is no good solution at the moment, mainly because the DataReader cannot be read once the connection is closed. Also, the connection object should be automatically closed at the appropriate time (by observing the temp file) and not in effect (functionally), so there is no specific solution here. For the next two questions, I use the following solutions.

      the way to turn off DataReader is simple enough to turn him off in finally. The key is how to get redundant code.
      through my analysis, data access layer operations can be divided into three categories: do not return data, return a single entity class, return the collection of entity classes. I pull out the public parts of these three operations, write three methods in Accessdalhelper, and use generics to solve different types of problems.
      There is a difficulty in doing this because the code that is converted from DataReader to entity classes is very different and cannot be extracted. Here, I use the strategy mode to solve. First, define a policy interface that is converted by DataReader into an entity class, and then write a different transformation strategy for different entities, as shown in the following diagram:

As you can see, all transformation strategies implement the Idatareadertoentitystrategy interface, and each strategy has a self assembly, which is thought to be implemented in singleton mode. Accessdalhelper, however, is independent of the specific policy and is only coupled to the interface.

Here's a look at the specific code:
First, the Idatareadertoentitystrategy interface.

IDataReaderToEntityStrategy.cs:IDataReaderToEntityStrategy

Code highlighting produced by Actipro Codehighlighter (freeware)
http://www.CodeHighlighter.com/

--> 1using System;
2using System.Collections.Generic;
3using System.Text;
4using System.Data;
5using System.Data.OleDb;
6
7namespace Nguestbook.accessdal
8{
9/**////
10///the policy interface converted from DataReader to entity classes
11///
public interface idatareadertoentitystrategy<t>
13 {
14/**////
15///converts DataReader to entity classes, using generics
16///
17///The DataReader object containing the data
18///Entity Class
T datareadertoentity (OleDbDataReader dataReader);
20}
21}

Then take the admin as an example and look at the specific implementation of the strategy:
AdminDataReaderToEntityStrategy.cs:
Admindatareadertoentitystrategy

Code highlighting produced by Actipro Codehighlighter (freeware)
http://www.CodeHighlighter.com/

--> 1using System;
2using System.Collections.Generic;
3using System.Text;
4using System.Data;
5using System.Data.OleDb;
6using nguestbook.entity;
7
8namespace Nguestbook.accessdal
9{
10/**////
One///DataReader to the entity class conversion policy-administrator
12///implementation using Singleton mode to ensure a globally unique instance
13///
public class Admindatareadertoentitystrategy:idatareadertoentitystrategy<admininfo>
15 {
private static Admindatareadertoentitystrategy singleinstance = null;
17
18