MSDN Blogs
  • WarNov Developer Evangelist

    Programando para Office 2010 usando WPF y Visual Studio 2010

    • 2 Comments

    En este video, observaremos la manera de crear un panel para usar dentro de Word, que contendrá fragmentos de texto a los que luego de hacerles doble click podremos insertar dentro del documento a través de Visual Studio Tools for Office (VSTO)

    El panel fue diseñado usando Blend 3 y aprovechando las características de DataBound de WPF. Se aprovecha la DLL WindowsFormsIntegration para obtener un objeto de tipo ElementHost que permite agregar dentro de Windows Forms tradicional, elementos de WPF. Luego este contenedor se agrega a un UserControl y este UserControl se agrega a Office a través de un Custom Panel.

    El video explica todo el proceso y de aquí se puede descargar la solución finalizada:

     

  • WarNov Developer Evangelist

    Entity Framework vs. LINQ como ORM

    • 6 Comments

    LINQ inició siendo una teconología que servía tanto para consultar objetos en memoria, como para mapear tablas de bases de datos SQL a objetos de memoria. Así que luego de hacer el mapeo, con nuestro mismo lenguaje de programación sin necesidad de escribir comandos SQL a través de LINQ tendríamos la posibilidad de hacer consultas y manipulaciones sobre estas entidades en memoria sin mucho problema.

    Visto esto, observamos que con LINQ tenemos dos alcances: Como lenguaje de consultas integrado y como ORM.

    LINQ fue primero que EntityFramework; al principio LINQ "quizo" ser el ORM de Microsoft, pero demostró algunas deficiencias en ciertos aspectos como la conexión a distintos repositorios. Luego vino el EntityFramework a mejorar esas cosas en las que LINQ tenía debilidades. Pero OJO! EntityFramework solo se ocupa de las operaciones de un ORM. Y el hecho de que haya aparecido, no significa la desaparición de LINQ, dado que LINQ aparte de tener esas caractarísticas de ORM, es un potente lenguaje de consultas integrado que permite consultar tanto entidades (como las arrojadas por EntityFramework, el mismo LINQ o cualquier otro ORM), como objetos personalizados, XML, ActiveDirectory y en general cualquier estructura de datos .NET en memoria que implementen IQueryable (http://msdn.microsoft.com/en-us/library/bb546158.aspx)


    En últimas, yo recomendaría usar EntityFramework para hacer ORM y luego usar LINQ para ejecutar consultas muy sencillamente sobre las entidades generadas por el ORM. (Y sobre cualquier otra colección de datos).

  • WarNov Developer Evangelist

    Entornos Laborales Virtuales Microsoft para Emprendedores

    • 0 Comments

    Tengo un gran amigo. Emprendedor y entusiasta de las tecnologías Microsoft. Se ha independizado y gran parte de su operación se ha beneficiado de todos los recursos que hoy en día tiene Microsoft que son gratis o de muy bajo costo. Empezando con BizSpark (todo el software por 3 años y 100 dólares no más), herramientas de virtualización gratuitas como Virtual PC, etc.

    En este post, de su nuevo blog:
    http://rickersilva.wordpress.com/2010/01/25/virtual-office,
    nos enseña como logró establecer su empresa sin oficinas y usando todas estas herramientas.

  • WarNov Developer Evangelist

    Curso Gratuito de XNA en Colombia

    • 0 Comments

    Microsoft Colombia te reta a aplicar tu imaginación, pasión y creatividad en innovaciones de tecnología que puedan hacer una diferencia en el mundo. Participa en Imagine Cup 2010.

    El Diseño de juegos es en dónde el arte y la ciencia se unen. A través de Imagine Cup, puedes aprender y avanzar hacia una carrera cómo desarrollador o empresario de juegos. Únete hasta con 3 amigos y construye una experiencia de juego completa, usando XNA Game Studio 3.0 o posterior, Visual Studio o Silverlight.

    ¿Quieres aprender XNA Game Studio y participar en Imagine Cup 2010?

    1. Aquí encuentras toda la información sobre la competencia. No olvides revisar con detenimiento las reglas.

    2. Regístrate en Imagine Cup 2010 y escoge la categoría de Diseño de Juegos.

    3. Envíanos a más tardar el 30 de enero el usuario con el cual te inscribiste, a acadcol@microsoft.com.

    4. El próximo 5 y 6 de Febrero podrás asistir sin ningún costo, al curso de XNA Game Studio dictado por especialistas en Desarrollo de Juegos con la plataforma XNA, que hacen parte de la más activa comunidad de desarrollo de Bogotá: BogotaDotNet (http://bogotadotnet.org/). Este curso lo estaremos dictando para los estudiantes que se hayan registrado en la competencia. El curso será presencial en Bogotá (cupos limitados) y se transmitirá vía Live Meeting. No importa en cuál ciudad del país estés, puedes participar.

    5. El día del curso te daremos acceso gratuito al software que requieres para desarrollar tu juego.

    6. Busca inspiración para tu proyecto en los Objetivos de Desarrollo del Milenio de las Naciones Unidas y empieza a crear tu producto. La primera ronda del concurso se cierra el 15 de Marzo de 2010.

    La tecnología es la fuerza más poderosa para transformar las ideas brillantes en soluciones reales y sabemos que eres talentoso en programación de software, desarrollo de hardware, diseño, pero sobre todo, que eres visionario.

    Apuéstale a representar al país en la final mundial de la competencia, que será en Polonia.

    ¡Te esperamos!

    Esta iniciativa es válida para Estudiantes mayores de 16 años, que residan en cualquier ciudad de Colombia.

  • WarNov Developer Evangelist

    Open Data Protocol (OData)

    • 2 Comments

    Si como desarrolladores alguna vez hemos tenido la necesidad de exponer los datos de nuestra aplicación a otras aplicaciones; o lo que es peor, usar datos de otras aplicaciones, deberíamos saber que éstas actividades de compartimiento de información son de las más complicadas en el proceso de desarrollo.

    Es cierto que hoy en día existen los gloriosos Web Services: montados sobre los más aceptados protocolos y estándares: TCP/IP, HTTP, SOAP, XML, XSD, WSDL…

    Pero a pesar de ello, la comunicación sigue siendo complicada. Sobre todo para aquellos que tienen que crear proxies manualmente (Afortunadamente el SDK del Framework.NET ayuda a alivianar estas tareas con herramientas como wsdl.exe y xsd.exe que se integran transparentemente con Visual Studio). Casos por ejemplo en que un cliente java requiere acceder a un Web Service creado con .NET. y viceversa, requieren de mucha mano de obra y configuración por parte del cliente. Y ni se hable cuando de WCF se trata! Es bien sabido que WCF da toda la flexibilidad que requerimos para acceder a cualquier fuente de datos, montados sobre cualquier protocolo de transmisión y con cualquier tipo de mensaje; pero configurar un WCF sin mucha experiencia, puede resultar ciertamente más dispendioso que crear las operaciones en sí.

    Dado que la mayoría de aplicaciones necesitan acceder a los datos a través de HTTP, es justo entonces que se defina un protocolo simplificado que aproveche todas las ventajas de HTTP y que permita a múltiples clientes (esto es: clientes creados con distintas tecnologías) acceder a múltiples fuentes de datos, todo usando el mismo mecanismo.

    El camino ya había estado bastante trabajado con arquitecturas como REST, protocolos como ATOM y lenguajes como JSON.

    Teniendo todas estas bases y las necesidades que ya he descrito, Microsoft decidió crear OData; un protocolo para la consulta y actualización de una variedad de fuentes de datos que incluye pero no se limita a bases de datos relacionales, sistemas de archivos, CMS y sitios web tradicionales.

    OData fue liberado bajo la promesa Open Specification Promise (OSP) para permitir a cualquier persona interoperar libremente con cualquier implementación OData. A futuro, se espera que OData empiece a ser parte de AtomPub.

    Como lo mencioné OData ha sido creado específicamente para trabajar sobre web y es un protocolo centrado en HTTP. Usa las URIs para identificar los recursos con los que se desea trabajar. Los resultados, aunque se pueden trabajar con el formato AtomPub basado en XML, también se pueden trabajan con JSON, para simplificar la integración con clientes HTML y JavaScript.

    Para trabajar con OData hoy en día se ofrecen toolkits gratuitos para .NET (WCF Data Services), JAVA, AJAX y PHP y se aplica no solo en sitios web personalizados, sino en productos como SharePoint, Excel (PowerPivot), SQL Server, Windows Azure Storage, WebSphere eXtreme Scale, etc.

    Más información, en la página oficial del protocolo: http://www.odata.org. Allí encontraremos links de la especificación FORMAL del protocolo. Pero como toda especificación FORMAL, para nosotros desarrolladores que necesitamos agilidad, es poco práctica. De hecho la practicidad que tiene este protocolo para nosotros, es en el uso de WCF Data Services y es por eso, que he dedicado mi próximo post a ese tema. Pero para entenderlo mejor, es necesario comprender que existe OData y que está basado en REST.

  • WarNov Developer Evangelist

    REST (Representational State Transfer)

    • 2 Comments
    Creado en el 2000 hace referencia a “Representational State Transfer” o transferencia representacional de estados.

    Si uno se deja guiar por el nombre pareciera como si no tuviese nada que ver con lo que medio se ha oído por ahí acerca del tema: “que sirve para acceder a servicios sencillamente a través de URLs”, por ejemplo.

    Pero estudiándolo bien uno nota que al final si hay cierta congruencia.

    En REST participan básicamente dos roles. Un cliente y un servidor. El cliente es el sujeto de los dichosos cambios de estados. Entonces imagine el cliente como su navegador web en un estado específico (una página web). Un cambio de estado obviamente significa la transferencia a otra página web.
     
    Una transferencia representacional en web, no es más que la transferencia lograda sencillamente a través de URLs. Y es precisamente allí donde se encadena todo.

    La idea es que las acciones o verbos que originan los cambios de estado del cliente en REST están completamente definidos. Es decir, REST propone un vocabulario de acciones fijo; que permite obtener recursos del servidor, que una vez interpretados por el cliente, hacen que este cambie de estado.

    Esto último es lo que más diferencia a REST por ejemplo del tradicional SOAP. Ya que en SOAP, se le dice a cada desarrollador que defina un vocabulario nuevo y arbitrario de verbos, de acuerdo a los requerimientos de la aplicación (obtenerUsuarios(), almacenarOrden(…), etc. Todos sobreusando el verbo POST de HTTP). Paradójicamente, esto que siempre se vio como una gran ventaja, va en contravía con muchos de los aspectos inherentes del HTTP que es base de SOAP. Así que aspectos como la autenticación, caching, negociación de contenidos y demás, no se aprovechan.

    Aunque hasta aquí todo lo ejemplifiqué usando HTTP, REST es un mecanismo que no depende de ese protocolo. Las aplicaciones REST pueden basarse en otros protocolos, siempre y cuando éstas provean un vocabulario uniforme preestablecido para las aplicaciones que se construirán sobre ella. Recordemos que la idea principal de REST es maximizar el uso de las capacidades predefinidas de la plataforma que los soporte. HTTP como tal, proporciona un rico vocabulario completamente establecido y estandarizado que se ajusta perfectamente a este objetivo. Es por esto, que hoy en día al hablar de REST uno automáticamente piensa en su implementación sobre HTTP.

    Principios

    REST se fundamenta en seis principios básicos:
    • Cliente y Servidor plenamente identificados y separados
    • No hay almacenamiento de estado en las transiciones (Stateless)
    • Respuestas “cacheables” (Para mejorar las interacciones y el performance)
    • Capas: Pueden haber varias capas de servidores intermedios
    • Código por demanda: La funcionalidad de un cliente se puede extender con código trasmitido por el servidor (por ejemplo con JavaScript). Este es el único requerimiento opcional.
    • Interfaz uniforme: La misma que se discutió anteriormente.

    Objetivos

    Los principios anteriormente mencionados, están diseñados para lograr los siguientes objetivos:
    • Escalabilidad de componentes
    • Generalidad de Interfaces
    • Distribución Independiente de componentes
    • Existencia de componentes intermediaros que reducen latencia, aumentan la seguridad y encapsulan sistemas de legado.

    Recursos

    Los recursos se definen como fuentes de información específica y son muy importantes en REST. Un cliente accede a los recursos que el servidor dispone. Imagine una aplicación empresarial con información de recursos humanos. En este caso, la lista de empleados es un recurso del servidor y para acceder a ellos, se requiere un identificador único (por ejemplo una URI), que es usado por el cliente para referenciarlo y una interfaz de comunicación estandarizada (por ejemplo HTTP). Obviamente, aparte de tener claro el objeto de una acción, se debe tener clara la acción a ejecutar sobre ese objeto. Así pues, una aplicación interactúa con los recursos sabiendo su identificador único y la acción a ejecutar sobre este. Por ejemplo: Recurso: Empleado con Id:3520. Acción: Borrar. Los recursos generalmente son transmitidos entre el servidor y el cliente usando formatos como HTML, XML o JSON. No obstante, los recursos también pueden ser imágenes, texto plano o cualquier otro formato.

    Servicios Web REST

    No son más que servicios WEB implementados usando HTTP y los principios de REST que comprenden una colección de recursos de acuerdo a los siguientes aspectos:

    • Una URI base para el nombre del servicio: http://example.com/miservicio/
    • El tipo MIME de los datos soportados por el servicio
    • El conjunto de operaciones soportadas.
    • En REST sobre HTTP, lo más normal es tener estas operaciones
      • POST: Crea nuevos recursos. Como retorno, se ofrece el ID automáticamente creado
      • GET: Lista un recurso
      • PUT: Reemplaza un recurso con otro (Útil para el update)
      • DELETE: Elimina un recurso

    Entonces por ejemplo si se quisiera eliminar el empleado con ID 3520 se haría un request con DELETE a la siguiente URL desde el cliente:/span>
    http://example.com/miservicio/empleados/3520

    Conclusión

    REST, que es una arquitectura y no un protocolo como SOAP, se basa en acciones sobre recursos, para permitir la interacción de un cliente con un servidor. La implementación sobre HTTP es la más común y ha permitido la creación de otras tecnologías. Por ejemplo Microsoft, que se ha basado en este tipo de implementación REST para generar el estándar OData (Open Data) sobre el cual se construyó WCF Data Services (antes conocido como ADO.NET Data Services), y que permite simplificar el acceso interoperable a las capas de datos en aplicaciones n-tier.



Page 1 of 1 (6 items)