PHP database ORM implementation necessity

In fact, it is not in conflict with the concepts of learning new things and some "advanced", but I have always been concerned with only one thing: I can't use it in my project. what is the purpose of this thing, what are the advantages and costs? Many online users say that object-oriented database operations can directly decouple the Model layer... in fact, it is not in conflict with the concepts of learning new things and some "advanced", but I have always been concerned with only one thing: I can't use it in my project. what is the purpose of this thing, what are the advantages and costs?

Many online users say that the object-oriented database operation method can directly decouple the Model layer without worrying about how it is implemented, and the OOP method can be used, such as getXXX () to obtain the value of a field in the record.

In fact, I have always wanted to do a travel site (similar to Baidu tourism/horse Honeycomb), Directory structure is also put forward in the http://segmentfault.com/q/1010000002890348, Midway also because I have read a lot of IoC articles is very headache, it is found that it is difficult to reflect its advantages because of the scale of the project. Instead, it increases the burden for design. Layering has made the action as simple as possible, and the Model can also be well reused.

1. I really don't know why I'm using ORM more and more? Is it because of the need for object-oriented programming (too general )? Or can my query result objects be cached? If the website traffic is high, is it the final solution to cache the query results in the form of objects? Can KV-based noSQL be replaced? What about the database's own cache?

2. in fact, decoupling is not the most important issue (I think it has not reached the point where decoupling is required, and the reusability brought by the above layers is already quite good ), the ORM builder is also drunk, so it is better to write SQL statements directly in the Model, and directly rewrite the database in the future (don't worry about this problem, it's not a bad time ), I feel that the performance and reuse have always been a little different. let alone the reusability and decoupling requirements. Is it because of the benefits of object cache if I want to use ORM?

3. In addition, the company's eldest brother said that join should not be used to directly nest queries. I said that is not the assumption that 15 articles on the article page contain author information. I will run 15 post tables, 15 more user tables in the middle? He said that the query results can be cached. I don't know whether the cache is database-level or Model object-level?

No more comments. thank you for your answers!

Reply content:

In fact, it is not in conflict with the concepts of learning new things and some "advanced", but I have always been concerned with only one thing: I can't use it in my project. what is the purpose of this thing, what are the advantages and costs?

Many online users say that the object-oriented database operation method can directly decouple the Model layer without worrying about how it is implemented, and the OOP method can be used, such as getXXX () to obtain the value of a field in the record.

In fact, I have always wanted to do a travel site (similar to Baidu tourism/horse Honeycomb), Directory structure is also put forward in the http://segmentfault.com/q/1010000002890348, Midway also because I have read a lot of IoC articles is very headache, it is found that it is difficult to reflect its advantages because of the scale of the project. Instead, it increases the burden for design. Layering has made the action as simple as possible, and the Model can also be well reused.

1. I really don't know why I'm using ORM more and more? Is it because of the need for object-oriented programming (too general )? Or can my query result objects be cached? If the website traffic is high, is it the final solution to cache the query results in the form of objects? Can KV-based noSQL be replaced? What about the database's own cache?

2. in fact, decoupling is not the most important issue (I think it has not reached the point where decoupling is required, and the reusability brought by the above layers is already quite good ), the ORM builder is also drunk, so it is better to write SQL statements directly in the Model, and directly rewrite the database in the future (don't worry about this problem, it's not a bad time ), I feel that the performance and reuse have always been a little different. let alone the reusability and decoupling requirements. Is it because of the benefits of object cache if I want to use ORM?

3. In addition, the company's eldest brother said that join should not be used to directly nest queries. I said that is not the assumption that 15 articles on the article page contain author information. I will run 15 post tables, 15 more user tables in the middle? He said that the query results can be cached. I don't know whether the cache is database-level or Model object-level?

No more comments. thank you for your answers!

If you have 10 or even five friends writing SQL together, today this person joins three tables, and tomorrow the person writes the subquery, and the other person tries to update the where condition in batches the day after tomorrow, then, on average, there are three bugs caused by incorrect field names and words every day, so you will know the valuable ORM.

We have also encountered the same problem recently. The performance of ORM is indeed much lower than that of native SQL. ORM is only suitable for fast and agile iterative development.

The performance of the ORM will indeed decrease, so it depends on how it is selected-if it is necessary to quickly make the website usable, the ORM may be faster, especially with code generation tools such as zii.

Don't fall in the trap of premature optimalization
Locate the bottleneck. Is the key. Do not tangle with the efficiency of a certain part.

We recommend that you use a short and concise ActiveRecord library, such as loydzhou/activerecord-GitHub, to implement relation similar to Yii. Document address: http://lloydzhou.github.io/activerecord/

class User extends ActiveRecord{  public $table = 'user';  public $primaryKey = 'id';  public $relations = array(    'contacts' => array(self::HAS_MANY, 'Contact', 'user_id')  );}class Contact extends ActiveRecord{}$user = new User();// find one uservar_dump($user->notnull('id')->orderby('id desc')->find());echo "\nContact of User # {$user->id}\n";// get contacts by using relation://   'contacts' => array(self::HAS_MANY, 'Contact', 'user_id'),var_dump($user->contacts);

Using SQL means you cannot change the database because SQL is not common.
Using join means that your project can only be in one database, and join is more complex across databases.
There is no need to use orm for small projects. as you said, it's not a bad time.

But big projects are different. to split the database and change the database, today mysql may use hbase tomorrow and may be mixed.

Model-level