The key to the battle between EF and Dapper

Suddenly found in the garden for EF and dapper things out of the sky. (The classmate who learns Java is probably hibernate and MyBatis's argument)

When it comes to EF's support for MySQL, I'm on the side of stealing: Fortunately I use nhibernate, support for MySQL is good, haha ...

Cough, this is certainly wrong, should be criticized. I review three seconds, first.

I read the article, also read the comments (but did not read). To be honest, I feel that there is only one word on Sansheng stone that can stand the foot:

The real problem is not the Entity Framework, but we, OK, just let it go: we miss the SQL statement too!

Others, well, already have a lot of people say a lot, I will not join in the fun.

I do not know if you remember what I said before:

While we have a C # object-oriented language, many of our developers are still "database-oriented" programming.

To avoid a greater controversy, I must first declare that:

object-oriented and database-oriented are not superior to the pros and cons of .

object-oriented and database-oriented are not superior to the pros and cons of .

object-oriented and database-oriented are not superior to the pros and cons of .

The important thing to say three times.

Choosing dapper, or even ADO-SQL, is essentially "database-oriented" programming. What do you mean? All the development process is based on the database, the whole system architecture is based on the database table structure. When encountering a business logic, the first thing that comes to mind is which tables the data is placed in, what SQL statements are taken out of them, and then how to encapsulate the data into classes ... This is what I call "database-oriented" programming.

So, what is "object-oriented programming" relative to it?

Forget about the database, especially the relational database, as I've said before, you can imagine that this data is ultimately stored in the XML file, stored in NoSQL, and stored on what other disk. Of course, the ideal is to have an "object database", all the data are stored in the form of objects, the data and data is the relationship between the object and the object, there are inherited references, are load out. Come out. In summary, SQL statements do not work at all. So, when encountering a business logic, the first thing that comes to mind is what objects these data are stored in and how they are loaded ...

Do you understand? This is the "object-oriented" thinking!

Where is the table and what SQL is there? We only have objects in our eyes! All things are object, Amitabha ...

But, the thing of the world, the most afraid is this but!

There is no "object database", only "relational database" Ah? This is a problem that is always unavoidable: almost all enterprise-class applications are memory-based with relational databases. This is the trouble, how to do?

The object-oriented fans have introduced an ORM (Object relational map), a mapping between the object and the relational database table, hoping to solve this problem. We must understand that ORM is the beginning of the O, the core of its essence, is to map object into a relational table, object is the first bit. Instead of many classmates, the ORM as a SQL statement generator or SQL language encapsulation, its role is "do not write SQL." Not like this, the cart before the horse, classmate! Well, in this sense, dapper is not an ORM (do not do the definition of the controversy, we understand the meaning of the line), he is an ideal dbhelper just.

Accordingly, EF, as a heavy ORM tool, is being despised. It's natural, I don't know. No, when your mind is "database oriented", ORM is really a burden, not only because it's "heavy", but also because it obscures the details of the SQL implementation: I can't see the SQL. But also special to set a breakpoint to check the log to see what the SQL generated, this is suppressed ...

And ORM does have problems when it comes to complex object mappings, complex queries, and now the tool is not perfect.

What about the whole thing?

I think this is a matter of personal (or team) preferences.

"Database oriented" itself is no problem. Database based on table structure, CRUD, what's wrong? The nature of the regression code also conforms to the kiss (Keep It Stupid simple) Principle! Countless successful projects have been done in this way and have been working well. On the contrary, the complete "database-oriented" design architecture, the collapse of the project is a lot of it?

However, personally, I prefer the idea and direction of "object-oriented". There are several reasons for this:

1. Don't like SQL. This is probably the decisive reason, especially the hatred of the stored procedure, especially the hundreds of of thousands of rows of stored procedures, particularly the collapse of the same feeling. "Database-oriented" is the ultimate "stored procedure programming", if all go extreme, compared to the "object-oriented" The ultimate I feel can accept-all the code see a line of SQL, nothing.
2. ORM is constantly progressing. EF I'm not familiar with many of NHibernate5.0 's new features that make me really bright, the most inspiring is that colletion on query () can generate SQL queries without having to load the entire collection. It's a feature I've been looking forward to for a long time, so cool! Many of the previous walkaround for performance are not needed, and the code is very clear. I believe that the ORM tool will continue to evolve until it is infinitely close to perfection, or the "Object Database" is born. "Database-oriented" does not require a BLL layer at all. Take the data out of the database, packaged into classes, why? Superfluous, it's totally. Even if we were to encapsulate it, I think the strongly typed dataset would suffice. But dateset these have been cold, plainly, "database-oriented programming" has been that way, can use, but nothing developed; but ORM, there are a lot of people in the company's efforts to improve, there is room for progress.
3. Too many tools or means must be matched with "object-oriented". For example, unit testing, I do not know how other people play, anyway, my unit test is to isolate the database, test data, the direct new is OK, fast and lightweight. mixed with SQL statements or stored procedures, must be attached to the database, this unit test do? I really don't know. In addition, the domain-driven, "database-oriented" also no way to play, you and "domain expert" table structure and SQL, people will collapse.
4. ORM retains your right to use native SQL in special cases. In fact, you can write your own SQL!

Almost, I think it can be summed up briefly, I hope students:

• Can understand the difference between "object-oriented" and "database-oriented" from the strategic height;
• Understand the inadequacy of ORM, but have confidence in the development of ORM.

Cough, this accent more and more like a teacher. Yes, Everyone is a program ape has been started for a long time, today is the 18th lecture, the introductory type of popular courses, interested students can listen to, Or for the new people around the propaganda, thank you first!