Correct use of Symfony models when complex Querys are needed

Question

Correct use of Symfony models when complex Querys are needed

Navigation

#1 by (1 votes)

1

I am very new to Symfony, I was looking at the documentation regarding the models, and all the examples and indications place a lot of emphasis on entities ( Entities ) that are well defined in the DB. My problem is that the system I am doing requires many queries of the type

SELECT [MUCHOS CAMPOS, FUNCIONES CONCAT, CONDICIONES CASE, ETC] FROM TABLA_1
INNER JOIN TABLA_2 ...
INNER JOIN UNA_VISTA ...

So I'm half disoriented about which entity would have to declare (for the moment I'm handling the queries from the controller, but the idea is to respect the MVC model).

Do I make a table 1 entity and do all the queries in its class by doing INNER JOIN with the other tables without the latter having entities or do I have to create them for all? Do I need a repository, 3 (one for each entity) or none and I make the queries from one of the entities directly?

Clarification: the TABLA_2 and UNA_VISTA do not have queries of themselves in isolation, that is, I do not have any query in the type code

SELECT [CAMPOS DE LA TABLA_2] FROM TABLA_2

So I do not know how much it is worth declaring entities for both.

If you could give me a hand, even if it is a small guide, I would greatly appreciate it. Greetings!

php pdo symfony3

asked by Genarito 30.07.2017 в 01:57

source

1 answer

Subtract column value from the same column, previous record Property not found in java.lang.string

score 1 · Accepted Answer

We're going through parts ...

You should have an entity for each table or view of your data model.

Even if you do not make queries directly about TABLA_2 or UNA_VISTA , it is necessary that they are modeled so that the ORM knows how to map their fields, since they will be used as elements within another query (by inner join )

The repository is a useful class where you can host all the code related to operations with a model or entity, it is usually a good idea to have this type of centralized operations, it makes the code more reusable.

In doctrine , entities are objects that represent your data models, they are not the place to make queries. In fact, they are not equipped with the necessary tools for you to do them, this should be done in a repository.

You can configure the relationships of an entity with other entities so that the ORM automatically includes a INNER JOIN . This is done with a directive called fetch , which depending on the type of relationship can adopt the values: eager , lazy or extra_lazy . By default, its value is lazy , which will cause the ORM to preload the relationships of an entity, but without consulting said values strictly. The value eager forces the ORM to bring the data of the relationships of an entity, normally through a INNER JOIN . If in your queries to TABLA_1 you are going to use as criteria only fields of TABLA_1 , this configuration will serve you. If you need to use more fields, you will have to generate a repository for this table and generate your own find method with the necessary fields. Within this method you can use the QueryBuilder of doctrine or DQL

With an ORM as doctrine , you do not perform queries for concatenated fields or case conditions. Instead, you extract entities, and those entities are the ones that have a method that returns the values of the formatted fields as you need.

Keep the controller as simple as possible. Query entities in a repository type class or create services where to host the business logic. You should see the controller as a mere HTTP interaction layer (Receive Request and issue Response , only)