Data access layer component design and selection the second encapsulation of the stream of consciousness and various complaints

Our components are relatively available, but our users are picky. Some users have three requirements:

 

1. Added support for distributed transactions

2. I don't want to write any SQL statements. I just want to do some simple single-table database operations. Can I automatically generate SQL statements?

3. I want to save the sub-objects in the SAVE call of a parent object like EF or NH, which is called cascade SQL operations.

 

This encapsulation will meet these requirements.

 

First, analyze,

Implement the first requirement, I don't want to touch the interface of any original method, so I thought of the concept of local thread storage.

In addition, for distributed transactions, I only refer to distributed transactions in the database. That is to say, a transaction accesses database A and database B. distributed transactions maintain a list of local transactions, distributed transactions are committed only when all local transactions meet the commit conditions.

 

Therefore, I wrote a transactionscope class, which should be similar to the practice in EF.CodeAs follows:

Using System;
Using System. Collections. Generic;
Using System. Data;
Using System. LINQ;
Using System. runtime. remoting. messaging;

NamespaceDianping. Ba. Framework. dal
{
Public ClassTransactionscope: idisposable
{
PublicIenumerable <idbtransaction> transactions {Get;Set;}

PublicTransactionscope ()
{
Transactions =NewList <idbtransaction> ();

Callcontext. setdata ("Transactionscope",This);
}

Public Void Rollback ()
{
Try
{
Foreach ( VaR Tran In Transactions. Reverse ())
{
If (Tran. Connection. State! = Connectionstate. Closed)
{
Tran. rollback ();
Tran. Connection. Close ();
Tran. Connection. Dispose ();
Tran. Dispose ();
}
}
}
Catch
{
// Todo: What is a log?
}

Transactions =NewList <idbtransaction> ();
}

Public Void Comit ()
{
Try
{
Foreach ( VaR Tran In Transactions)
{
If (Tran. Connection. State! = Connectionstate. Closed)
{
Tran. Commit ();
Tran. Connection. Close ();
Tran. Connection. Dispose ();
Tran. Dispose ();
}}
}
Catch
{
// Todo: What is a log?
}

Transactions =NewList <idbtransaction> ();
}

Public Void Dispose ()
{
Try
{
Foreach ( VaR Tran In Transactions)
{
If (Tran. Connection. State! = Connectionstate. Closed)
{
Tran. rollback ();
Tran. Connection. Close ();
Tran. Connection. Dispose ();
Tran. Dispose ();
}
}
}
Catch
{
// Todo: What is a log?
}

Transactions =NewList <idbtransaction> ();
Callcontext. freenameddataslot ("Transactionscope");
}
}
}

 

You only need:

Using ( VaR Transactionscope = New Transactionscope ())
{
Try {
// Database Operations
}
Catch (Exception E)
{
// Todo: logs recorded
Transactionscope. rollback ();
}
}

 Achieve the second requirement:

 

How is it difficult to automatically generate simple SQL statements?

 

Brother immediately created a dacbase <t> class. Do not create your own DAC class for simple queries. Use it directly:

 

 

 

Now let's take a look at the third requirement.I have always thought that the object should be anemia and should not have operations. It is best not to have cascade data operations.

For example, the so-called cascade select is like this:

 

 

The classb attribute of testclassa does not store the primary key of the classb, but directly stores the object. Then, it is done in the get method of the attribute. This is Cascade select.

 

What about cascading insert and update?

 

See the insertcascade and updatecascade methods of dacbase <t>.

 

 

 

I also created a dacbaseobject class to assist.

 

Public Static Class Dacbaseobject
{
Private Static Readonly Dacbase < Object > Dacbase = New Dacbase < Object > ();

Public static int insert ( Object record)
{< br> return dacbase. insertcascade (record);
}

Public Static VoidUpdate (ObjectRecord)
{
Dacbase. updatecascade (record );
}
}

 

 

Maybe we have already surpassed ibitas and daab, but our users will always be in an inch.

 

Now the user puts forward higher requirements:

 

I don't want to write SQL statements at all. I just want to operate the database, just like the memory data. I don't care about the database, just the business.

 

Isn't this forcing our components to the heavyweight or mapping direction?

 

I always thought that the difference between heavyweight or mapping and lightweight is: is there any mapping to implement the relationship between database tables.

 

It is very complicated to implement this. Specifically, it is very complicated to automatically generate statements for multi-table queries! What are the basis for generating such statements? Isn't there a one-to-many or many-to-many relationship between tables, object objects, and object objects?

 

NH has implemented this, but it has been criticized in many aspects. developers who care about performance and flexibility do not need it. This is why ibitas is increasingly used in the Java camp.

 

EF also implements this, and there are two ways:

One is configuration, but its configuration is not all in the file, while adding some ugly attribute to the object, and reading attribute information consumes resources.

The other is code first, which directly writes the code first and then generates the database required by the Service Code. This is obviously only applicable to projects completely starting from 0.

 

Another weakness of EF is that the statements generated by EF are completely similar to those generated by LINQ to SQL. They are all parsed Based on the lamada Expression Tree. For details about the Expression Tree, see

Http://rednaxelafx.iteye.com/blog/248317

 

Expression Tree Parsing is a black box for most developers, althoughSource codeIt is also said to be public, but few people actually read it or understand it. Developers like me who "Break the sandpot and ask the truth" Give up directly.

(PS: I am really such a person. I put ASP in my 08 years. net MVC was recognized only after the source code of the current version was read. If you don't believe it, go to my blog on MVC in)

 

A major problem in generating SQL statements based on the Expression Tree is expansion. For example, what should I do if I want to use EF to access the PostgreSQL database? I don't know, but my intuition tells me that I want to modify the expression tree to generate the SQL logic. Let's just get it !!!!

This isThe critical weakness of EF.

 

PS: checked, EF seems to also support PostgreSQL, http://stackoverflow.com/questions/1211475/entity-framework-postgresql how to support me really don't know, this link is just to lead readers

Http://npgsql.projects.postgresql.org/

 

In addition, managing database mapping will inevitably lead to complexity. Even if you are doing well, you just say that you have a good processing method, not your complexity.

 

The problem caused by complexity is

Poor performance Poor flexibility (think about the situation where the database relationship is needed, think about the situation where the existing database design does not comply with the EF standard should be developed on the basis of the situation, think about writing a lot of reports that are originally made by this bi, but they are on your head)

 

Poor controllability (Can you control the multi-Table query statements it generates? I can only rely entirely on the capabilities and character of the author. I would like to pray for the blessing of the Bodhisattva, not to mention that EF generates statements using expression trees that few people understand)

 

Poor scalability (as mentioned earlier) It is also not well integrated with log monitoring and other components.

 

 

After talking about so many heavyweight or mapping tools, I have only one goal: to persuade the boss to give up using the heavyweight or mapping tool, which is actually quite simple, check how many companies and teams are looking for lightweight data access solutions. How many companies are or are already turning to ibitas or other components without using hibernate. Check how many large companies are using EF. Check which teams have a history of tears.

In the blog, how many Daniel are talking about the death of LINQ to SQL and the death of objectspace (EF)? Why?

 

Why does the daab in the Microsoft enterprise database fail to become Ef? You can say that the Microsoft enterprise database is a weakness,Since the Microsoft enterprise database is a chicken ribs and EF is a good thing, why does Microsoft not replace daab with EF to make the Enterprise Library less chicken ribs ??

There is only one reason: they do not dare! Microsoft does not trust EF!

Conclusion:If the Microsoft enterprise database is a chicken rib, EF is actually more chicken ribs. It has been a few years since it came out, and it is not far from death. Please wait.

 

In fact, sometimes I am selfish to think that EF can also be used. Why should I recommend my own components when I get angry? It will take time and effort to provide technical support. It is no good for you.

When the team complains about EF or EF cannot do something, it will launch its own things to clear up the mess that best suits the individual's interests. Okay, it's silly.

 

I gave up the argument because I was not good at "talking about the crowd". During the debate, my ideas were chaotic. The last time someone said that the Microsoft enterprise database was a chicken ribs, I was speechless...

 

In the final analysis, Microsoft's most incorrect practice is: it always makes decisions for users without authorization, always treats users as dummies, and launches silly products. It always thinks that you do not need to know more deeply.

The above conclusions are drawn from the two development camps. I think if I talked to some java team about EF, EF would have been shot!

 

Here we will look at what has just happened:

 

Our company recently organized a 24-hour eXtreme Programming Competition named hackson, where nine teams participated. My team should be the least competent. In everyone's words, it is the person to be picked.

 

I was chosen because I had been focusing on the development of a basic component. I did not care about this activity in the early stage, so I had no choice.

 

The topic we choose is probably to provide sales staff with the most valuable gadgets and get some commercial analysis results to talk about business with customers. Since it is a business analysis, Bi data is inseparable, this is a difficult issue. This data has only one provider and is not supported by basic components.

 

Our results are very interesting,

Multiple teams write data by themselves (or make sales input data, complicated input interface, and want sales as record collectors ),

Multiple teams directly use one job to capture data with that provider and store the data in their own SQL Server database (that is the massive data volume in the data warehouse, you actually copy one? If you do not copy a copy completely, your data is incomplete)

 

Why are they doing this? I think what they use EF is that they don't want people to see that they actually use Bi data providers directly (our competition also depends on code quality)

 

Only one team is talking with real and complete data (this team may also be recognized as the best team, but also the only one who has completed the task ahead of schedule and completed the task more than twice as planned ), that is, my team. It took me half an hour to encapsulate the Bi data provider in our data access component without changing any existing code line, only an implementation is added. (Open and closed Principles)

 

Several teams want to attract everyone's eyes to the fancy interface and to the spirit of teamwork (feeling). However, how can we mask the incomplete data? The data is incomplete.ProgramIs the value equal to 0?

Let sales input a lot of information, maybe. Well, if I am a sales person, I must be a lazy sales person!

 

Looking back,I am wondering how to bypass data mapping and support development without writing any SQL statements.

 

This introduces the next topic, which is coming soon.

 

 

 

PS:

I. Maybe I am wrong. It may be a headache for me to enter sales information. Most sales do not have a headache. They can talk about customers and input data, you can open a notebook at home and enter it ~~

2. Maybe I am wrong again. There should be two or more Data Access Components in a system, and then the advantages are complementary.