[Original]. Net business framework development practices six Dal Reconstruction

Six Dal reconstruction in. Net business framework development practice
In fact, this series is still the previous ". Net distributed architecture development practice". The reason why I changed the name is mainly becauseArticleThe title of this article brings a lot of ambiguity: In this series of articles, we plan to develop a framework that simplifies the business process, and then use this framework to develop a distributed application. Changed the name. We apologize for any inconvenience.

The topics in this article are as follows:
1. Define the Dal interface.

 

Links to articles:

[Original]. Net distributed architecture development practices

[Original]. Net distributed architecture development practice Draft II Design

[Original]. Net distributed architecture development practice III. In-depth thoughts on data access

[Original]. Net distributed architecture development practices 4 build a bridge between ideal and implementation (previous article)

[Original]. Net distributed architecture development practice 5 framework Improvement

[Original]. Net business framework development practices six Dal Reconstruction

[Original]. Net business framework development practices-a preliminary idea of the seven business Layers

[Original]. Net business framework development practices-eight business layer ing selection policies

[Original]. Net business framework development practices 9 mapping attribute principles and verification rules implementation strategies

[Original]. Net business framework development practices in the first phase of the 10 Summary, a simple introduction, the water goes by the way (previous article)

[Original]. Net business framework development practices in the first phase of the 10 Summary, a simple and easy to understand (later)

 

 

In the development of Dal, some ideas were proposed and some interfaces were also designed. Now we have improved some of the Dal designs. Saying "perfect" doesn't mean to put allCodeAll are implemented, but the defined interfaces and methods are finalized. Richard believes that when designing an architecture or framework, the interface is defined, and the interface for interaction between layers is defined, then the implementation of specific code.

When designing the framework, you must first consider who the framework users are and how they want to use the developed framework. Here, Richard understands that framework users are developers in their own company. It also makes development as convenient as possible. Do not configure documents everywhere. It is best to introduce the framework and use it with a little configuration.

 

In the framework designed by Richard, if you want Dal to return datatable and datareader to Bll, you only need to specify the connection string of the database; if you want the data entities returned by the Dal to be BLL, You have to map one sheet of tables to an entity and then let these entities inherit the idataentity interface. (You can use the ORM tool to generate an object, or manually write the code ).

Richard considered his previous design for Dal and made some improvements here.

The first is the re-design and understanding of idatacontext: the previous design defined idatacontext and implemented this interface in different ways, such as linqdatacontext. the provider returns the result (dataresult) using the LINQ method ). Now Richard thinks that idatacontext is actually used to operate the database, so the returned result should be the result after the operation data, for example, the update operation returns the affected number of rows or whether the update is successful. As to whether to package some additional information and return it to Bll, it is not an idatacontext implementer. In addition, Richard also considered the need to support native ADO. Net to a certain extent, at least reserved interfaces for ADO. net.

 

Based on this, Richard defines idatacontext as an interface declaration, and then defines idataentitycontext and idatatablecontext to inherit idatacontext. Their relationship diagram is as follows:

Here, idataentitycontext is implemented using LINQ and Entity Framework, while idatatablecontext is implemented using ADO. net.

The idataentitycontext interface is similar to some methods defined in the series, but has been modified. One thing to mention is that icriteria is the interface to be implemented by all condition objects (the query object is also a condition object ). For example, you can delete or update data based on the conditions.

 

Code

  ///   <Summary>
/// All data entity executors implement this excuse
///   </Summary>
Public   Interface Idataentitycontext: idatacontext
{
Tentity add < Tentity > (Tentity entity) Where Tentity: idataentity;
List < Tentity > Add < Tentity > (List < Tentity > Entitylist) Where Tentity: idataentity;

Bool Update < Tentity > (Tentity entity) Where Tentity: idataentity;
Bool Update < Tentity > (List < Tentity > Entitylist) Where Tentity: idataentity;
Bool Update (icriteria condiftion, Object Value );

Bool Delete < Tentity > (Tentity entity) Where Tentity: idataentity;
Bool Delete < Tentity > (List < Tentity > Entitylist) Where Tentity: idataentity;
Bool Delete (icriteria condition );

Int Getcount (icriteria condition );
List < Tentity > Query < Tentity > (Icriteria condition );
List < Tentity > Query < Tentity > (Icriteria condition, Int Pageindex, Int Pagesize, Ref   Int Entitycount) Where Tentity: idataentity;
List < Object > Query (icriteria condiftion );
}

 

 

In addition, there is an additional list <Object> query (icriteria condiftion); method. Richard considers that developers may want to directly write SQL statements for execution, for example, select AVG (count), sum (name) from customer ..., developers can write arbitrary statements. Therefore, if an entity class is returned, a list <Object> is returned.

 

Another point is the improvement of the query object: Previously, only the interface for the query object was defined. Now, the condition object is defined in the icriteria interface, it can also be declared in the condition object whether the transaction or cache is used for data operations.

Code

  ///   <Summary>
/// All condition objects must be inherited from this interface.
///   </Summary>
Public   Interface Icriteria
{
String Name { Get ; Set ;}
Bool Iscache { Get ; Set ;}
Bool Istransaction { Get ; Set ;}
}

 

Then Richard defines an idataprovider interface. The declaration is as follows:

 

Code

  ///   <Summary>
/// An excuse for data providers to implement
///   </Summary>
Public   Interface Idataprovider
{
Dataresult < Tentity > Add < Tentity > (Tentity entity) Where Tentity: idataentity;
Dataresult < Tentity > Add < Tentity > (List < Tentity > Entitylist) Where Tentity: idataentity;

Dataresult < Tentity > Update < Tentity > (Tentity entity) Where Tentity: idataentity;
Dataresult < Tentity > Update < Tentity > (List < Tentity > Entitylist) Where Tentity: idataentity;
Bool Update (icriteria condiftion, Object Value );

Dataresult < Tentity > Delete < Tentity > (Tentity entity) Where Tentity: idataentity;
Dataresult < Tentity > Delete < Tentity > (List < Tentity > Entitylist) Where Tentity: idataentity;
Bool Delete (icriteria condiftion );

IntGetcount (icriteria condition );

Dataresult < Tentity > Getone < Tentity > (Icriteria condition) Where Tentity: idataentity;
Dataresult < Tentity > Getlist < Tentity > (Icriteria condition) Where Tentity: idataentity;
Dataresult < Tentity > Getpagedata < Tentity > (Icriteria condition, Int Pageindex, Int Pagesize, Ref   Int Entitycount) Where Tentity: idataentity;
List < Object > Getcustomdata (icriteria condiftion );
}

 

 

To define this interface, Richard wants to implement the idatacontext class to perform underlying data operations in a down-to-earth manner. As to the form in which the result after the data operation is sent to Bll, you do not need to care about idatacontext, but the idataprovider.

The implementer of idataprovider calls the idatacontext implementer method at the underlying layer. Then, in idataprovider, it provides more friendly and convenient methods for external use, finally, The bll directly depends on idataprovider instead of idatacontext.

In addition, some modifications are made to the dataresult returned by idataprovider: If the returned data entity uses idataentitycontext to provide underlying data operations, then dataresult <tentity> is no problem; however, if idatatablecontext is used, dataresult <tentity> cannot be returned because the idatatablecontext query method may return a datatable or datareader. therefore, an interface is reserved during the design process to implement the idataresult interface for the results returned by idataprovider. ataresult <tentity> inherits this interface, which is mainly used to return data entities, as follows:
 

The Design of dal is here, and the next article begins to talk about some thoughts on the business layer.

Copyright:XiaoyangAnd the blog Park, reprinted please indicate the source to the author.

Http://www.cnblogs.com/yanyangtian

Code download