1
00:00:00,620 --> 00:00:08,000
En los vídeos anteriores hemos estado viendo cómo manejar Doctrine con una sola tabla.

2
00:00:08,619 --> 00:00:11,439
Este vídeo es más bien explicativo, más que desarrollar.

3
00:00:11,960 --> 00:00:19,859
Vamos a utilizar el ejemplo que hemos seguido en clase y en este caso vamos a ver cómo vamos a relacionar las distintas clases.

4
00:00:21,179 --> 00:00:26,359
Conocemos la clase usuario. La clase usuario, en este caso, ya sabemos que es una entidad.

5
00:00:26,359 --> 00:00:32,240
es la tabla relacionada con una tabla que se llama el usuario

6
00:00:32,240 --> 00:00:34,820
y vamos a generar un repositorio, una clase de repositorio

7
00:00:34,820 --> 00:00:38,039
donde tendremos una serie de métodos que nos permitan acceder a la información.

8
00:00:39,320 --> 00:00:42,320
Bueno, identificamos la clase de usuario de esta manera

9
00:00:42,320 --> 00:00:44,159
y ahora vamos a ir al primer campo, el campo id.

10
00:00:45,119 --> 00:00:48,399
No tiene mayor importancia, ya hemos visto en el ejemplo anterior

11
00:00:48,399 --> 00:00:53,299
id es un id que es entero y que el valor es autogenerado.

12
00:00:53,299 --> 00:00:58,320
a la columna nombre, que es una columna de tipo string, la columna nacido

13
00:00:58,320 --> 00:01:02,140
que es de tipo string, ya veríamos que esto en otros casos sería de tipo fecha

14
00:01:02,140 --> 00:01:06,079
pero de momento vamos a dejarla como string, ¿de acuerdo? que estamos trabajando con ese culite que no diferencia

15
00:01:06,079 --> 00:01:10,079
mucho strings de fechas, y empezamos aquí

16
00:01:10,079 --> 00:01:13,659
lo importante, vamos a definir una tabla

17
00:01:13,659 --> 00:01:17,819
una tabla, una clase, sexo, aquí la tenemos por aquí, y vamos a decir

18
00:01:17,819 --> 00:01:22,260
que muchos usuarios van a tener

19
00:01:22,260 --> 00:01:26,299
un sexo, es decir, y podríamos decirlo al revés

20
00:01:26,299 --> 00:01:29,939
un sexo lo pueden tener muchos usuarios, con lo cual sería una relación

21
00:01:29,939 --> 00:01:33,739
desde aquí, desde el usuario de many to one, muchos a uno

22
00:01:33,739 --> 00:01:38,219
lo primero que hay que decirle, estamos en usuario, y lo primero que hay que decirle

23
00:01:38,219 --> 00:01:42,040
es con qué clase tiene relación

24
00:01:42,040 --> 00:01:46,099
en este caso con sexo, después tenemos que decir exactamente lo que haríamos

25
00:01:46,099 --> 00:01:49,780
en un join, en un select vulgar y corriente, el join lo hacemos

26
00:01:49,780 --> 00:01:56,780
con la tabla sexo y la columna o campo con el que está referenciado es el campo id.

27
00:01:57,459 --> 00:01:58,980
Bueno, hasta aquí es algo muy normal.

28
00:01:59,879 --> 00:02:02,579
El otro caso que tenemos es deportes.

29
00:02:02,579 --> 00:02:08,780
Un usuario va a practicar muchos deportes en general y un deporte va a ser practicado

30
00:02:08,780 --> 00:02:12,740
por muchos usuarios, con lo cual nuestra relación en este caso es many to many.

31
00:02:13,180 --> 00:02:18,439
La entidad con la que vamos a tener relaciones con deporte y la tabla que hace de enlace

32
00:02:18,439 --> 00:02:23,740
entre usuarios y deportes, pues lo llamamos de esta manera, usuario-deporte.

33
00:02:24,680 --> 00:02:29,680
Bueno, aquí ya tenemos no solamente cómo enlazamos hacia allá, es decir, con nuestro

34
00:02:29,680 --> 00:02:35,939
identificador de usuario referenciamos a y d, sino también cuál es la relación inversa.

35
00:02:36,400 --> 00:02:41,759
Entonces, con id de deporte relacionamos con su id, ¿de acuerdo? Tenemos las dos,

36
00:02:41,759 --> 00:02:46,759
tanto el join hacia adelante como el join en la otra parte de la relación.

37
00:02:46,759 --> 00:03:16,159
Y aquí tendríamos deportes. Voy a continuar porque lo único importante aquí es esto de aquí. Para las relaciones de tipo many to many nos hace falta que creemos una estructura que se llama de tipo array collection para que nos guarde para cada usuario todos los objetos de deporte que practica. ¿De acuerdo? Y esto hay que crearlo siempre que tengamos una relación many to many. También en los casos one to many. ¿De acuerdo?

38
00:03:16,759 --> 00:03:21,939
Bueno, lo demás exactamente igual. Aquí tenemos los getes y aquí los setes.

39
00:03:22,460 --> 00:03:25,979
Por aquí abajo asoma el repositorio, del cual hablaremos en otra ocasión.

40
00:03:26,919 --> 00:03:29,340
Vamos a ir a sexo, a ver qué tenemos en sexo.

41
00:03:30,020 --> 00:03:34,699
En sexo tenemos exactamente la definición de sexo.

42
00:03:34,699 --> 00:03:38,639
No hay nada nuevo aquí, nada, absolutamente nada nuevo como se puede ver.

43
00:03:39,000 --> 00:03:39,099
¿Vale?

44
00:03:40,599 --> 00:03:46,280
Estábamos, recordamos que de usuario era una relación many to one, con lo cual este no tiene ninguna relación.

45
00:03:46,280 --> 00:03:58,120
Sin embargo, en deporte tenemos la definición normal de los campos que tiene y tampoco tenemos en este caso ninguna relación.

46
00:03:58,379 --> 00:04:04,620
Ya veremos que de esta manera, aunque sea many to many, vamos a actuar como si fuera many to one, ¿de acuerdo?

47
00:04:04,819 --> 00:04:07,180
Pero bueno, eso ya lo veremos posteriormente.

48
00:04:07,180 --> 00:04:16,220
Si quisiéramos que realmente fuera many to many y esta tabla, esta clase, alojara también los objetos que practican un deporte concreto,

49
00:04:16,279 --> 00:04:20,339
tendríamos que incluir aquí el equivalente al que hemos visto en usuarios

50
00:04:20,339 --> 00:04:24,120
poniendo aquí private que usuarios son

51
00:04:24,120 --> 00:04:28,139
y definiendo aquí las características correspondientes

52
00:04:28,139 --> 00:04:32,540
para relacionar esta entidad con la entidad usuaria

53
00:04:32,540 --> 00:04:35,819
bueno, con esto nos quedamos de momento

54
00:04:35,819 --> 00:04:36,959
voy a dejarlo como estaba

55
00:04:36,959 --> 00:04:43,519
y esta es la explicación de los campos que se manejan hacia el otro lado

56
00:04:43,519 --> 00:04:45,939
¿cómo funciona esto?

57
00:04:45,939 --> 00:05:03,259
Bueno, ¿cómo funciona esto? Pues es muy simple. En el caso de usuario hemos creado un pequeño repositorio en el cual algunos métodos que utilizamos en nuestra aplicación, pues hemos puesto aquí su equivalente. Esto no nos hubiera hecho falta, podríamos haber directamente hecho esto, pero queda bien.

58
00:05:03,939 --> 00:05:21,959
El repositorio usuario extiende el repositorio de entidades en general y lo que estamos haciendo aquí es decirle que cuando leemos a un usuario que tiene, o estamos buscando un usuario que tiene un identificador, vamos a llamar a gestor de entidades y vamos a buscar el usuario ese identificador.

59
00:05:21,959 --> 00:05:37,360
Si queremos buscar todos, pues en este caso los quiero además ordenados por el nombre, pues seleccionamos todos los objetos de ese usuario, de los usuarios que hay, los ordenamos por nombre y obtenemos el resultado.

60
00:05:37,360 --> 00:06:03,120
¿De acuerdo? Esto es una manera de hacerlo. Si vamos al sexo, que también hemos incluido esto para trabajar con lo que había, tenemos nuestro read igual, nuestro read all igual y además tenemos un read indexed que nos va a servir para después mostrar, ven aquí, options y la posición es el id y el valor el nombre, con lo cual esto nos va a servir después para los campos de tipo option o similares.

61
00:06:03,120 --> 00:06:04,139
y en deporte

62
00:06:04,139 --> 00:06:06,639
idendeide

63
00:06:06,639 --> 00:06:08,660
¿de acuerdo? esto es lo que vamos a tener

64
00:06:08,660 --> 00:06:10,199
con todo esto

65
00:06:10,199 --> 00:06:12,060
y ya sabiendo esa estructura

66
00:06:12,060 --> 00:06:14,439
es verdad que vamos a ahorrar bastante trabajo

67
00:06:14,439 --> 00:06:15,579
a la hora

68
00:06:15,579 --> 00:06:18,279
de manejar nuestra librería

69
00:06:18,279 --> 00:06:19,379
en nuestro controlador

70
00:06:19,379 --> 00:06:22,279
se mantiene siendo un controlador muy sencillo

71
00:06:22,279 --> 00:06:23,959
y en nuestra librería

72
00:06:23,959 --> 00:06:25,740
en la que realmente maneja

73
00:06:25,740 --> 00:06:28,620
todo lo que tenemos que hacer

74
00:06:28,620 --> 00:06:30,259
pues ya vemos que por ejemplo

75
00:06:30,259 --> 00:06:32,720
añadir una opción, pues va a ser crear usuario

76
00:06:32,720 --> 00:06:35,519
hacer los sets correspondientes para darle su valor

77
00:06:35,519 --> 00:06:38,100
añadir los deportes

78
00:06:38,100 --> 00:06:43,420
y ya finalmente, pues, simplemente hacer persistir al usuario y añadir

79
00:06:43,420 --> 00:06:46,160
modificar, pues, id de id

80
00:06:46,160 --> 00:06:48,399
simplemente, esta línea nos sobraría

81
00:06:48,399 --> 00:06:51,899
incluso, simplemente, haciendo el flush

82
00:06:51,899 --> 00:06:56,779
y en eliminar, pues, lo remolramos y ya está

83
00:06:56,779 --> 00:07:00,040
en el read, pues, leemos con el identificador

84
00:07:00,040 --> 00:07:04,000
y en el reader exactamente como aparece aquí

85
00:07:04,000 --> 00:07:06,920
recuerdo que estos readers los hemos hecho

86
00:07:06,920 --> 00:07:08,939
que realmente lo que están haciendo es llamarnos

87
00:07:08,939 --> 00:07:11,699
llamarnos, en este caso el DAO

88
00:07:11,699 --> 00:07:14,100
está llamando al repositorio

89
00:07:14,100 --> 00:07:15,279
por eso es muy interesante

90
00:07:15,279 --> 00:07:16,759
es muy interesante

91
00:07:16,759 --> 00:07:19,680
esto, este repositorio

92
00:07:19,680 --> 00:07:22,620
donde llamamos directamente a estos métodos

93
00:07:22,620 --> 00:07:24,939
de tal manera que entre el programa que hicimos anteriormente

94
00:07:24,939 --> 00:07:27,199
y este programa pues no hay grandes diferencias

95
00:07:27,199 --> 00:07:29,160
si lo programamos desde cero a lo mejor

96
00:07:29,160 --> 00:07:31,639
hay cosas de aquí que hubiéramos eliminado

97
00:07:31,639 --> 00:07:34,259
bueno, espero que haya aclarado

98
00:07:34,259 --> 00:07:36,660
esta cuestión y ya por último

99
00:07:36,660 --> 00:07:38,639
simplemente decirles que en Doctrine

100
00:07:38,639 --> 00:07:40,639
en el manual, en la documentación

101
00:07:40,639 --> 00:07:42,180
pues aparecen todas las posibilidades

102
00:07:42,180 --> 00:07:44,060
que ofrece esto y que realmente

103
00:07:44,060 --> 00:07:46,560
va a ser a medida que nos vaya haciendo falta

104
00:07:46,560 --> 00:07:47,959
cuando nos vayamos a buscar

105
00:07:47,959 --> 00:07:49,540
pues

106
00:07:49,540 --> 00:07:52,540
cómo podemos obtener un tipo de información

107
00:07:52,540 --> 00:07:54,720
u otra, pero que el mecanismo

108
00:07:54,720 --> 00:07:56,560
es bastante fácil, bastante fácil

109
00:07:56,560 --> 00:07:58,279
y bastante simple, y que cuando hacemos

110
00:07:58,279 --> 00:08:02,300
una aplicación que se atiene primero a ORM

111
00:08:02,300 --> 00:08:06,220
y además utiliza el patrón modelo vista controlador, pues

112
00:08:06,220 --> 00:08:10,399
realmente tenemos una aplicación que es fácil de mantener y fácil de irla generando

113
00:08:10,399 --> 00:08:13,980
a pesar de que a lo mejor en el inicio haya que establecer demasiadas cosas

114
00:08:13,980 --> 00:08:17,139
pero después lo vamos a rentabilizar rápidamente

115
00:08:17,139 --> 00:08:20,240
y eso es todo el vídeo, muchas gracias