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.

MARS MultipleActiveResultSets True

Cuando estas trabajando con SqlDataReader para obtener informacion del SQL Server 2005 muy probablemente te encuentres con este mensaje al ejecutar el metodo ExecuteReader del SqlCommand:

There is already an open DataReader associated with this Command which must be closed first.

En terminos sencillos, se nos dice, que ya tenemos un SqlDataReader que se encuentra abierto y NO seria posible aperturar otro al mismo tiempo, mientras NO se cierre el primero.

Para este incidente, el SqlServer2005 brinda la posibilidad de agregar una propiedad al ConnectionString para permitir multiples SqlDataReader abiertos, al mismo tiempo.

Agregando MultipleActiveResultSets=True al ConnectionString se resuelve el problema.

Sin embargo recuerda que esta facilidad solo esta permitida en SQL Server 2005 y superiores.

En la version del SQL Server 2000 esta propiedad para el ConnectionString NO esta factible de utilizar. Por lo que el error aun prevalecera.

SetValue PropertyInfo FieldInfo Struct

Cuando defines tus Business Entities como structuras y NO como clases, es decir como struct.

Estableciendo sus diferentes atributos, para que posteriormente manejar el mapping correcto con su correspondiente tabla a nivel de base de datos, requeriras de una mecanismo generico para hacer la lectura de los registros de dicha tabla de base de datos hacia una coleccion de Business Entities, para manejarlos como tal dentro del mundo .NET

Hasta alli, todo relativamente normal.

Pero al usar un struct para definir cierto Business Entity, te daras cuenta que el metodo SetValue del PropertyInfo o el FieldInfo -dependiendo lo que estes usando para definir las propiedades o atributos de tu Business Entity- NO estan funcionando como tu esperas.

Lo que sucede es que las estructuras o struct, son tipos de datos por valor a diferencia de las clases o class.

Y este es uno de los puntos en contra al utilizar estructuras o struct para definir tus Business Entities.

En este incidente la clase ValueType resuelve tu problema.

TEntity entity = new TEntity();

Debera ser reemplazado por:

ValueType entity = new TEntity();

Dentro del bucle que este leyendo el SqlDataReader para iterar cada uno de los registros de la consulta que hayas realizado, mapeando cada uno de estos registros dentro de su Business Entity para retornar finalmente a una coleccion de Business Entities, a quien haya utilizado el metodo generico que implementaste.

IEnumerable ExecuteReader( String sql ) where TEntity : struct

Vale recalcar que es importante utilizar la clausula where TEntity : struct para poder instanciar el template TEntity dentro de la implementacion de dicha funcion y para poder castearlo a un ValueType, posteriormente.

Top Down versus Bottom Up

Cuando desarrollamos software con conectividad a Base de Datos, nos encontramos con diferentes herramientas, en el mercado, que facilitan la construccion de los Business Entities a partir de una estructura de datos relacional.

El resultado es alentador. Gracias al Drag & Drop o algo relativamente similar obtenemos los Business Entities para el mundo .NET desde el conjunto de tablas que se encontraban ya definidas en la Base de Datos.

Esta es una perspectiva Bottom-Up.

Pues partimos del nivel mas bajo de la arquitectura de un producto de software, la Base de Datos, para facilitar la contruccion de las demas capas de la arquitectura, aquellas que estan por encima de la Base de Datos.

Pero existe la posicion contraria. Un punto de vista distinto, llamado Top Down.

A partir del cual prototipeamos las interfaces de usuario, con las cuales este -el usuario- ha de interactuar con el producto de software que vayamos a construir, para ir construyendo conceptualmente las demas capas de nuestra arquitectura de software.

Seguidamente un modelo de clases que se desprendera a partir de la discusion y analisis de los casos de uso, sera nuestro siguiente paso.

Dicho modelo de clases orientados al negocio del producto de software, que tenemos la mision de construir, estan relacionados en funcion a: herencia, asociacion, agregacion y otros mecanismos de relacion los cuales NO necesariamente deberian plasmarse tal cual en la estructura de datos final, ya en la Base de Datos.

Y he aqui la moraleja.

Ambas perspectivas tienen sus pros y contras, cada una de ellas validas desde sus respectivos puntos de vista.

Pero ambas perspectivas: Top Down y Bottom Up, se encuentran en ese punto. Aquel punto donde la conciliacion es el mejor fusible, para tener contentos a la mayoria, pero NO siempre la mejor solucion.

Para Bottom Up un Business Entity en terminos sencillos deberia ser tal cual una tabla que esta definida a nivel de Base de Datos. Tantas propiedades en cada Business Entity como columnas existan en la tabla correspondiente.

Por otro lado, Top Down propone algo diferente pues la relacion de una herencia o una agregacion a nivel de un modelo de clases de negocio NO se plasman tan facilmente a nivel de Base de Datos.

Menudo problema.

Web Service Software Factory

El Web Service Software Factory es una verdadera cochinada.

Más de cuatrocientos archivos que construye aquel bendito tool, de un modelo de NO mas de 20 tablas en mi base de datos, son prueba indubitable e insoslayable de la afirmación inicial.

Por cierto, recuerdo que tuve que renombrar a nivel del tool, todas la tablas e inclusive los campos de las mismas, para poder obtener un resultado relativamente decenten, en principio, a nivel de Business Entities.

Pero conforme vas haciendo cambios a nivel de la estructura de datos, te das con la amarga sorpresa, que esto trae como consecuencia que tengas que zambullirte en las cuchumil cuatrocientas clases creadas en el Data Access de tu solución.

Yo solo quiero hacer un UPDATE en un campo de una de mis tablillas. ¿Por que me complicas la vida?

¿Acaso no pensaron colocar un boton en el tool que diga algo asi como REFRESH?

En fin, esas son una de las razones por la que usar esta cochinada es una verdadera perdida de tiempo.

Nada como el BusinessLayer.Components y el BusinessLayer.Entities liberado hacer unos años atras, y que fue un golazo en su momento.

Hoy sin embargo, en los cuarteles de invierno, construyendose la version para LINQ aprovechando los lambda expression y clases anonimas para acelerar la construcción del Desarrollo de Software y que favorezca la estabilidad en dicha fase de producción.

Tan distante de las actuales realidades.

Beta vs Release Visual Studio 2008

Cuando estas trabajando con el Visual Studio .NET 2008 version de evaluacion BETA, te sientes algo ofuzcado. Pero luego haces el cambio a la version RELEASE, la firme pe, la que se distribuye comercialmente y notaras ciertos cambios inmediatamente.

Uno de los cambios que se percibien con mayor claridad estan orientados a la velocidad con la que carga el Visual Studio .NET 2008 version comercial.

Haces click y ya tenemos el entorno de desarrollo abierto en el escritorio de trabajo. Sin tanto loading!

Y es que la version BETA se demora un siglo en abrirse y posteriormente cuando trabajas con la apertura de archivos en tiempo de diseño muestra cierto LAG.

Algo muy distinto en la version comercial.

Instala tu Visual Studio .NET 2008 ya!

Page LoadControl UserControl OnInit

Cuando tecnicamente decides usar el Page.LoadControl( path ) para cargar dinamicamente en tiempo de ejecucion los UserControls definidos en tu web application, tienes que tener en mente ciertas caracteristicas que por cuestiones de diseño de ASP.NET son aplicables en este contexto.

Sucede que el evento OnInit del UserControl que se desea cargar dinamicamente no trabaja de la misma forma en la que se manifiesta cuando es cargado en tiempo de diseño.

En se caso, solo te queda realizar una llamada a un metodo que tu definiras en aquel UserControl donde estableceras explicitamente los EventHandlers de los Controles que alli este definidos.

Por ejemplo, si tuvieras un DataList, naturalmente es muy probable que necesites enlazarte al ItemDataBound de este DataList.

Algo que normalmente tendrias que definir en el OnInit del UserControl que contiene a este DataList.

Pero si este UserControl va a ser cargado dinamicamente en tiempo de ejecucion entonces te daras cuenta que algo no esta funcionando bien si lo haces de esa manera.

Por lo que corresponde realizar el enlace al ItemDataBound del DataList en el mismo metodo que es llamado por la pagina que contiene al UserControl para que en dicho metodo se realize dicho enlace.

Y ver que todo vuelve a la normalidad.