09.18.11
Posted in Arquitectura, Metodologías at 5:21 pm by Miguel
A continuación, basado en su uso y experiencia, traslado la metodología que mejor resultado viene dando en la transmisión de conceptos de arquitectura y desarrollo de software a perfiles de profesionales recién licenciados sin experiencia, con experiencia leve, o experiencia focalizada en desarrollos específicos web, escritorio o dispositivos móviles.
Puntualizar que la experiencia ha sido siempre lanzada utilizando como base tecnología Microsoft.NET, la cual dispone de herramientas que dan cobertura completa a los conceptos de arquitectura a trasladar, pero esto no quiere decir que este método no pueda ser aplicado utilizando otras tecnologías de cobertura completa (Java por ejemplo) o incluso en combinación de varias (bajo mi punto de vista sería el objetivo a cumplir tras la primera fase del “curso” que hoy os vamos a trasladar).
Objetivos
En el momento de finalizar el curso el alumno debe haber asentado su conocimiento sobre los siguientes conceptos
1) Entorno de desarrollo tipo
2) Desarrollo de arquitecturas orientadas a n-capas
3) Desarrollo de aplicaciones SOA
4) Buenas y malas prácticas de programación
5) Diferencias fundamentales en el desarrollo de aplicaciones web y escritorio
6) Trabajo colaborativo y en equipo
7) Importancia de las pruebas en el proceso de desarrollo
Despliegue de aplicaciones en entornos no accesibles
9) Dinámica de proyecto
Mientras que los objetivos del instructor son
1) Adaptar la formación a un escenario tipo de proyecto, el alumno desde el primer día debe entrar en la dinámica del día a día de un proyecto real
2) Identificar áreas de mejora de los alumnos, tanto técnicas como no técnicas
3) Identificar puntos fuertes y puntos de mejora del alumno
4) Identificar puntos de mejora del propio método de formación
Requerimientos Previos
Referidos a los alumnos (en orden de importancia):
1) Programación orientada a objetos
2) Definición de modelos entidad-relación
3) HTML básico
La falta de conocimiento de alguno de estos puntos, requerirá que el instructor incorpore a la formación módulos adicionales que cubran la visión necesaria al respecto.
Otros valores deseables ajenos a las capacidades técnicas
1) Pro actividad
2) Eficacia
3) Eficiencia
4) Trabajo en equipo
5) Liderazgo
6) Confianza
7) Capacidad de trabajo
Nivel de interlocución
Es labor del instructor identificar puntos de mejora también en estos aspectos, potenciándolos durante el proceso formativo. No solo estamos formando a nivel técnico, también estamos formando profesionales que van a ser parte fundamental de proyectos de desarrollo que requerirán de aptitudes no solo técnicas para lograr el éxito del proyecto.
Referidos al instructor:
1) Profesional consolidado en conocimientos de arquitectura y en la tecnología/tecnologías de desarrollo que se desarrollan en el curso.
2) Experiencia de trabajo en proyectos, habiendo participado/liderado procesos de captura de requerimientos, definición de arquitecturas y procesos de implantación/despliegue, gestión de equipos, diseños funcionales, diseños técnicos, supervisión del trabajo de otros programadores y construcción.
3) Nivel de interlocución medio-alto
4) Experiencia en sesiones formativas
En resumen y por poner un símil en consultoría, las habilidades esperadas de un Jefe de Equipo.
Bases Fundamentales de la Metodología
* Dinámica de proyecto desde el primer día
* Curso eminentemente práctico
* Grupos de formación pequeños (entre 5 y 10 alumnos máximo por instructor)
* No solo centrarse en las habilidades técnicas
* Que el alumno de el primer paso: resolver el problema de forma completa con el conocimiento actual del alumno, a medida que se vayan incorporando conceptos nuevos (a posteriori) el alumno deberá resolver de forma completa el problema adaptando su solución e incorporando los nuevos conceptos adquiridos.
* El instructor no es el protagonista
Capítulo I: Definiendo requerimientos
Todo proyecto comienza a partir de un conjunto de requerimientos, por lo que si uno de nuestros principales objetivos es introducir al alumno en la dinámica del proyecto deberemos partir de un conjunto de requerimientos base. No es objetivo de esta formación introducir al alumno en el proceso de toma de requerimientos, por lo que nos mantendremos ajenos a él. Nuestro punto de partida puede ser un pequeño documento que describa un pequeño escenario o si queremos empezar desde ya a identificar capacidades no técnicas, un pequeña conversación (poniéndose el instructor la gorra del cliente) donde se describan los requerimientos a cubrir; es aquí donde el alumno debe comenzar a tomar notas y hacerse un pequeño esquema mental de la solución. No es una toma de requerimientos en sí, ya que lo que hará el instructor será recitar verbalmente los requerimientos como si los estuviera leyendo.
Dependiendo de a dónde queramos llegar elegiremos uno de los dos métodos, eso sí, es fundamental que sea cual sea el formato seleccionado, se abra un espacio para dudas y preguntas por parte del alumno. Es así como comenzaremos a matizar el alcance, reglas de negocio, otros requerimientos, etc; además de comenzar a identificar habilidades no técnicas del alumno.
¿Y qué vamos a construir? Bajo mi punto de vista deberíamos definir una herramienta que motive al alumno, pero cuyo funcionamiento a bajo nivel resulte algo ajeno. Es decir, evitaría temas muy comunes como el desarrollo de una aplicación de gestión para bibliotecas o temas muy complejos como el desarrollo de una herramienta de gestión de cálculo de declaraciones de renta. Como un ejemplo no muy complejo tendríamos una herramienta tipo Facebook o Google+.
Capítulo II: Plazos e hitos
La propia definición de proyecto lo lleva de serie, los plazos. No hay proyecto sin un plazo de ejecución límite, por lo que el alumno debe desde el primer día ser consciente de esta realidad, trasladándole la tensión (que no presión) necesaria para mantener su motivación y dedicación al proyecto.
Este es el momento de trasladar al alumno cuál es la planificación de su primer proyecto (la planificación del curso), con cada uno de sus hitos intermedios y su hito final. Tanto el instructor como el alumno son los responsables de que dicha planificación se cumpla (no solo el instructor), cumpliendo adicionalmente todos los objetivos establecidos para el curso.
Para cada tarea el instructor establecerá tiempos límite. El objetivo es que el alumno empiece a jugar con el tiempo, a saber cuándo puede dilatarlo y cuándo puede (normalmente más que puede debe) contraerlo. No podemos irnos por las ramas, atascarnos de forma permanente; si no podemos tomar un camino, busquemos otra alternativa. La calidad de los resultados tiene relación también con el tiempo, hay que saber jugar con estos conceptos.
Capítulo III: Desarrollo de aplicación de escritorio
Fase 1 – Familiarizarse con el entorno y la tecnología
Como comentábamos al inicio, las formaciones de este tipo siempre han venido de la mano de tecnología Microsoft .NET, por lo que el hilo argumental se basará en la experiencia con dicha tecnología. Es en este punto donde cada instructor deberá adaptar los conceptos y herramientas a la tecnología seleccionada.
En nuestro caso entonces, nuestro entorno de desarrollo podría ser Visual Studio 2010 y nuestro framework el .NET Framework 4.0 (adaptar también dependiendo de los objetivos a lograr).
En esta primera fase, el instructor trasladará al alumno el funcionamiento básico del entorno de desarrollo:
* Tipos de proyecto
* Menús
* Teclas de acceso rápido
y de la tecnología
* Framework .NET 4.0 (en nuestro caso de partida)
* Orientación a eventos
Fase 2 – Solucionar el problema con lo puesto, premisa: todo va en memoria
Manos a la obra, el alumno ya dispone de una versión mínima de funcionamiento del entorno y del framework y conoce los requerimientos a cubrir. El primer objetivo a proponer al alumno es el de construir un aplicativo de escritorio que cubra los requerimientos demandados por el cliente, obviando una de las partes fundamentales de una herramienta de gestión, como es el almacenamiento de la información en un modelo de persistencia no volátil (una base de datos o un conjunto de ficheros).
En este punto el instructor únicamente marca las siguientes premisas:
1) El alumno deberá describir en un pequeño documento las principales entidades implicadas y sus relaciones (no estamos hablando de un modelo relacional formal, simplemente queremos ver que el alumno ha entendido el requerimiento y se ha construido un mapa mental con la información a gestionar y las relaciones que existen entre ella).
2) Antes de iniciar la codificación, el alumno deberá diseñar en primer lugar las interfaces de usuario a partir del entorno visual (WYSWYG) que provee el propio Visual Studio. Interfaces sin comportamiento únicamente descripción de las pantallas.
3) Límite temporal para realizar estas actividades.
Adicionalmente, el instructor puede esperar a ver con qué herramientas soluciona el problema del almacenamiento en memoria el alumno o trasladar una pista inicial que es el uso de listas genéricas, que es donde el instructor pretende que el alumno llegue. Una u otra opción dependerá del plazo temporal que estipulemos para esta primera fase.
El objetivo de esta primera fase se considera alcanzado cuando el alumno ha sido capaz de construir un aplicativo libre de errores con las nociones básicas de programación en objetos de las que cuenta, las nociones de entorno, de framework y la formación en el uso de listas genéricas. Nuestro aplicativo es un aplicativo que cubre el requerimiento sobre una aplicación de escritorio, pero con el pequeño gran defecto de que al cerrar el aplicativo toda la información almacenada en memoria se pierde.
Fase 3 – Primeras Pruebas
En este punto el alumno cuenta con una aplicación que cubre los requerimientos descritos por el cliente (o que debería cumplirlos) y que está preparado para su uso masivo por parte del mismo (esperamos).
Es este el momento para trasladar la importancia del proceso de pruebas. Lo más normal es que el instructor en menos de 5 minutos haya conseguido explotar tanto vulnerabilidades del sistema (objetos no referenciados, validaciones que fallan, problemas de seguridad de acceso, navegaciones ineficientes, etc) y requerimientos que no se cumplen parcial o totalmente. Se debe estudiar cada una de las aplicaciones y trasladar de forma global a los alumnos cuáles han sido los problemas que se han detectado. Es fundamental que el instructor traslade al alumno la importancia del proceso de pruebas y verificación; se la ha de poner en la piel del cliente. El alumno debe afianzar la visión del cliente y quedarse con la máxima “me da igual cómo esté hecho por dentro, lo que te haya costado hacerlo y lo que cueste mantenerlo (esto último no debería darle igual pero ya hablaremos de ese tema otro día), necesito que funcione y solucione mi problema fácil y rápidamente”. La definición técnica y de arquitectura es básica para el éxito del aplicativo y su posterior mantenimiento, pero debemos transmitir a fondo en esta fase que ésta no es la prioridad principal del cliente, por lo que el desarrollador debe darle tanta importancia a los factores técnicos como a los factores de “cliente”. Como ya muchos de vosotros sabréis, los éxitos técnicos son estupendos y maravillosos (seguramente os hayan acusado de románticos más de una vez), pero no son suficientes si el aplicativo no hace lo que tiene que hacer o falla intentándolo; si el aplicativo no es usado, no hay éxito.
Resumiendo, no es objetivo de esta fase validar técnicamente el aplicativo, únicamente el instructor se debe poner la gorra del cliente y revisar el aplicativo a nivel de uso, siendo muy exigente con el resultado obtenido. Es buen momento para trasladar ciertas nociones de usabilidad al alumno y de establecer los mecanismos básicos de herramientas para llevar a cabo pruebas unitarias y funcionales.
Fase 4 – Trasladando buenas prácticas
El punto de entrada de esta fase es una aplicación que representa lo que el requerimiento dictamina, de forma usable y con una tasa de errores no significativa.
Es ahora el momento en el que el instructor deberá analizar cada uno de los aplicativos desarrollados por los alumnos de forma interna, evaluando cuáles son los principales problemas detectados. El nivel de conocimiento previo del alumno es el que va a marcar el camino a seguir a partir de ahora. Resalto a continuación los principales temas identificados como puntos de mejora en desarrolladores con experiencia media-baja.
* No aplicación de patrones de diseño y otras herramientas provistas por la programación orientada a objetos
* No se encapsula
* No se orienta el código a su mantenibilidad
* No se emplean estándares de codificación
* No se comentan los métodos, ni los parámetros, ni los fragmentos de código más complejos
* No se aplican las listas genéricas (si no lo hemos trasladado en una fase anterior)
* No se usan constantes
* Se hardcodean parámetros configurables a partir de ficheros externos
* No se emplean excepciones
* No hay separación entre capas
El alumno tendrá que refactorizar su código atendiendo a todas estas clausulas, logrando disponer nuevamente de una herramienta que cubra los mismos requerimientos y que pase el proceso de pruebas nuevamente. Lo interesante sería que estos conceptos se vayan dando de uno en uno, para que el alumno los vaya asentando individualmente.
Fase 5 – Concepto de capa de acceso a datos
Uno de los problemas que seguramente haya surgido en la primera fase es que no haya separación entre capas, es decir, que el alumno haya construido un aplicativo en el que desde el propio interfaz se esté aplicando la lógica de negocio y accediendo a nuestro repositorio de datos (que por ahora tenemos en memoria).
En este punto es donde vamos a tener que proponer una refactorización importante de código, ya que todo lo que tenga que ver con acceso a datos el alumno deberá moverlo a un conjunto de clases independientes agrupadas por entidades de datos. La interfaz debe dejar de saber dónde estamos almacenando el dato, pudiendo en un momento dado cambiar el modelo de almacenamiento (de memoria a una base de datos física) sin necesidad de modificar una sola línea de código en la capa de presentación. En este punto es interesante trasladar el funcionamiento de patrones como DAO y DTO.
Nuevamente tras el desarrollo, el alumno deberá garantizar que la aplicación cubre los requerimientos y pasa el plan de pruebas, así como que ante un cambio de modelo de persistencia, la capa de presentación no va a sufrir ningún tipo de cambio.
Fase 6 – Definiendo un modelo relacional
El alumno ya debería estar en disposición en este punto de modelar relacionalmente la solución. Para ello, se le provee en este caso de un acceso a una instancia de SQL Server 2008, donde va a poder definir el modelo relacional. Es en este punto donde el instructor deja definir al alumno el modelo sin aplicar ningún tipo de premisa, con el objetivo de identificar necesidades formativas al respecto.
El instructor debería reforzar los siguientes conceptos
* Uso de claves primarias y foráneas
* Uso de relaciones 1-N y 1-1, definición de modelos entidad-relación basados en 3FN
* Abuso de la 3FN y problemas de rendimiento asociados
* Estándar de nomenclatura para campos y tablas
* Introducir comentarios descriptivos en campos y tablas
* Importancia de los índices
* Concepto y programación de procedimientos almacenados (muchos recién licenciados salen de la carrera sin que nadie les haya contado que es un procedimiento almacenado y para qué sirve).
Fase 7 – Almacenando la información de forma persistente
Ya tenemos una capa de acceso a datos que realizamos en la fase 5 y un modelo de datos desarrollado en la fase 6; ahora nos queda preparar nuestra capa de acceso a datos para cambiar el modelo de persistencia y comenzar a persistir sobre nuestra base de datos SQL Server 2008.
En este punto el instructor deberá seleccionar la tecnología de acceso a datos que considere. En caso de orientar la formación a un proyecto específico o tecnología esto nos llevaría a trabajar en este punto con una tecnología de acceso a datos concreta. En casos en los cuales no tengamos clara la salida del alumno, y a nivel general, recomiendo partir de las clases básicas de acceso a datos que provee el framework (ADO.NET; JDBC para formaciones Java), que accedan a los procedimientos almacenados que el alumno ha creado sobre la propia base de datos.
Esta fase va a generar una refactorización exclusivamente sobre la capa de acceso a datos (si hemos hecho bien el resto), y nuestra aplicación, sin necesidad de tocar una sola línea en el interfaz, va a pasar de almacenar la información en memoria a almacenar la información en base de datos.
Como siempre, tras este cambio, la aplicación va a tener que seguir cumpliendo el requerimiento y pasando el plan de pruebas.
Tras este desarrollo, el alumno debería percibir la importancia del trabajo en capas, la abstracción que supone el uso de capas separadas, reforzando el uso de clases con una alta cohesión y bajo acoplamiento.
Fase 8 – Concepto de capa de lógica de negocio
Nuestro código dispone en este punto de una capa de presentación que no conoce de dónde proviene el dato que está manejando, pero que sí conoce la lógica del negocio. Es decir, si para nuestro negocio dar de alta un nuevo modelo de coche en nuestro software de gestión de flotas de vehículos supone, además de realizar una inserción en la tabla que almacena los modelos a través de nuestra nueva y reciente capa de acceso a datos, enviar 3 e-mails a 3 destinatarios diferentes, replicar un conjunto de datos asociado al modelo en otro contexto diferente al nuestro, generar un fichero de comunicación con otros sistemas, etc; en este punto todo este código seguramente estará ubicado en el propio evento “onClick” del botón dar de alta nuevo modelo de coche.
El objetivo de esta fase es que una vez finalizada, nuestro aplicativo cuente con una capa de negocio que encapsule todo este comportamiento. Nuestro botón “onClick” debería llamar a un único método llamado “DarDeAltaModeloCoche” que se encargara de realizar todas las acciones pertinentes (entre otras realizar la inserción del nuevo modelo de coche a través de la capa de acceso a datos). La capa de presentación no sabe dónde se almacena el coche, y qué significa para nuestro negocio el dar de alta un modelo de coche.
Nuevamente, el aplicativo deberá respetar los requerimientos y pasar el plan de pruebas.
Fase 9 – Otras capas: Caché, Validación
Incluimos a continuación nociones de uso de otras capas como Caché, Validación, etc. Es un bueno momento para trasladar al alumno teoría de algunos patrones como Singleton, Strategy, Factory, etc.
El aplicativo debería reflejar dichos ajustes.
Fase 10 – Librerías
Nuestro código, aunque separado perfectamente en diferentes capas, ha estado formando parte de la misma aplicación en todo momento. Es este el momento de incluir los conceptos de librería de clase, y dividir cada una de las capas en librerías diferenciadas por el proyecto inicial. Acceso a Datos, Negocio, Validación, Entidades de Negocio… son librerías diferenciadas que podrán ser actualizadas de forma independiente y reutilizadas.
Capítulo IV: Replicando en Web
Es precisamente en este punto donde vamos a comenzar a reutilizar el trabajo realizado en la última de las fases de desarrollo de aplicaciones de escritorio, ya que vamos a referenciar las librerías de negocio, acceso datos, caché, validación y otras capas que hayamos creado para la aplicación de escritorio. Todo el trabajo va a ser reutilizado a excepción de la capa de presentación que es la única que va a cambiar. El alumno deberá notar la potencia de haber desarrollado su anterior trabajo con esta orientación, limitándose a realizar una nueva interfaz.
En este punto el instructor debe trasladar conocimientos avanzados al respecto de
* HTML
* Javascript
* CSS
* ASP.NET
Una vez finalizado este capítulo, el alumno cuenta con dos aplicativos diferentes que realizan exactamente la misma función y sobre los que únicamente se diferencia la interfaz (ambos referencian a los mismos proyectos de tipo librería para realizar cálculos de negocio y almacenamiento de datos).
Capítulo V: Replicando en Dispositivos Móviles
Mismo trabajo en el punto de desarrollo de aplicaciones web, pero en este caso realizando desarrollo sobre proyecto de aplicación móvil.
Capítulo VI: Distribuyendo el negocio, concepto de servicio, arquitectura SOA, independencia del dispositivo
Nuestro aplicativo ha referenciado hasta ahora librerías locales. Ha llegado el momento de distribuir el conocimiento del negocio en un aplicativo distribuido: Windows Communication Foundation. Si todo ha ido bien, las tres capas de presentación diferenciadas con las que contamos en este momento (escritorio, web, móvil), únicamente deberán cambiar su referencia de las librerías locales a los servicios web publicados por el aplicativo WCF que también crearemos en este punto.
Hasta aquí la primera versión de este método, donde intento a alto nivel dar a entender el formato de formación que hasta ahora mejor resultado viene dando, permitiendo en un plazo de 3/4 semanas situar al alumno en una dinámica de proyecto lo más cercana a la realidad, habiendo repasado conceptos de arquitectura medios y avanzados que forman parte del día a día de los proyectos de software; todo ello en un ambiente divertido y de aprendizaje continuo.
Intentaré en próximos artículos bajar de nivel de abstracción alguno de los puntos, intentando dar algo más de detalle de cómo enfocarlos a más bajo nivel.
Un saludo.
Miguel.
Permalink
09.09.09
Posted in Arquitectura, Enterprise Library at 8:36 pm by Miguel
Y es que a la hora de acceder a una base de datos tenemos tantas opciones que muchas veces lo complicado es intentar decidir cuál de todas resulta la mejor para nuestro proyecto y/o organización.
Trabajando con .NET los dos motores de base de datos más empleados son SQL Server y Oracle, y para acceder a ellos desde una de nuestras aplicaciones podemos pasar desde utilizar los drivers propios de Microsoft para acceder a ambos gestores, con clases propuestas por el propio framework, podemos acceder a oracle a traves de los Oracle Data Access Components (ODAC) para .NET, podemos usar Datasets Tipados con sus correspondientes TableAdapter para aliviar algo el tiempo de construcción… utilizar patrones de acceso a datos como DAO+DTO… y un largo etcétera que puede pasar por soluciones caseras más o menos elaboradas, aplicaciones de otros patrones de acceso a datos como puede ser Active Record o herramientas de acceso a datos orientadas entidades como el nuevo Microsoft Entity Framework y la versión de Hibernate para .NET, NHibernate. Para más diversión, incluso pueden emplearse combinaciones de alguna de las herramientas descritas en el párrafo, intentando ajustar el esfuerzo de construcción a nuestro proyecto y, lo más complicado de todo, a nuestra planificación 
Pues ante toda esta lista interminable de herramientas, cada una con sus pros y sus contras, añado y expongo a continuación las ventajas aportadas por otra más, las Enterprise Library con su funcionalidad de acceso a datos: Data Access Application Block.
¿Qué nos aporta el Data Access Application Block?
Pues una de las principales ventajas que aporta el framework es que permite con la misma codificación atacar a diferentes gestores de bases de datos, es decir, tras preparar el acceso a datos de nuestra aplicación con enterprise library, podríamos ser capaces sin cambiar ni una línea de código (no os toméis esto al pie de la letra, que seguro que algo habrá que cambiar aunque sea mínimo), de pasar de atacar a un SQL Server a un Oracle. Esta puede ser una gran ventaja si estáis preparando un producto al que dependiendo del cliente al que se lo vendáis tengáis que garantizar el soporte de ambos gestores, porque por ejemplo alguno de vuestros clientes esté casado con Oracle y otro con SQL Server. Con un sólo desarrollo de vuestra capa de acceso a datos cubriréis toda la casuística (menos los procedimientos almacenados, claro, que os va a tocar picarlos dos veces ).
Otras ventajas a tener en cuenta son la facilidad de configuración. Una vez instaladas las enterprise library disponemos de una pequeña aplicación que apuntándola al Web.Config o App.Config de nuestro aplicativo permite editar las propiedades de conexión de manera visual. Pudiendo configurar el proveedor de la conexión, tipos de autenticación y más parámetros propios de una conexión a datos de forma muy cómoda y sencilla.
Una vez configurada la conexión, con una línea como la siguiente conectamos con el gestor, independientemente de cuál sea (DataBase y DataBaseFactory son clases del Data Access Application Block).
Database nuestraDB = DatabaseFactory.CreateDatabase(“nombreConnectionString”);
Para hacer una consulta que retorne un conjunto de registros a través de un procedimiento almacenado:
DataReader ejemploDR = nuestraDB.ExecuteReader(CommandType.StoredProcedure, “spu_get_allitems”);
Y para recorrer el datareader, pues como siempre, utilizando el método Read y luego en el registro sobre el que trabajamos obteniendo el dato a través del identificador de la columna.
Como véis es rápido y sencillo (no tanto para los que os toque trabajar contra Oracle, ya que os vais a necesitar conocer algún truquillo extra), y os ayuda a mantener una total independencia con el gestor de base de datos.
Bajo mi humilde opinión, Data Access Application Block podría ser un buen candidato a herramienta de acceso a datos corporativo en cuanto al desarrollo de soluciones .NET.
Saludos.
Miguel.
DAB.Database dbTampico =
DAB.DatabaseFactory.CreateDatabase(“cnTampico”);
Permalink
06.02.09
Posted in .NET, Arquitectura, Web at 6:47 pm by Miguel
A continuación paso a enumera una serie de consideraciones a tener en cuenta y que os pueden ser útiles a la hora de tomar ciertas decisiones de arquitectura al respecto del uso de variables de sesión. Como veréis algunas de ellas tienen que ver con entornos .NET, ya que es la plataforma con la que suelo trabajar, pero la mayoría son aplicables a otros entornos tecnológicos no Microsoft.
Sesión en Memoria vs Sesión en Sistemas Persistidos (Base de Datos o Servicios del Sistema Operativo)
La forma más eficiente de trabajar con sesiones es manteniendo su contenido en memoria. En el caso de estar trabajando con una granja de servidores, pueden utilizarse soluciones existentes en el mercado como es NCache, para balancear el contenido de las sesiones en memoria entre todos los servidores de la granja.
En caso de no poder barajar esta alternativa existen soluciones que permiten almacenar el contenido de la sesión sobre sistemas persistidos. Esta solución es más lenta, pero permite compartir la información de sesión sobre diferentes servidores, además de garantizar que aunque se reinicie el servidor de aplicaciones, la información de sesión va a permanecer disponible cuando la aplicación vuelva a arrancarse.
Cantidad de Memoria en Uso
El uso de sesión afecta directamente al consumo de memoria del servidor que está ejecutando las llamadas del cliente, por lo que deberá almacenarse en sesión únicamente la información que se considera imprescindible y que, se recomienda, esté relacionada con alguna de las siguientes características:
- Información básica relacionada con la autenticación o la seguridad del usuario y que es necesario comprobar en las llamadas o peticiones que realiza el usuario contra la aplicación.
- Otro tipo de información funcional asociada al usuario, que va a permanecer estática a lo largo de toda la vida de la sesión y que es requerida de forma constante en las peticiones que realiza el usuario a la aplicación. El objetivo de este punto sería minimizar el número de llamadas a base de datos.
Tipos de Objetos en Memoria
Los objetos almacenados en la sesión deben ser en todo caso de poco peso, minimizando así la cantidad de información almacenada por sesión por cada objeto. Se recomienda el uso de objetos de negocio que incluyan tipos de datos básicos. No se recomienda el almacenamiento de objetos propietarios de .NET del tipo Dataset ó DataTable debido al tamaño asociado a los mismos.
Manejando Información Sensible
Si el contenido almacenado en la sesión contiene información sensible, como podrían ser contraseñas o información personal del usuario activo, ésta deberá permanecer encriptada durante todo el ciclo de vida de la sesión.
Usando Sesión a modo de Caché
No debe emplearse la sesión para almacenar catálogos de datos comunes de la aplicación, como podrían ser listados de países, regiones, provincias, etc, ya que éste no es el objetivo de este tipo de objeto. Para estos casos se deberá recurrir a un objeto de tipo caché.
Usando Sesión a modo de Viewstate (específico .NET)
No se recomienda emplear la sesión para almacenar información que será necesaria explotar entre llamadas a la misma página, ya que para ello existe un objeto preparado específicamente para resolver esta problemática como es el Viewstate de ASP.NET.
Usando Sesión a modo de POST y GET
No debe emplearse la sesión para transportar información entre páginas de la misma aplicación, ya que para ello se deberá recurrir a los objetos POST y GET.
Liberando Información de Sesión
Siempre y cuando se detecte que la información almacenada en sesión deje de ser necesaria para la sesión de usuario actual, se debe solicitar la liberación de la memoria asociada al servidor.
Saludos.
Miguel.
Permalink
