Intento empezar, pero está va a ser para largo. Cuando diseñas tu sistema, deberías obtener una estructura de objetos, no una lista de tablas y relaciones.
O sea, tu dominio tiene clientes y facturas y pedidos, etc, que se relacionan entre ellos e interactuan, pero no necesariamente tiene una base de datos relacional donde existen tablas y registros y relaciones. Eso es sólo UNA implementación de la persistencia del dominio (voy a tratar de no irme mucho hacia el lado de DDD pero puede ser que sea inevitable). Tus clases de dominio deberían tener estado y comportamiento (properties and methods) que saben como hacer lo que deban hacer. El estado va a ser persistido en algún lugar (y no debería ser importante para el dominio). El comportamiento va a ser lo que hace que tus objetos vivan (si esto necesita más explicación podríamos seguirlo en un sentido totalmente distinto, pero no quiero irme de mambo en algo que por ahí ya compartimos). Con respecto a la persistencia, es algo que haces luego (mucho más tarde, cuando tu dominio funciona en memoria con fakes/stubs/mocks y en tus unit tests ... para nombrar nuevamente al Maestro esos test deberían estar escritos antes de escribir las clases del dominio, pero eso es otro hilo). Si tu modelo (las clases del modelo) está funcionando, entonces podes pasar a una implementación de la persistencia. Por ejemplo, si usas EF podes generar tu SQL Server database (code first enable). Por ejemplo, si tenes una relación de muchos a muchos (cosa que en objetos es completamente normal), EF va a generar 3 tablas para cambiar la relación a "uno a muchos a uno" (con una tabla relacionante) y tu modelo ni se va a enterar de esta tabla INEXISTENTE en el modelo. Por ejemplo, tenes un dominio de video-club (que viejo que soy) donde tenes peliculas que son alquiladas por clientes. Cada pelicula es alquilada por varios clientes y cada cliente alquila varias peliculas. En el dominio existe una relación de muchos a muchos. Si definis un POCO class para clientes que tiene un IEnumerable<Peliculas> y definis otro POCO class para las peliculas que tiene un IEnumerable<Clientes>, cuando ejecutas eso en EF vas a encontrar una tabla para clientes, otra para peliculas y otra para la relacion entre ellas (esto no pertenece al dominio, pertenece a la implementación de la BD y no debería importarte en el dominio). Cuando pedís un Cliente, no deberías pensar en de que tabla viene y si tenes que consultar esta y la otra tabla. Cuando pedis las peliculas de ese cliente EF va a hacer su "magia" para traerte la data que necesite. Cuando pedis una pelicula, nuevamente (dependiendo de si haces lazy loading o no) te va a traer también la lista de Clientes y nuevamente no necesitas persar en que tablas consultó. Va quedando? Me puedo explicar correctamente? SaludOZ, PS: El Maestro es Angel J. Lopez 2014-10-09 8:55 GMT+11:00 Oscar Onorato <[email protected]>: > Una consulta sobre el tema, > > Yo estoy metiéndome en lo que es E.F., pero no entiendo ¿cómo hago para > olvidarme de la BD al momento de configurar mi ORM? > ¿Y al momento de volver a modificar el ORM, poniendo por caso NHibernate? > ¿Se lo delego al Administrador de SQL Server, o del Server de RDBM del > caso? > > Juro que no entiendo, y dudo que pueda dormir... > > ¿Quién es el Maestro, trabaja en MS, en Oracle, acaso ha creado algún > Framework reutilizable para el universo del Desarrollo de Software mundial? > > Redobles hasta saber quién será ese Maestro, aunque no para entender > porqué debería olvidarme de la BD. Eso es para el caso de una Demo, no para > el caso de una BD no muy bien desarrollada que es, para el 50% de los casos > un hecho concreto. > ¿Me olvido, se lo dejo al Admin de la BD, a otra persona..? > > Desde ya muchas gracias. > > > *Oscar R. Onorato* > [email protected] > 15 - 6124 - 5067 > 4943 - 0980 > > El 8 de octubre de 2014, 18:21, Alberto Paz <[email protected]> > escribió: > >> no es una red social ... pero le daria un LIKE a este comentario de >> Zarate ! >> >> -------------------------------------------- >> El mié 8-oct-14, Oscar Zárate <[email protected]> escribió: >> >> Asunto: [puntonet] Entity Framework >> Para: [email protected] >> Fecha: miércoles, 8 de octubre de 2014, 18:01 >> >> Andres, >> Para usar EF (o cualquier otro ORM) es MUY >> importante que dejes de pensar en "data first". >> Olvidate que hay una Base de Datos (que tiene tablas y >> relaciones y registros, etc). Pensá en el arbol de >> objetos. >> Si bien lo que te dice Gonzalo es útil, vos tene >> que pensar en tu diseño de objetos/clases. >> BTW (y como diría el Maestro) cual es tu caso de >> uso? >> 2014-10-09 1:23 >> GMT+11:00 Andres Guzman <[email protected]>: >> Estimados, junto con saludarlos, quisiera >> hacerle una pregunta, cual es la forma correcta para >> configurar un modelo entity framework, para que cuando >> realize un select de cualquier tabla, solo me traiga los >> registros de esta tabla y no las tablas relacionadas a >> estas. >> >> Desde ya muchas gracias. >> Saludos >> >> -- >> Saluda ATTE. >> Andrés Guzmán Oyaneder. >> 09-9319111 >> [email protected] >> >> >> >> >> >> >
