Why does everyone need Doctrine so much if he doesn't know much?

Question

Doctrine ORM

I work in a company where the doctrine is used (version 2). If the doctrine does not know how to do something, then the request is rewritten to plain SQL. Faced with the fact that there are enough restrictions, doctrines cannot IFNULL, MySQL full-text search is lame, the subquery mechanism is not very convenient, for working with YEAR, Month and similar stock mysql functions it works only if something is tweaked somewhere in the drivers. Insert through persist, flush does enough time. Actually, I don't think that's all. Why is the doctrine so praised by so many? So far, I have seen solid cons for myself.

Answer 1

Almost any abstraction over anything is always a compromise between speed and maintainability. The doctrine, like any other abstraction, is a choice in favor of the speed / convenience of development with the rejection of universality in queries. Just such a choice was made in your project, it is not known whether it is correct or not, but if the project is already working and living (and making a profit), then this tool is unlikely to be replaced.
Not a single professional (if he is really a pro) will say that "this is cool", and the rest is shit. For he understands that each tool has its pros and cons and is suitable for its tasks. The ability to see this balance is professionalism.

Answer 2

Doctrine implements a conceptually different approach to working with data, this is its great advantage and this is where its limitations follow.
If you've ever come across design patterns, you may have heard of a man like Martin Fowler and his book "Patterns of Enterprise Application Architecture". It describes design patterns for enterprise-level applications. In this book, Fowler proposed a set of patterns that organizes work with data sources through the representation of this data in the form of interconnected objects. This set includes Data Mapper , Identity Map , Unit of Work and many other patterns.
If you go a little deeper, then the essence of Doctrine is the ability to work with data in the database as with ordinary objects. If you think about it, this opens up unprecedented prospects in ensuring the predictability of the development and support of the project code. provides the developer with the opportunity to abstract from the details of information storage and focus on an important part of his work - the implementation of the business logic of the project. Doctrine, on the other hand, takes care of ensuring that the application receives the necessary data when it needs it, that this data is correctly stored so that there are no conflicts, etc. etc.
Try to imagine a large business project with many people working on it, where there are hundreds of kinds of data interacting with each other and complex processes involving many kinds of data are defined. Of course, all this can be written and maintained manually, there are many such examples, the question is the cost of such work. Imagine having to manually write a sequence of queries to save data to 20 tables, and having to keep that code correct as the project's business requirements change next time. I am sure if after half a year of such work you are offered to replace all this with one line $em->flush(), you will gladly agree and, perhaps, then you will understand what Doctrine gives the developer.
It is from the idea of ​​shifting the developer's focus from the implementation details of the data warehouse to the implementation details of the business logic of the project that Doctrine's limitations are born. They can be perceived negatively if you try to think of Doctrine and DQL as stripped-down SQL, for some reason returning objects, not arrays. Yes, of course, you won’t build any complex analytical queries on DQL, but this is only because Doctrine has a different goal. If you look at DQL a little closer (for example, how joins are described in it ), you will notice that Doctrine is based not on how the data is arranged in tables, but on how the data is presented in entities. This is not the most noticeable, but very important difference. it defines the space of data operations. Roughly speaking, given by youifnull()in DQL becomes a rather meaningless construct. this function is rather weakly applicable to objects.
Of course, in real projects there are often tasks that require working with data in the database outside of Doctrine, this is normal, no tool is comprehensive. However, the “shortcomings” of Doctrine that you describe stem rather from a lack of understanding of what kind of tool it is and why it is needed, what tasks it is designed to solve. This misunderstanding is resolved by examining what you are working with on a deeper level. If you decide to eliminate it, you will get your hands on one of the best tools for working with data in business projects that the world of PHP has, and then, hopefully, you will be able to appreciate it.

Answer 3

I work in a company where the doctrine is used (version 2). If, of course, the doctrine does not know how to do something, then the request is rewritten to plain SQL.

In fairness, I think it's worth noting that none of the ORMs I know can do "everything", even at the MySQL level. And if we talk about more advanced databases (in terms of functionality), for example, PostgreSQL, then ORMs generally "can't do much" (in percentage terms).

Actually, I don't think that's all.

I am more than sure that this is not all.

Why is the doctrine so praised by so many? So far, I have seen solid cons for myself.

I would not be so categorical (the cons are still not continuous, there are definitely some pluses in it), but, to the question "why?" I personally concluded for myself that the main popularity of Doctrine is due to the fact that it is (or was) shipped with Symfony by default, and Symfony, in turn, won the main popularity because for a long time it (a) was considered the most complex (or one one of the most complex) PHP frameworks, with a fairly high entry threshold, which in turn elevated it to the rank of a kind of "idol" that distinguishes an "experienced" developer from those who, for various reasons, could not master Symfony (or did not want to). Here is the chain...
PS Everything written above is my subjective observation, based on my personal experience of working with students and people who improve their skills in terms of web development. Dear colleagues, I earnestly ask you not to make a srach under this post, unfortunately I do not have enough time to conduct an objective discussion, but to support a skirmish is a desire.

Answer 4

The doctrine is big. There is DBAL, there is a qveri builder, there is an ORM.
Specifically, we use as an ORM. Because it is convenient to work with objects .
You have to pay for convenience.
About "the most complex framework" and "idol" - this, of course, is baby talk.