The way of Architecture (V): Forget the database

So much has been written in the front, largely to prepare for this chapter. Object-oriented or domain-driven, the most important thing is to forget the database! It took me a long, long time to understand this and really move on to a new world, and then it took me a long, long time to do just that; I hope that someday this will no longer be a problem and I don't need to think about it ...

Why the business layer is so thin

After the three-tier architecture was popular, it was clear that the UI layer was responsible for page interaction and called the next layer, and that the DAL layer was dealing with the database. But the BLL layer? What is "business logic"? There are all sorts of explanations, but aren't they all SQL? For the vast majority of application systems, in addition to the database to "delete and change", I really do not know what else to do? Not to mention, there are super-powerful stored procedures!

So, a lot of systems, even reluctantly make a business layer, also "thin" is outrageous, like a layer of plastic film, let a person have it immediately tore off the strong impulse.

Why?

This has to be from. NET camp from the history of speaking. NET camp's classmates know that the three-tier architecture, mostly from PetShop, is a classic of the three-tier architecture, and many projects even replicate their architecture directly. At the time, it was a remarkable advance. At that time, or from ASP to ASP, many ASP projects, SQL code is still written in the HTML! Therefore, the separation of the UI and the Dal undoubtedly has a detailed demonstration effect.

But Microsoft's pace, a modest, just pulled the egg.

Step a little bit, make a two-storey structure, estimate a little problem is not, everyone can accept, step a little bit bigger, will have to ORM, unfortunately Microsoft was not conditional support. So I got out of the concept of a shady and confused, tortured me for a long time ...

Long. Net of the camp, at the application level, in fact, is "database-oriented". It can be seen from datasets, DataGrid, Datasourcebinder and the like. Even the entity Framework, at first, is the table from the database. NET classes are mapped. These, are greatly restricted. NET camp students to expand the object-oriented thinking.

Fortunately, I finally jumped out.

Database oriented

To illustrate, let's give you one of the simplest examples.

The requirement is: Record the number of views (article) of the article (Viewcount). Whenever the article is read (view) at a time, the number of views plus one.

What is the first thing you think of when you see this demand? Isn't it:

Update Article Set Viewcount = Viewcount + 1;

If this is the case, congratulations, you also firmly hold the "database-oriented" position.

/* Database-oriented is not unacceptable, and object-oriented is not necessarily more advanced than database-oriented. This is only the choice of two roads, if you would like to see the scenery of another road, please continue; */

Object oriented

So what should the object-oriented or domain-driven drive do?

        public void View ()        {            //Remove Article            Article Article = Session from the database. Load<article> (ArticleID);                        Change the Viewcount property of the article            article. Viewcount + = 1;            The changed article is then deposited into the database            session. Save (article);        }

How do you feel? A light, or is it incredible? Think a little deeper, do not think this is a superfluous, a SQL can solve the problem, so complicated?

I was, the most considered, the most unacceptable, is the performance problem.

1. This must take advantage of ORM, even if the SQL generated by the ORM is not high efficiency, the cost of generating SQL should not be low?
2. To do this, take data, open a database connection, save the data, and open a database connection. Even if there is a connection pool, it is not better to save a little bit.

So, if you're like me, go back to my previous blog!

In doing so, there are a number of other specific technical issues that we will follow up on the following blog.

Why

Why do we have to go back in the big direction? In other words, what is the problem with "database-facing", or what is the benefit of "object-oriented"?

I think that the "abstract", "decoupling", "reuse" and the like, have not touched the fundamental. The most fundamental reason is that our brains are not adapted to abstract the world into a single table, but rather to one object . As the system becomes more complex, the phenomenon becomes more apparent.

I have been involved in a project, its database structure to print out, the map so a big piece of paper (I do not know the number of a few), dense all is the table, a variety of lines staggered among them, I looked at the scalp numbness. Department inside like a treasure to give this table, because the company can not print and can't copy Ah! (I don't know how they got it at first, it's probably a problem)

If you read and think about it, you'll find, "No, how many tables are there and how many classes are not as complicated?" ”

Yes, and because of abstraction, classes are likely to be more than tables. However, in the abstract, in our architecture, design, communication, we can temporarily discard a lot of details. For example, we can say, "after the article is commented, the article author's points plus 10 point", this time, we do not consider the article there are many kinds of: blog, news, questions and answers, comments ..., do not consider the increase in points is directly to change the score points, or add an integral record, or to synchronize .... What do you say if you have a table?

Of course, the structure of a table can also be designed to look like inheritance (the inheritance of classes will eventually be mapped to a table structure), but how do you show this abstract relationship in communication? More importantly, a concept commonly used in software engineering: delegation.

Simply from the point of view of the program, the use of ORM, object-oriented, but also increased the complexity of the system. After all, it's not a simple task to map objects to a database, especially when you have to consider performance issues.

Then why do we have to do this? delegate, in other words, to push complexity elsewhere. I remember repeating this point, one of the important tasks of architecture is to divide and shuffle complexity . Split estimate everyone understands, but what does "buck" mean, and to whom? Whatever it is, I only do what I classify, other, UI push to BLL,BLL push to dal,dal push to DBA,DBA push to purchasing department ...

It's funny to write here, but that's the truth. In the performance chapter, I said, you want to write high-performance code, you just rob someone else's job, that's what it means. What does the UI do with the DBA's work and what do they eat? Your code is written in 10,010,101,010,102, not to mention the assembly, the CPU is estimated to live.

We are here to push the complexity to the Map team, ORM Tool developers, and DBAs.

Because we want to talk to our customers about demand, what is the common language that is typically domain-driven, and where customers/domain experts find "common language"? Is the table structure? It is estimated that if a financial accounting system is developed, it is still possible-estimating that the early systems are mostly financial reporting systems? Maybe that's the way it is. Why object-oriented from Java is popular, Java is a virtual machine, can be used in the microwave oven alarm, such as above, the underlying data structure can be completely detached from the database Ah! NET do what started, on the report Ah! Oh.

In short, the development to this day, with the increase of system complexity. In the architecture design of the system, we have to map the real world first into an object that can be encapsulated, with inherited polymorphism, and focus on the maintenance of these object relationship functions.

Database? Let's just ignore it.

Only out of the constraints of the database, we can freely soar in the object-oriented world!

I can't forget it.

"The problem is I can't forget it!" ”

"I just need to see the demand, the brain is immediately the database is the table." ”

"I don't know how to start writing code without a database. ”

......

Yes, it's hard to forget the database--especially for our old people. have been steeped in SQL for decades of master, you let me forget it? Do you think writing novels, Zhang Mowgli learn Taiji ah?

I can only talk about how I did it, I hope I can give you some reference.

I'm assuming my system is not storing data in a "relational database", not MySQL, not Oracle; I use NoSQL, I store it in an XML file, okay? What's the use of NoSQL? I don't know, I got nine out of ten. But I'm going to start building my bll/domain layer when I don't know how nosql is going to work. And I only set one of the simplest assumptions:

• All objects can be directly from the hard drive load ()
• All objects can be directly save () to the hard disk
• objects can be associated with 1:1, 1:N, n!

How to access it from the hard drive (so-called "persistence"), then again. I do not know what to do with persistence, how to think now? But there is a, anyway, will not use relational database, it is estimated to use NoSQL bar ...

The ultimate expectation

The Real object Database! Come out now, please.

The convention says my project is progressing:
1, write the document to spit ...
2, the reconstruction tired became the dog ...
The plan released a new version of this blog, but it can not be dragged. Blog series Next, into the project of the specific development, the code is also disorderly into a heap, ah ...

The way of Architecture (V): Forget the database