Entity Framework - not needed?

Question

.NET

Not so long ago, I heard the opinion that "If for a long time, reliably and with support - this is the Entity Framework. If you quickly throw something simple - then ADO.NET". There was no time to discuss why the person thinks so, but I remember his point of view, because I saw it a little differently.
Eric Evans mentioned in his book Domain-Driven Design that developers often think of application objects in terms of database tables. Here we have a conditional "Order", so there is an order table, there is a "Supplier", which means that the table is like that. As a result, the application model ("domain") merges with the database structure, and if an idea / need to place data in some other way suddenly comes up, this directly affects the model, which is at least undesirable,
After all, the very conditional "Order" object that we create in the application and which is integral in it can be convenient to "smear" over several database tables, and then, when it is needed again, restore from these several tables.
Example: the class Order (Order) contains an identifier, creation date, anything else (it doesn't matter) and a recipient company. The recipient company (Client) is also a separate class with an identifier, a name, and some details. Accordingly, it will most likely be stored in the database as follows: the "Order" table and the "Company" table. In the "Order" table, the "Recipient" field will contain the company ID from the "Company" table. In the application, it would be much more logical for the Order object to have a field of type Client,
And so this approach "Single program object <--> Representation-in-a-database-such-what-is-now-more convenient", as far as I see it, is easily implemented through the usual ADO.NET. We simply write a data access layer in which we select the necessary data from any number of tables using classical SQL, restore the Client and Order objects, nesting the first into the second, and that's it. Simple and clear. The model remains isolated, and how it will be stored can be altered at least a hundred times in a way that is transparent to it.
In the case of EF, I don't see how this can be done. All the examples that I have seen on the Internet demonstrate the approach when the EF object is one to one database table. That is, an Order object is obtained with the same notorious int as the recipient company.
What in the end it turns out that just ADO is for "seriously and for a long time", and EF - "for simple cases, so as not to mess with queries when the application object is one to one database table"? Or where I missed something or misunderstood something?

Answer 1

EF gives you the ability to automatically translate expressions into SQL dialects and map it to convenient sub-entities. With bare ADO.NET, you will do the same, but by hand.
The scheme you propose is denormalized, generally speaking, this is not very good. But look at Owned Types for EF Core and Complex Types for EF6, it seems to me that this is what you would like to "embed" one object into another, keeping everything in a single table.
Yes, EF is not something that allows you to deviate much from the classical relational model, but with it you can call raw sql-queries pointwise , which will give more flexibility where necessary.

Answer 2

Greetings!
Yes, Evans wrote something similar, but his main emphasis was on the fact that the relationships that exist between the tables in the database, the developers transfer them to the model, thereby complicating everything.
And the example you provided demonstrates this very well! You don't need an object reference between Client and Order, because these are different aggregates and each of them implements its own invariants. But the link between the aggregates in the form of identifiers - int, Guid or something else, is just the recommended way.