Linq support server-side data paging

Cuando estas desarrolando software con Visual Studio 2008 para utilizar todos los beneficios de usar Linq, te encontraras con este mensaje de error, al intentar enlazar un origen de datos Enumerable.SelectIterator sobre un GridView:

The data source does not support server-side data paging.

Apesar de haber configurado las propiedades AllowPaging="true" del GridView, este mensaje te saca de las casillas y puedes equivocadamente sospechar que las expresiones Linq NO pueden enlazarse a un simple GridView.

var q = from item in Clients select item;
this._grid.DataSource = q;

Donde la variable Clients es una coleccion de datos, cualesquiera.

Sin embargo, al enlazar el objeto de estructura de datos inferida, es decir: q, sobre el DataSource del GridView, debe utlizar el metodo ToList()

this._grid.DataSource = q.ToList();

De esta manera superaras un inconveniente tecnico, que antes NO se habia experimentado, es decir en las versiones anteriores.

Linq brinda una serie de beneficios para poder trabajar con colecciones de objetos en el mundo .NET de una manera similar a SQL, sin que esto implique necesariamente una operacion hacia la Base de Datos.

Naturalmente, entre los pro y contra encontra algunas dificultades tecnicas que se deben superar.

Row not found or changed

Uno de los exceptions que por lo general aparecen cuando estas trabajando con Linq to Sql, es el ChangeConflictException.

El mensaje tradicional correspondiente a este exception es: Row not found or changed.

Cuando recien estas construyendo el software. Muy probablemente te encuentres con este mensaje. Si no te calmas en encontrar la solucion, te podria sacar de tus casillas.

Lo que sucede es que generalmente la base de datos esta aun ajustandose, cambiando si un campo de la tabla permitira nulo o NO, por ejemplo. Si un tipo de dato BIT sera cambiado a un CHAR(1), por decir algo.

Y otras simpleces a nivel de base de datos.

Pero aquellos cambios, por la premura del tiempo o por alguna circunstancia, NO son plasmados tambien en el modelo que propone Linq To Sql, dentro de tu aplicativo.

Y he alli el origen del problema.

Cuando estas desarrollando software y te apoyas en Linq To Sql para facilitarte la construccion de los Business Entities, debes estar pendiente que la estructura de tablas de tu Base de Datos sincronize con las caracteristicas de los Business Entities asociada a cada tabla.

Al realizar una operacion de actualizacion o eliminacion contra la Base de Datos de un elemento en particular, Linq To Sql no construye la sentencia SQL en funcion a un WHERE mykeyfield = @mykeyfield

Linq To Sql realiza un WHERE en funcion al estado actual del registro previo al cambio.

Y si alguna caracteristica de tu Base de Datos NO esta sincronizada con el modelo de Linq To Sql, pues veras este mensajito constamente: Row not found or changed.

Por citar una ejemplo, que un campo en la base de datos haya sido cambio para NO permitir nulo, cuando antes si lo permitia. Pero sin embargo dicho cambio NO se realizo de la misma manera en el modelo de Linq To Sql, se entiende que para Linq To Sql aquel campo aun permite nulo.

Entonces al construir su WHERE, Linq To Sql, constuira una lista de campos para hacer el match del estado anterior del registro y con un myfieldchange IS NULL dentro de todos ellos.

En lugar de algo distinto al nosotros saber, que a nivel de Base de Datos, esto ya NO esta permitido.

En consecuencia, Linq To Sql NO puede encontrar el registro anterior, debido a que efectivamente este ya NO existe, bajo esas circunstancias.

La solución pasa por simplemente sincronizar la estructura de tu Base de Datos a nivel de campos con tu modelo de Linq To Sql.

Trabajo facil!

Usando Interfaces en Linq To Sql

Una de las cosas que me incomoda de Linq To Sql, es que no brinda la posibilidad inmediata de construir un modelos de clases orientada al uso de Interfaces.

En terminos sencillos, Linq To Sql te brinda un modelo de clases basada en el modelo entidad relacion de tu base de datos.

Si el objetivo es llenar un GridView y mas nada. Seguramente estaras contento con Linq To Sql. Pero si no. Uhmmm.

Un producto de software no solo es llenar GridViews. Es mucha más que solo aquello.

Las reglas del negocio traen como consecuencia contruir un modelos de clases basada en la implementación de Interfaces: IUser, IGroup, IPurchaseOrder, IInvoice and others.

Te das cuenta. ¿Por que? Pues porque es la forma profesional de construir software.

Pero me quita tiempo. Dicen algunos. Si pues efectivamente, construir software no es hacer click and click.

¿Cual es el objetivo desde la perspectiva de nosotros, los Jefe de Proyecto?. Pues que el producto de software pueda escalar en el mediano y corto plazo. Desde el punto de vista tecnico. Sin embargo desde el punto de vista comercial, de la casa de software, es entregar el producto a tiempo.

Estas dos posiciones se contraponen y se enfrentan en algun momento.

Y es justamente el Jefe de Proyecto, quien ponen de manifiesto toda su capacidad para satisfacer ambos objetivos.

En consecuencia, Linq To Sql nos esta nativamente orientada a satisfacer el objetivo tecnico. Esta orientada mas al otro objetivo, el comercial.

Entonces ¿que hacer?. Meterle mano para que tu producto de software pueda ser escalable en el tiempo. Y sino quiero. Pues click and click. Tranquilo, no se te quemara neurona alguna. Je!