jcamweb's blog

En las entradas umbraco 4.7 y umbraco 4.6 se comentaron las sucesivas puestas al día del cms favorito de este autor. Además de la correspondientes soluciones a bugs de cada una de estas actualizaciones, también se anunciaba ya la más que probable migración a un patrón mvc de umbraco. Esto se ha confirmado en esta primera versión beta junto a otras mejoras en las instalación y configuración. Umbraco jupiter, que así se llama esta rama de evolución, está totalmente basada en el patrón mvc pero por el lado negativo no permitirá una actualización sencilla desde versiones 4. En caso de querer migrar desde una versión anterior deberemos usar una versión especial de la  herramienta de implementación de umbraco, courier, que nos permitirá migrar contenido y media de una versión anterior a la 5.

En cuanto al proceso de instalación tanto en local como servidor de hospedaje final, el proceso es más sencillo y el número de pasos es menor. Aunque ahora hay que tener instalado mvc3, pero los requisitos de base de datos son más flexibles ya que podemos elegir sqlce4 que viene incluída en el paquete, lo mejor es que podemos olvidarnos de los permisos sobre los directorios de instalación que más de un quebradero de cabeza han dado a la hora de hospedarlo. Pero lo mejor es entrar en umbraco codeplex conseguir el instalable y probarlo.

En anteriores entradas ya se ha comentado tanto sobre servicios web, arquitectura soap, wcf y wcf rest services. Por un lado se ha destacado por qué puede interesarnos una arquitectura orientada a servicios, como empezar a desarrollar servicios web en el entorno .net y el más generalizado modo de desarrollo empleando wcf.
Sin embargo una vez que entras en el desarrollo, más allá de los ejemplos académicos, los requisitos que demanda la aplicación son más exigentes. Se te puede plantear que el web service sea accesible desde varias tecnologías, aprovechar al máximo el entorno .net para descargar los recursos necesarios para correr los servicios, validación de datos y feedback para los diferentes clientes que hacen uso del web service. En esta entrada se comentan algunos de estos puntos siguiendo el caso desarrollado en el que se hacía necesario que el web service fuera compatible para múltiples entornos. Leer más…

Al igual que en entornos Linux hay paneles de control de hosting, open source, de características y funcionalidades equivalentes a los comerciales, vhcs, ZPanel, para entorno windows tenemos un panel de control que nada desmerece de las soluciones que se ofrecen comercialmente. Hablamos de WebsitePanel también conocido como dotnetpanel. En esta entrada no se va a comentar nada en particular sobre la instalación, requisitos del sistema o donde conseguirlo, sino se describirán algunas características de este panel, posibilidad de multisitio, facilidad de gestión de dominios y programación de tareas, que particularmente a mi me han resultado interesantes. Leer más…

En las entradas web service o wcf y web service o wcf parte ii comentamos la arquitectura soa, la base para construir aplicaciones para esta arquitectura, web service/wcf,  y que una de las ventajas de desarrollar en los estándares Soap/wsdl es la multitud de herramientas y fabricantes que lo han adoptado y por tanto facilitan el desarrollar con ellos.  Pero no siempre que queramos desarrollar servicios en la web tenemos por que seguir el estándar Soap/wsdl, de hecho esta manera de hacerlo está menos ligada a como funciona internet, si seguimos como en el protocolo http que no mantenga estado, identificado únicamente por la Uri, funcionalidad expuesta por http get, post, put, delete y que sea cacheable estaremos hablando de un Rest web service. En esta entrada veremos cómo programar un web service que siga estos requisitos, en concreto con Wcf .net 4. Leer más…

Cualquier aplicación que se precie debe a la hora de la planificación dedicar tiempo a su arquitectura. Aquí deberemos de tener en cuenta los patrones de diseño que más convengan a nuestro futuro sistema, así como tengamos más conocimiento y experiencia con él. En esta entrada escribiremos sobre la data access layer y en concreto sobre dos posibilidades para construir el acceso a datos. Por un lado usar daab, la librería de Microsoft de acceso a datos optimizada y que permite ahorrarnos lineas de código, y por el otro un orm, no de los más conocidos pero con sencilla implementación, subsonic. Para ambos compararemos su configuración y ejemplo de código para generar consultas, así tener idea del tiempo y número de lineas necesarias para su uso. Empezamos con daab. Leer más…