Cambios de EF en la beta del SP1 VS2008

De primeras, seguro que hay muchos que aún no he visto y que tengo ganas de probar, pero de entrada hay unos cuantos que se ven muy claros:




  • Nuevo diseñador, algo más ligero que el anterior y más funcional


  • Por defecto los ficheros de Store, Conceptual y mapeo están embebidos en el ensamblado y no como output


  • ConcurrencyMode accesible y “funcional” desde el diseñador


  • Los marcadores Setter y Getter de las propiedades accesibles y modificables desde el diseñador


  • Nuevos elementos al menú contextual del Model Browser


  • La ventana de actualización del modelo es nueva, aunque le queda mucho para ser realmente funcional, sigue fallando en diversos toques para actualizar los cambios producidos en la base de datos, refrescar el modelo con una jerarquía terminada y alguna que otra, esta es una parte que está bastante floja…


  • Seguimos sin tener la posiblidad de hacer tipos complejos desde el diseñador, y algo que me mosqueo es que tampoco fuí capaz de hacerlo ‘a pelo’ ( aunque tampoco le dediqué demasiado tiempo, todo sea dicho de paso.


  • En cuanto al código el ObjectContext dispone de un nuevo método denominado CreateEntityKey mediante el cual podremos crear EntityKey pasando el nombre del EntitySet y el objeto al que le deseemos agregar este elemento.


  • La última, puede que sea una de las más importantes para la construcción de aplicaciones distribuídas y tiene que ver con la serialización de EntityCollection y EntityReferences, algo que tiene que ver con un post puesto hace algún tiempo con respecto a la serialización de grafos.

Seguro que me estoy olvidando de más, pero tal y como he comentado en cuanto vea más cosas interesantes las iré publicando…


 


Saludos


Unai Zorrilla


 

12 comentarios sobre “Cambios de EF en la beta del SP1 VS2008”

  1. Hola Unani. Cuando te refieres a “Por defecto los ficheros de Store, Conceptual y mapeo están embebidos en el ensamblado y no como output” entiendo en que podrás elegir el ensamblado de destino no?
    Saludos!

  2. Hola Carlos, dentro de un mismo proyecto se agregan los tres ficheros de los metadatos que indica Unai.

    Cuando distribuimos una aplicación con Entity Framework, se genera el ensamblado donde estaban los tres ficheros de los metadatos y los ficheros de metadatos aparte que debían ser distribuidos todos juntos. Para agregarlo como recursos, debíamos incrustarlos y acceder a ellos a través de res:// en el app.config de turno. Eso quiere decir, que los metadatos estarán embebidos por defecto dentro del único ensamblado que se generará, el del propio proyecto, por lo que salvo que me equivoque, no se podrá elegir otro ensamblado diferente, sino solo el del mismo proyecto donde se crean los archivos de metadatos.

    Espero haberme explicado y no haber dicho ninguna burrada porque aún me queda probarlo al 100%.

  3. Si, porqué no, de hecho es lo único que estás haciendo en gran parte, si lo tomas como una arquitectura n-capas tradicional. Tu capa de acceso a datos puede usar el modelo creado en este ensamblado, aunque a mayores tienes el contexto de trabajo. Lo que si es cierto es que la llegada de EF cambiar puede hacer cambiar la forma de ver tu arquitectura y librarte de otras capas que con esta vista podrían parecer innecesarias. Se que Rodrigo está deseando hablar de esto después de muchas de nuestras conversaciones…

    Saludos
    Unai

  4. En mi empresa estamos pensando en desarrollar con EF, en nuestra anterior arquitectura manteniamos una referencia desde la capa UI a la capa de datos para poder hacer uso de las entidades generadas por el ORM, pero veo q con EF o Linq to sql no permite generar el modelo conceptual en otro proyecto, tendriamos q mantener la referencia entre proyectos igualmente(UI-DB).
    La unica manera q encuentro es generar las entidades manualmente y insertar los atributos….
    Bueno chicos gracias por todo 🙂

  5. Carlos, respecto del comentario que hiciste al final (La unica manera q encuentro es generar las entidades manualmente y insertar los atributos….) creo que puede servirte Data Services… echale un ojo a eso.
    Saludos

  6. En realiad tu UI nunca debería conocer a tu capa de datos, nunca nunca.. piensa que lo único que deberías exponer son contratos de datos, si estamos hablando de WCF, en este caso los contratos serían entidades de EF, pero una vez fuera del servicio son solo contratos y no necesitas tener referencias a tu capa de acceso a datos solamente al proxy generado…

  7. Bueno, me olvide comentar que en realidad nadie impide generar las entidades en cualquier ensamblado usando EdmxDeploy.exe, pero sigues en la misma, no entiendo que te podría aportar pensándolo un poco, a lo menos que estés buscando tener el contexto por un lado y las entidades por otro, cosa que no puedes hacer de una forma sencilla claro

  8. Eso es, mi objetivo es separar las entidades del contexto en otro proyecto para poder referenciar este, en todas las capas, asi eliminamos la referencia.
    Haciendo uso de WCF, evitariamos ese problema como bien dices, pero no exponemos el BL como servicio.
    Muchas gracias machines! Miraré la herramienta EdmxDeploy.exe.
    🙂

  9. No es imposible, es
    factible, pero complicado para la vida del desarrollo ( tienes que andar fuera de VS para ir haciendo cosas ) si lo haces con EF. Sobre todo por la nueva forma de exponer y de pensar en un arquitectura tradicional.. si rodrigo no pone el post pronto lo clavo yo 🙂

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *