Object-oriented is the most important is "abstract", the three-tier most important is also "abstract", no abstraction is not a real object-oriented, three-tier.

Only class, which is called "object-based", for example, the original vb6.0, only three projects, the previously written together in the code divided into three, the so-called business logic layer is a megaphone, this category of self-proclaimed three layer, in my view are "imitation three", or even "pseudo three layer."

Object-oriented, that is, to consider the "object", when considering the object of the total need not to consider what the database structure is like, this is right. ORM is about having R after the existing o and then mapping it.

Code to write here, suddenly think of a point of view: In fact, O and R are at the same time, they are based on the requirements of the project are designed separately, without impact. Once you've designed it, think about how to map it.


You might say that each design is designed to correspond to the design. On this issue, the original object and relational database thinking is completely the opposite.


Object oriented, considering objects, abstractions, and individuals. To abstract a large number of objects, to integrate many attributes, methods, to find the appropriate relationship between the various classes.

relational database, consider the division, so that the data as far as possible without redundancy, so many paradigms to achieve the effect of what. is to try to divide the table into multiple tables, each table expressing only one meaning, then in the "Relationship" (association) together, to avoid data redundancy purposes.

Object-oriented is simply not to consider the problem of data redundancy, he is considering the "one". The structure of an object, and the relationships of other objects (inheritance, interfaces, delegates, combinations, aggregations, and so on). He would not consider 10,000 examples, at least not as a priority.

Relational database considers "many", many data, 10,000, 100,000, millions record, how to deal with. The problem of how to handle more than one data.

It seems to be getting off the topic, hurry back.

On an article, write the kind of "separate" way, for the three layer and three layer of practice, I think is pseudo three layer, so please note, I said is false three layer bad, for three layer and three layer is wrong. I think the way I wrote the code is not really three layers, so please do not misunderstand, I did not say that the real three layer is not good, I am not opposed to object-oriented.

This article I just want to say, I use the object-oriented approach. Maybe my ideas and your understanding is not consistent, but it doesn't matter, take out the discussion together.

Web site, from the business side (is the customer's needs) possible classification forms, such as blog Park

At the beginning of the blog Park did not have so many modules, and then slowly added to the. So are we going to design classes according to these classifications? A module a class or several classes. If it's simple, then it's a class explosion. And there is no abstraction. (I don't know how blogging is done, it's just speculation, from a technical point of view.) I'm just a familiar one to give an example, please do not associate, thank you. ）

When I do a website, I think about it from another perspective--from the point of view of the page

Maybe you look a little dizzy, this is what ah, a mess, don't worry, take me slowly way.

Please note that this is the Web page, excluding background management. Background management is another separate project, and the page is completely separate. Their links simply read the same database.

The first figure is divided into so many columns, but the home page of the essay list, the left and right on both sides of the list, news in the news list, groups in the group list, Group topics list and so on. These are list, form, data format (that is, the attributes of the class) are similar, then we can not abstract it. Abstract an entity class for these various lists.

First look at the small list

The column navigation on the homepage, the connection on the left, the topic, the blog list, the right 24 hours reading ranking, etc., this kind of is I said "small list".

What attributes are required for column navigation. Column name, connection address.
What attributes are required for the connection. Connection name, link address.
What attributes are required for the blog list? Blog name, connection address.
What attributes are required for a 24 hour reading ranking. Essay name, connection address.

Well, the other is not to say more, lest there is a suspicion of the number of words.

Now let's abstract it.

So many attributes, in fact, two attributes--name, connection address.

"Definition of a class for a small list"

Code///<summary>
A simple list
</summary>
public struct LISTINFO1
{
<summary>
The primary key ID of the record.
corresponding field name (alias): ID
</summary>
public string ID;

<summary>
Link addresses, for static pages or URL overrides, or dynamic pages
corresponding field name (alias): URL
</summary>
public string URL;

<summary>
Title, name, etc.
corresponding field name (alias): Title
</summary>
public string Title;
}

　

In so doing, a class can be used in many places, and new requirements need not be defined to define new classes, to avoid class explosions. Then the next step is to consider how to map. The idea of mapping is also very simple, a class in different places, and different tables (fields) to map.

Do not know if there is no such provision, do not allow the properties of a class and different tables of the corresponding fields.

You may ask, a property for a while and the name of the essay corresponds to a column name corresponding to, this is not disorderly. How to maintain, how to expand, and messed up again. This depends on how the mapping rules are defined.

The first thing to have is a document, which is required, in the document, where the properties of the class correspond to the fields of the table. This is the first step.

The second step is how this mapping is implemented. Actually quite simple, quite not easy to mess with.

I guess a lot of people are object-oriented habits, ORM is spoiled, the SQL statements have been forgotten.

　　

Select col0 as ID, col1 as Title, col2 as URL from table1

Do not know that you see this SQL statement, have no idea how I want to map. The right is to use the field alias to map. So mapping, you still think will map chaos. Will it be difficult to maintain?

Because the structure of an entity class is fixed , the code (function) that assigns values to the entity class is fixed , and only the SQL statement changes . Of course, how to display in the page is also a change.

In this way, the amount of code is reduced geometrically, and there is no need to use a code generator, which is to generate an SQL statement.

Field name changes, only need to modify the SQL statement, the entity class is fixed, do not change. The code that assigns a value to an entity class is also fixed, or it doesn't have to be changed. Greatly reduce the structure of the database changes to the impact of the code.

Today is Wuyi Labor Day, I wish you all a happy labor.

It's a nice day, I'll go out and get some sunshine. Come back and write.