Bottom Up para desarrollar software

La perspectiva Bottom Up para desarrollar software provoca que una de tus primera tareas sea modelar la estructura logica de la Base de Datos que soportara el producto de software que vayas a construir.

Muchas veces se cae en la simpleza de mencionarse que si la base de datos esta bien modelada cualquier cambio posterior NO tendra un impacto muy grave.

Los que estamos involucrados en el mundo del desarrollo de software con conectividad a Base de Datos, hemos modelado una estructura de datos, si o si, y hemos visto hasta Base de Datos en produccion, sin primary keys, constraints, relations ships, sin nada.

Con campos redundantes de informacion de una tabla en otra, entre quienes existen solo algun tipo de relacion.

Entonces, ¿hasta que punto es valido rasgarse las vestiduras para aferrarse a la fragil idea de que la base de datos debe estar MUY bien modelada?

En la fase de la contruccion del software, aquella en la que los developers empiezan su tarea, desarrollan las vistas del usuario y demas, por alguna u otra circunstancia se haran necesarios diferentes cambios en la estructura de datos original de la base de datos que hayas modelado.

NO existe el modelamiento preciso y exacto que resuelva todas las incidencias posteriores, sin requerirse cambios en los objetos de la base de datos: tablas, campos, relaciones, etc.

Si aun puesto en produccion, el software al ser usado por un mayor volumen de usuarios, brotaran incidencias que traeran como consecuencias cambios en las vistas y muchas veces -algunos de esos cambios- requeriran cambios en la estructura de datos original, pues con mayor razon que en la fase de la construccion del software seamos testigos presenciales y activos de esos cambios.

La Base de Datos NO tendria por que ser necesariamente la mayor de las prioridades, pues las vistas del usuario NO interacturan directamente con dicha estructura.

La capa de negocio o Business Layer adquiere mayor relevancia.

Clases parciales con Visual Source Safe

Una de las tantas aplicaciones que puedes darle a las clases parciales esta directamente asociada con el uso del Visual Source Safe 2005.

Cuando tienes algunos developers en tu equipo de trabajo, dedicados a la construccion de un producto de software y se apoyan en Visual Source Safe para la gestion y cuidado del codigo fuente, sucede una necesidad.

Acceder a un archivo .cs en particular para agregarle alguna funcionalidad o aplicar un pequeño refactory en el mismo.

Sea como fuese, es necesario poder acceder a un mismo archivo fisico a la vez.

Justamente el Visual Source Safe existe para todo lo contrario. Impedir el acceso de escritura a un mismo archivo fisico, a la vez.

Ante el requerimiento de poder hacerlo y la funcionalidad de la herramienta que te lo impide, utilizar Clases Parciales o Partial Classes es una solucion al problema.

Al utilizar mas de un archivo fisico para definir una entidad logica, solo te quedara la tarea de agrupar ciertas funcionalidades en el primero de los archivos y otras funcionalidades en los archivos fisicos restantes.

Puedes utilizar tantos archivos fisicos requieras para la definicion de tu entidad logica, la clase.

Web Client Software Factory

Una propuesta para desarrollo de software en modalidad web con la propuesta Model View Presenter MVP, es el llamado Web Client Software Factory.

Este interesante add-on para el Visual Studio .NET 2005 propone una forma peculiar de desarrollar software para ASP.NET.

Web Cliente Software Factory se monta sobre el Composite UI Application Block.

Esto es una ladilla pues cuando te encuentres desarrollado alguna vista en particular te encontraras con un error mas deconocido que el anterior.

Unos errores realmente espantosos.

Ello es consecuencia directa de utilizar el Composite UI Application Block como base para el Web Client Software Factory.

Por otro lado, el Web Cliente Software Factory propone un marco para desarrollo de una aplicacion ASP.NET en lo correspondiente a la capa del usuario. El manejo de las vistas a traves de un presenter.

Escucharas sobre Presenters, Controllers y Views a diestra y siniestra.

Sin embargo, debes y tienes que encontrar una forma creativa de fusionar la propuesta del Web Client Software Factory con tu capa de negocio y posteriormente con tu capa de acceso a datos.

De una forma u otra, sentiras en carne propia que requieres utilizar mas tiempo -que el que utilizabas antes- para construir un aplicativo cualesquiera bajo la propuesta del Web Client Software Factory.

Los Views solo deberian gestionar los eventos de los controles que estan disponibles al usuario.

Los Presenters son los encargados a establecer la logica de presentacion de la informacion en los Views. Pues los Presenters tiene una referencia a los Views.

Esto podria sonar relativamente extraño, pero es asi. Pues uno espera que sea el View que tenga una referencia al Presenter, sin embargo la referencia es a la inversa y eso ayuda a poder utilizar los elementos definidos en los Views desde el Presenter.

Los Controllers hacen justamente eso, controllar la forma en que los Presenters han de interactuar.

Sin embargo, queda en un limbo como hacer para que tu Business Layer se integre facilmente con la propuesta del Web Client Software Factory.

Cada quien tiene su propio criterio y encontraras soluciones buenas y otras NO tan buenas.

En el intento esta la respuesta. Y en las pruebas de stress la mejor solucion.

Tipos anonimos en C# 3.0

Una de las cosas que me fascinan del C# 3.0 es el uso de tipo anonimos.

Las tipos anonimos o anonymous types, tambien conocidos como clases anonimas, brindan una posibilidad interesante que nos hubiese gustado poder disfrutar en la version C# 2.0 del Visual Studio .NET 2005.

Una de las primeras aplicaciones de los tipos anonimos lo encontramos en el desuso de los RowDataBound del GridView al mostrar informacion de vistas relativamente sencillas.

Gracias a que existen los tipos anonimos, puedes entregar un lista de elementos cuya estrutura NO se encuentra definida previamente.

Muchas veces, al usar un modelo de objetos basado en Collections and Business Entities, se hacia necesario utilizar el RowDataBound del GridView para poder enlazar los controles definidos en los TemplateColumn -que hayas diseñado en el GridView- con el dato que deseas.

Por ejemplo, si tenias un collection de Clientes y tienes una propiedad para cada cliente llamada TipoCliente.

Evidentemente NO hibas a enlazar en una columna del GridView solo el ID del TipoCliente.

Era requerido por el usuario final, mostrar la descripcion del TipoCliente en la grilla de datos.

Ese tipico escenario, era motivo para utilizar el RowDataBound del GridView, con la intencion de enlazar el Label que habias definido en el TemplateColumn con el dato que se encontraba en ICliente.TipoCliente.Descripcion que habias establecido segun el modelo de objetos a nivel de la capa de negocio del producto de software que te encontrabas construyendo.

Gracias a las clases anonimas y su facil uso, hemos dejado de usar los RowDataBound del GridView en algunos tipicos escenarios.

Esto ayuda mucho en la mejora del tiempo para el desarrollo del software.

Al poder definir un collection de tipos anonimos de una forma relativamente similar a: new { item.Entity.ID, item.Entity.Nombre, item.TipoCliente.Descripcion }; donde item es un objeto del tipo ICliente y naturalmente la clase Cliente implementa la interfaz ICliente, todo se hace mas sencillo y menos trabajoso para el developer.

Los tipos anonimos han logrado facilitarnos la vida, como NO tienes idea.

Partial Class en Visual Studio .NET

Una de las mejoras del C# 2.0 son las Partial Class o clases parciales.

Partial Class permite definir una misma clase y sus miembros en archivos .cs distintos.

Una de sus primeras aplicaciones lo encontramos en los .designer de las ASPx web pages.

Pues en las versiones anteriores del Visual Studio .NET previas al 2005 los elementos definidos en el diseñador de las paginas ASPx eran plasmados en un solo archivo aspx.cs.

Lo cual se le hacia muy complicado gestionar al Visual Studio .NET 2002 y 2003, por ejemplo.

Hoy esto ha sido superado. Facilitando el manejo del designer y la estabilidad del Visual Studio .NET 2005 y con mayor razon en el Visual Studio .NET 2008.

Usar las Partial Class es un primer ejemplo del Divide y Venceras.