Thursday, July 31, 2008

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.

Monday, July 28, 2008

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.

Wednesday, July 23, 2008

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.