Miguel Matas Blog

Ingeniería y Arquitectura de Software, Proyectos IT, Programación, Personas, Problemas, Mejora Continua, la vida.

Archive for the 'Arquitectura' Category

Vuelven las aplicaciones de escritorio?

Hola,

Desde hace ya una temporada se viene notando, no tengo una estadística si no un poco la experiencia del día a día, y cada vez con más indicios que es así, ¿están volviendo las aplicaciones de escritorio?

Veamos:

* Clientes que su método habitual es trabajar siempre con aplicaciones de escritorio y solo crean aplicación web si se ha preparado una completa justificación al respecto

* Nuevas aplicaciones, para las que a la hora de tomar la decisión si se realizan en escritorio o en web, el cliente ha evaluado internamente que lo mejor es hacerla en escritorio, o ahora sí está escuchando a los arquitectos de software que, en base a los requerimientos funcionales y técnicos identificados, recomiendan dicha solución frente a una solución web

* Propuestas que recibimos sobre mantenimientos de aplicaciones de escritorio

* Propuestas que recibimos sobre migraciones de aplicaciones de escritorio hechas en VB6 y que se solicita migrar a una tecnología de escritorio Microsoft más moderna como WPF.

* Personas con las que estoy compartiendo entrevista técnica para nuevas incorporaciones, y que en su experiencia profesional, algunas de menos de 3 años, predomina el trabajo en aplicación de escritorio

En fin, parece, y digo parece ya que como comentaba al principio no tengo ninguna estadística oficial, que lo de la moda de la web se está pasando y ha vuelto el sentido común; a base de muchas tortas me temo. El martillo se está volviendo a utilizar para los clavos y el destornillador para los tornillos.

Enhorabuena a todos los desarrolladores de software, se acabaron un porcentaje importante de “misiones imposibles”.

Pero no bajéis la guardia, porque a la vuelta de la esquina podéis encontraros el próximo reto 🙂

Finalmente, cuidado, no dejéis de formaros en web, tener una visión y experiencia compartida en ambos entornos es muy atractivo de cara a presentaros a una candidatura para un puesto de trabajo.

Abrazos!

Miguel.

No comments

Recordatorio para desarrollos con requerimientos ligados al rendimiento

Hola,

No olvidar: en todo proyecto donde existan requerimientos técnicos ligados a los tiempos de respuesta, incluir en el contrato que desde el día 1 se contará con el juego de datos que se utilizará como banco de pruebas para realizar dichas pruebas, y que en caso de que dicho juego de pruebas varíe en tipología o tamaño, debe revisarse convenientemente por ambas partes.

Gracias.

Un saludo.

No comments

Separación de capas y despliegues

Hola,

Otra frase lapidaria en cuanto al uso de capas.

“la separación de capas ayuda en el despliegue de un sistema distribuido, permitiendo que diferentes capas sean situadas de forma flexible en diferentes servidores o clientes, de manera que se minimice el exceso de comunicación y se mejore el rendimiento (Cita de M. Fowler).”

Pasaje de: Architecture, Microsoft. “Guí­a de Arquitectura N-Capas Orientada al Dominio con .NET 4.0.” Krasis Press, 2010-11-29T23:00:00+00:00.

Un saludo.

Miguel.

No comments

Una caché para andar por casa mediante static

Hola,

Seguimos adelante con el conjunto de artí­culos destinados al Especial Capa de Caché, para abordar una sencilla forma de cachear datos en memoria, una fórmula de andar por casa, mediante el uso variables de tipo static.

Una variable de tipo static cumple dos de las principales premisas necesarias para crear una capa de caché, en primer lugar es visible para toda la aplicación, en segundo lugar su contenido se almacena en memoria. Adicionalmente, cuenta con otras ventajas a nivel de programación, como es permitir almacenar objetos de cualquier tipo, incluso los no serializables.

Por tanto, ante la pregunta, ¿podrí­a utilizar como sistema de caché de andar por casa un conjunto de variables static que me permitieran resolver mi problema? La respuesta podrí­a ser, sí­, por qué no, si el problema a abordar no requiera por ejemplo:

* Polí­ticas avanzadas de refresco de caché

* El conjunto de datos a almacenar no va a ser muy grande por lo que no hay peligro de colapsar la memoria del servidor

* Compartir la información de caché entre diferentes aplicaciones

Eso sí­, como consejo, y con tal de mejorar la escalabilidad del sistema, encapsularí­a el acceso a nuestra caché basada en statics con tal de que el sistema no conozca la implementación interna de la misma. Con este tipo de implementación y en caso de necesitar a futuro contar con un sistema más potente, simplemente necesitarí­amos reimplementar el sistema de caché sin afectar al resto del sistema.

Un saludo.

Miguel.

No comments

Objetivo de la arquitectura Domain Driven Design

Hola,

Marco entre comillas el pasaje y en negrita el punto que considero más importante, sobre todo para los que estamos acostumbrados a trabajar con arquitecturas SOA.

Pasaje de: Architecture, Microsoft. “Guí­a de Arquitectura N-Capas Orientada al Dominio con .NET 4.0.” Krasis Press, 2010-11-29T23:00:00+00:00.

“El objetivo de una arquitectura basada en Domain Driven Design es conseguir un modelo orientado a objetos que refleje el conocimiento de un dominio dado y que sea completamente independiente de cualquier concepto de comunicación, ya sea con elementos de infraestructura como de interfaz gráfica, etc.

Buscamos construir un modelo a través del cual podamos resolver problemas expresados como la colaboración de un conjunto de objetos.”

Un saludo.

Miguel.

No comments

Capas y pruebas unitarias

“Para asegurar estabilidad y calidad, cada capa debe contener sus propias pruebas unitarias”

Pasaje de: Architecture, Microsoft. “Guí­a de Arquitectura N-Capas Orientada al Dominio con .NET 4.0.” Krasis Press, 2010-11-29T23:00:00+00:00.

No comments

Parte I. Ubicación y relaciones de la capa de caché dentro de una arquitectura n-capas

Hola,

Y tras la introducción realizada en el capí­tulo anterior, vamos a estudiar en primera instancia dónde podemos ubicar la capa de caché y con qué relaciones puede contar.

Como siempre, los ejemplos están basados en la experiencia, no queriendo esto decir que sean las íºnicas soluciones, si no que son varios ejemplos válidos, de comíºn uso, y que podrí­an serviros en un momento dado. Los muestro como ejemplo didáctico, pero esto no quiere decir que sean la íºnica solución.

Ejemplo. Capa de caché distribuida y en cliente, siendo responsabilidad en el primer caso de la capa de negocio alimentarla de datos

A continuación un diagrama UML de componentes que da a entender el escenario y remarcando por mi parte que esta es la solución que suelo usar y con la que más veces me he encontrado.

Miguel Matas Blog - Ejemplo 1 de ubicación de capa de caché

Podremos observar 4 nodos diferentes, que representan 4 sistemas fí­sicos: un servidor de presentación, uno de negocio, uno de persistencia y una aplicación de escritorio. He resaltado en dos de los sistemas fí­sicos la utilización de 2 cachés diferentes.

En el sistema fí­sico de negocio vemos que la capa de caché es accedida por la capa de negocio (en los casos que esta lo considere, es decir, en los casos en los que el negocio sabe que dicho dato está cacheado). La capa de caché puede retornar la información ya cacheada a la capa de negocio, evitando que esta pida la información al acceso a datos, lo que forzarí­a a consultar la base de datos. En el caso de que la capa de caché no disponga de la información cacheada, será ella la que conectará con la capa de acceso a datos para obtener la información y cachearla, consiguiendo así­ que en la siguiente consulta de la capa de negocio ya no sea necesario pasar por la base de datos (a no ser que se haya reciclado la caché, claro).

Por otro lado podemos ver que en el modo que representa la aplicación de escritorio tenemos una caché local, la cual almacena ciertos datos, para evitar así­ llamadas al servidor de negocio.

A resaltar además el hecho de que la capa de caché de negocio está situado en el mismo nodo fí­sico que el resto de capas del nodo; esto es algo que veremos más adelante que puede cambiar en el momento en el que distribuyamos la caché (donde aparecerá un nuevo nodo fí­sico participante).

Un saludo.

Miguel.

No comments

Beneficios de una arquitectura en n-niveles

Hola,

Hablamos muchas veces de arquitecturas n-capas, aunque muchas menos veces se trata el tema de los n-niveles.

Los n-niveles es un concepto que seguro que habéis usado, aunque no le hayáis etiquetado con este nombre.

Los niveles (tiers en inglés), identifican capas fí­sicas diferenciadas; como ejemplo, diferentes servidores.

En una arquitectura tí­pica en n-capas podemos mantener todas las capas en la misma aplicación o en diferentes aplicaciones pero corriendo en el mismo servidor; acabamos de ver un ejemplo de n-capas y 1-nivel.

Por otro lado, podrí­amos tener una aplicación asp.net corriendo en una máquina concreta, estando al mismo tiempo una aplicación Windows Communication Foundation corriendo en otro servidor y conteniendo ésta toda la lógica de negocio, caché y acceso a datos. Por íºltimo, la base de datos y los procedimientos almacenados en una tercera máquina. Este serí­a un ejemplo de arquitectura en n-capas y 3-niveles.

A continuación os dejo un UML de componentes que describe este íºltimo ejemplo.

Miguel Matas Blog - Beneficios de una arquitectura en n-niveles
Y ya una vez situados todos, las ventajas de usar una arquitectura en n-niveles:

* Separación de responsabilidades fí­sicas: puede dimensionarse cada servidor adaptándolo a las exigencias de las capas que en él se despliegan.

* Separación de la carga de trabajo: seguramente la BBDD tirará más de disco duro que el servidor de negocio que tirará más memoria; al estar en máquinas separadas los procesos que ocurran en una o en otra no afectarán al rendimiento global.

* Tolerancia a fallos: al tratarse de diferentes máquinas, si se cae una no se cae todo el sistema (aunque si sólo tienes una aplicación corriendo y necesita de todas las partes, de poco te va a servir)

* Escalabilidad: es posible añadir más de una máquina por nivel y poder permitir así­ un mayor rendimiento global. Por otro lado este punto mejorarí­a también la tolerancia a fallos.

Un saludo.

Miguel.

No comments

Migrando de ASP.NET WebForms a ASP.NET MVC

Hola,

Recientemente tuve que investigar este tema y localicé un artí­culo de introducción muy interesante para ponerse en situación.

http://developerart.com/publications/8/migration-from-asp-net-webforms-to-asp-net-mvc

Tened en cuenta de todas maneras que es un artí­culo antiguo, comprando de la versión 1 de ASP.NET MVC, por lo que seguro que alguno de los temas que se tratan seguro que han mejorado para la actual versión 4. A expensas de ello, me resulta interesante como punto de partida.

Un saludo.

Miguel.

No comments

Clases estáticas o singleton

Hola,

Recupero un artí­culo ya de hace unos años, pero que da respuesta aíºn a dí­a de hoy estupendamente al respecto de qué aporta el uso del patrón singleton respecto al uso de clases estáticas.

http://geeks.ms/blogs/gelexgaray/archiven/2007/02/01/clase-singleton-vs-est_E100_tica.aspx

Un saludo.

Miguel.

No comments

Next Page »