Cyq. Data from getting started to abandoning the ORM series: Opening: Automation Framework Programming thinking

Objective:

As Cyq.data began to return to the free use of the user to find the mood is getting excited, in order to maintain this constant excitement, let me have the idea of open source.

At the same time, since the framework has evolved over the past 5-6 years, the earlier tutorials have been too backward, including the way they are used, and related introductions, which are easily misleading.

To this end, I intend to re-write a series to introduce the latest version, so that everyone from the traditional ORM programming to automated framework-based thinking programming (self-created words).

So: The name of this new series is called:cyq. Data from getting started to giving up the ORM series

What is: Cyq.data

1: It is an ORM framework.

2: It is a data-tier component.

3: It is a Toolset class library.

Let's look at a picture below:

As you can see from the figure above, it's not just an ORM, it comes with some band features.

So:

Write log: You no longer need: Log4net.dll

Operation JSON: You no longer need Newtonjson.dll

Distributed cache: You no longer need Memcached.ClientLibrary.dll

Currently the framework is only 340K, and subsequent versions will not confuse work and will be smaller in size.

The development process of traditional ORM:

Look at a one-piece development trend chart:

Search in open source China. NET system: ORM, the number of about 110, in the CodeProject search. NET: ORM, the number of 530 or so.

After a lot of viewing, it is easy to find that the ORM on the market is almost the same, the only difference:

is in the custom query syntax, each family is playing their own tricks, and must play a different, otherwise everyone is a kind, show no superiority.

At the same time this variety of unreasonable query syntax sugar, also wasted a lot of developers time, because the cost of learning is to read a book or a series from the introduction to mastery.

In general, it is possible to jump out of this trend, Wood has! It is necessary to artistic that the ORM is a routine and innovative.

Once, I also have a very simple and traditional ORM called Xqdata:

I made it 2009 years ago, and found that I was still lying on the hard drive, and was self-willed to share the open source to all of you have not made the ORM of the small partners when the starter guide used.

Xqdata source (SVN download) address: Http://code.taobao.org/svn/cyqopen/trunk/XQData

Cyq. Data's Automated Framework thinking:

In the early version of Cyq.data (how much sooner or later), compared with the traditional entity-type ORM, in addition to the eclectic, looks a little tide, the value of the encouragement and attention, it really does not feel good.

With the formation of automation framework thinking, after years of improvement, now, and the gap between the entity-type ORM is not at the same level.

First look at the code writing method of entity ORM: entity inherits from CYQ.Data.Orm.OrmBase

using (Users u = new users ()) {            u.name = "Passing Autumn";            U.typeid = request["TypeID"];            //....            U.insert (); }

It looks neat, doesn't it? It is, but it is too fixed, not smart enough, once written dead, is a couple of the perfect couple.

Why do I recommend using maction? Because it has an automated framework of thinking:

Look at the following code:

using (maction action = new Maction (tablenames.users)) {    action. Insert (TRUE);//There is no single assignment process in the middle.}

Compare the code to see the advantages:

1: Less code, no middle of the assignment process;

2: And the property and database fields are not dependent: No matter your front-end modification interface, or modify the database, the background code is not adjusted;

If you increase switching table operations and transactions, there are two more advantages:

1: Entity ORM: You can only include code snippets with distributed transactions, and you cannot reuse links.

2:maction: You can use local transactions, you can reuse links.

The above maction code, there is a Tablenames.users table name dependency, if you turn it into a parameter, you will find a different sky:

using (maction action = new maction (parameter table name)) {     action. Insert (TRUE);}

With just two lines of code, you find it completely decoupled from the database and interface.

Here you will find that this is where the framework and the entity ORM are not at a level:

1: Because it realizes the decoupling of the data layer and the UI layer in real sense.

2: Because it is based on the thinking of the automation framework programming, there is no longer a process of assigning a property value.

See here, and then look at the ajaxbase in the ASP. NET Aries Open source framework, you can understand why the background is always a bit of code, can handle any table and data processing automatically:

The following method only needs to pass a table name (+ corresponding data) for the front page only:

If further, the table name is configured in the URL menu field in the database, then an automated page is formed:

And these automated framework programming thinking, are not the entity ORM, the entity ORM can only be a bunch of code for an interface to a heap of code to knock.

Look at an API interface design:

Let's say that there's an app project that has Android and iOS, and they all need to call the backend API, so how do you design it?

Do not move, wait for the app product manager to finalize the interface prototype, and then for the app interface needs what elements, and developers to discuss the development of the application, and then for the request write method?

After all, you have to know which table to read, which data to check, so you can only be passive? Each new page or feature, you have to run to the background to write a bunch of business logic code, and then to do the joint tune?

Is it extra-tiring?

Take a look at the direct use of this framework, the process of your design will become simple, elegant and have abstract thinking:

Interface Core Code:

using (maction action = new Maction (tableName)) {     action. Select (PageIndex, Pagesize,where). ToJson ();}

The next thing you want to design is:

1: Set the format of the client request parameter to the app: {key: ' xx ', Pageindex:1,pagesize:10,wherekey: ' xxxx '}

2: Put the table name mapping to the database (Key,value), the app only passes the Key when the request name

3: Construct the Where condition according to the actual business.

Design several such general-purpose interfaces, to the app developer, and see what the advantages are:

1: Can reduce a lot of communication costs.

The 2:API is designed to be general-purpose, reducing a lot of code, and subsequent maintenance is simple and configurable.

3: Start at the beginning, do not need to wait until the app prototype starts and then hands.

4: Even if the table exists, what to grow, can be in advance regardless of the use of later database configuration.

5: After the realization of a set, change the company to change the business can also be used, because your design and specific business is decoupled.

Think of the entity ORM, do you want to have a database in advance, generate a bunch of entities, and then the specific business constantly new instances, the limits of thinking can only be limited to specific business.

Abstract thinking of frame and intelligent derivation of where condition

First look at a picture:

For the table of common data additions and deletions to the operation, from the visible, the framework finally abstracted two core parameters: Table name +where Condition:

Once I have thought about the grammar of sugar, whether the where this piece is designed to:. Select (...). Where (...). Having (...). GroupBy (...). (...) ...

Later, I insisted that beginner's mind remain native:

1: Developers have no learning costs.

2: Keep the frame young and creative.

3: With automated framework thinking.

The disadvantages of grammatical sugars:

1: The frame itself complex design complexity increases.

2: User learning Cost is high, the use of complexity increases.

3: Not suitable for automation extension: Design has become an expression, can not dynamically according to a key and table to dynamically construct the query conditions! Only suitable for specific instances and business, not suitable for automation programming.

Of course, in most of the where conditions, many are based on the primary key or unique key components of the condition, in order to further abstract and adapt to automation programming, I designed a self-energy deduction mechanism.

Intelligent derivation for Where:

Look at the following two code: The left side is the structure of the relatively complete where, the right can automatically deduce where. (There is an internal anti-SQL injection, so don't worry about the Where condition injection problem).

By intelligently deriving, removing the primary key name parameter (because different table's primary key table is not the same), the intelligent derivation produces, can let the programmer main concern passes over the value, does not have to pay attention to the specific primary key name what.

If the value is a comma-separated multivalued value, the framework automatically infers the turn to primary key in (A/a) condition.

Look at two sets of code: the left side is still relative to the where condition, the right is the Intelligent deduction type programming.

Note: The same is the value, but we want the username, not the primary key, the system can be deduced?

At this time the system will be based on the type of the value, the primary key, unique key equivalent type synthesis analysis, the value should be the primary key or unique key to construct where.

(PS: Unique key derivation is a function that was completed yesterday, so only the latest version is available.) ）

Because the frame has intelligent derivation function, shielding field differences, so that users only need to focus on the value of the pass. It is also an important function to enable you to implement the automation framework programming thinking.

Automated batch-type programming:

Take a look at a picture: mdatatable: It can directly generate batch conversions with various data types:

Mdatatable is one of the core of the framework, and the previous article has an exclusive introduction to it.

Of course, the construction of table is often based on rows, so look at a graph: mdatarow (it is the core of a single row of data)

In fact, because Mdatarow opened a single row of the volume of data come and go, so that the mdatatable to create a multi-line data processing.

In fact Mdatarow is the core implementation layer, but it is relatively low-key.

Add Important address:

1: Source SVN address: https://github.com/cyq1162/cyqdata.git

2: Project Demo example SVN address: http://code.taobao.org/svn/cyqopen/trunk/CYQ.Data.GettingStarted/

3: Frame:

1:vs High version: NuGet search Cyqdata

2:vs Low version: http://www.cyqdata.com/download/article-detail-426

Summarize:

When you use framework programming, you'll find more of a concern: the flow of data, and how to build a configuration system for abstract parameters.

Most of the programming time, in addition to the specific field meaning needs specific attention, mostly based on automated programming thinking, data flow thinking.

Early series: Without this kind of programming thinking, inevitably read the introduction will have a kind of violation of the feelings.

Today's system: Automation Framework programming thinking, but also the user loyalty high like on the reasons, especially after free.

Of course, the follow-up will also be for this series, re-write the use of tutorials, and the tutorial source code will be updated synchronously to SVN, please look forward to.

Cyq. Data from getting started to abandoning the ORM series: Opening: Automation Framework Programming thinking