Alguna duda que se repite cuando se trabaja (o mejor dicho todavía se trastea...) con Microsoft Entity Framework es la posibilidad de realizar cargas diferidas de entidades en base a la navegación que sobre el E.D.M. se va realizado.
Imaginemos que tenemos una entidad Curso y otra Alumno. Supongamos que existe una relación de navegación de 1 a * entre ambas. (Relación de asociación a nivel del CSDL). La cuestión es si podemos recuperar los cursos (solo los cursos) y en base a nuestras necesidades avanzar por alumnos automatizando la carga de los mismos a través del mecanismo de carga diferidad "orquestado" de manera automática por el Entity Framework.
La respuesta es NO.
La respuesta oficial del equipo de desarrollo de ADO.net de Microsoft es que ellos bajo ninguna circunstancia permiten que el Entity Framework tome la iniciativa y acceda a la Base de Datos subyacentce sin la autorización expresa del desarrollador. (Lease esto lease paso del tema que es un patín...). De hecho esta funcionalidad ha sido desestimada (al menos de momento) por lo que no está planificada en el roadmap del producto.
Palabra de ADO.net Developer Team...
Saludos.
miércoles, 28 de mayo de 2008
martes, 27 de mayo de 2008
Entity Framework SP1 (o como no debe usted implementarse su propio O.R.M. a estas alturas...)
Con el reciente lanzamiento de la Beta del Visual Studio 2008 SP1 por parte de Microsoft me he decidido a investigar la nueva versión del Entity Framework que en el se incluye. Tengo que decir que aunque la cosa todavía esta un poco verde promete.
Se caia de maduro que Microsoft necesitaba cubrir un nicho en la que las soluciones de terceros (Hibernate, Neo, Codus...) se le habian colado en su bonito .NET Framework: Los Object Rational Mapping (ORM) y los servicios de consultas contra dichos objetos.
Microsoft ha realizado intentos, timidos pasos hacia lo que hoy es (o mejor dicho mañana será) el Entity Framework. Se probó con el DataSet, que prometia ser la revolución y se quedo por el camino, muy mal acompañado del XSD para definir modelos. Las especificaciones completas de XSD además de ser infumables, se olvidan por completo de hablar de servicios como la persistencia. Así que no es el lenguaje optimo para hablar de entidades que queremos trabajen con el ORM.
De hecho, existe una nueva especificación para definir los modelos conceptuales (CSDL), de almacenamiento (SSDL) y mapeo el E.D.M.(Entity Data Model). Dichas especificaciones cubren ambos mundos de manera muy natural (puesto que para eso ha sido creado, dicho sea de paso)
Disponer de un ORM (entre otras funcionalidades) estandar y mantenido por Microsoft es un tema a tener muy en cuenta. Yo por mi cuenta, me cree hace un par de años una implementación propia de un ORM común para mis proyectos. Pero no solo yo, es que casi todos los colegas con cierta carga de proyectos se han ido haciendo las suyas propias formando una torre de Babel de lo más poco práctica.
Y el problema no solo es hacerlo sino mantenerlo (y más rápido que Microsoft) desviando esfuerzo de la implementación de sus propias aplicaciones. Por eso es tan interesante el Entity Framework.
Por supuesto, existe la guinda del pastel en forma de LINQ to Entities que es una implementación del proveedor de LINQ para trabajar contra objetos de tipo Entidad (Definidos en el E.D.M.) e incluso una implementación de SQL llamada eSQL(subconjunto muy limitado (sin instrucciones DML para la release 1)) para atacar directamente al nuevo cliente EntityClientProvider que se coloca sobre los proveedores de todas la vida, abstrayendo de sus particularidades.
En este aspecto coincidimos todos los que "parimos" cualquier implementación mejor o peor (que de todo hay no se vayan a crerer) de ORM, en cuanto madure un poco, al trastero con las soluciones propias y a trabajar con el Entity Framework.
Como ven hay muchas cosas interesantes pero ya las iremos viendo poco a poco.
Un saludo.
Se caia de maduro que Microsoft necesitaba cubrir un nicho en la que las soluciones de terceros (Hibernate, Neo, Codus...) se le habian colado en su bonito .NET Framework: Los Object Rational Mapping (ORM) y los servicios de consultas contra dichos objetos.
Microsoft ha realizado intentos, timidos pasos hacia lo que hoy es (o mejor dicho mañana será) el Entity Framework. Se probó con el DataSet, que prometia ser la revolución y se quedo por el camino, muy mal acompañado del XSD para definir modelos. Las especificaciones completas de XSD además de ser infumables, se olvidan por completo de hablar de servicios como la persistencia. Así que no es el lenguaje optimo para hablar de entidades que queremos trabajen con el ORM.
De hecho, existe una nueva especificación para definir los modelos conceptuales (CSDL), de almacenamiento (SSDL) y mapeo el E.D.M.(Entity Data Model). Dichas especificaciones cubren ambos mundos de manera muy natural (puesto que para eso ha sido creado, dicho sea de paso)
Disponer de un ORM (entre otras funcionalidades) estandar y mantenido por Microsoft es un tema a tener muy en cuenta. Yo por mi cuenta, me cree hace un par de años una implementación propia de un ORM común para mis proyectos. Pero no solo yo, es que casi todos los colegas con cierta carga de proyectos se han ido haciendo las suyas propias formando una torre de Babel de lo más poco práctica.
Y el problema no solo es hacerlo sino mantenerlo (y más rápido que Microsoft) desviando esfuerzo de la implementación de sus propias aplicaciones. Por eso es tan interesante el Entity Framework.
Por supuesto, existe la guinda del pastel en forma de LINQ to Entities que es una implementación del proveedor de LINQ para trabajar contra objetos de tipo Entidad (Definidos en el E.D.M.) e incluso una implementación de SQL llamada eSQL(subconjunto muy limitado (sin instrucciones DML para la release 1)) para atacar directamente al nuevo cliente EntityClientProvider que se coloca sobre los proveedores de todas la vida, abstrayendo de sus particularidades.
En este aspecto coincidimos todos los que "parimos" cualquier implementación mejor o peor (que de todo hay no se vayan a crerer) de ORM, en cuanto madure un poco, al trastero con las soluciones propias y a trabajar con el Entity Framework.
Como ven hay muchas cosas interesantes pero ya las iremos viendo poco a poco.
Un saludo.
Razones para evitar la programación en cliente en Aplicaciones Web
Existen algunas razones para intentar evitar la programación en el lado del cliente:
- Aislamiento
El código del lado del cliente no puede acceder a los recursos del servidor. Por ejemplo, una aplicación que se ejecuta en el cliente no tiene una manera sencilla de leer un fichero o interactuar con una base de datos del servidor (al menos no sin caer en problemas con la seguridad y compatibilidad de navegadores) - Seguridad: Los usuarios finales pueden ver el código de cliente. (Y cuando digo pueden es SIEMPRE pueden solo varia el tiempo que tienes que invertir en poder ...) Por lo tanto un usuario malintencionado al entender como funciona la aplicación puede "trampearla" más a menudo.
lunes, 19 de mayo de 2008
En que ando metido...
Hace tiempo que no cuento nada por aqui, así que voy a comentaros en que investigaciones ando metido ...
Saludos
- Entity Framework
- WPF
- WCF
- Mock
- SCRUM
- PoliceInjection
- MVC con comandos en WPF
- JQuery
- ...
Saludos
Una pregunta para los religiosos...
Si decimos que Dios creo el universo... ¿Quien creó a Dios?
Espero sus respuestas!
Espero sus respuestas!
Suscribirse a:
Entradas (Atom)