En esta publicación voy a mostrar cómo se puede mostrar documentos XML "transformados" o formateados en una página web, para ello se utiliza el XML Web Server Control.

Este componente que nos facilita el Framework, nos permite mostrar en un área de una página o formulario web el contenido de un documento XML, pero lo más interesante es que se lo puede "procesar", para ello utiliza otro documento (un XSLT Extensible Stylesheet Language Transformation) que no es otra cosa que un documento en XML que indica cómo se debe procesar en este caso "transformar" el documento original.

Esto muy útil cuando la organización para la que desarrollamos una aplicación recibe frecuentemente documentos en formato XML y mediante un hoja de transformación podemos mostrar el contenido del documento.

More...

Vamos a continuar mostrando algo más de la relación que XML tiene con ADO.NET.

En la publicación anterior, mostramos la forma más simple de obtener documentos en formato XML o de enlazar un componente de interfaz de usuario con un documento XML.

Ahora vamos a mostrar las posibilidades que XML nos brinda cuando de relaciones se trata; para ello vamos a volver a utilizar las tablas de otras publicaciones, en este caso utilizaremos Provincias y Departamentos donde sabemos que existe un relación de uno a muchos.

More...

En esta publicación vamos a ver un poquito de la relación que XML tiene con ADO.NET.

XML - Extensible Markup Language, es un estándar cuya historia se remonta a los años setenta, que surge como la necesidad de compartir información en un formato que sea fácil de entender y procesar y particularmente que no dependa de la aplicación o plataforma en la que se procesan los datos. Su nombre lo dice claramente, se trata de un lenguaje de marcas extensible; es un lenguaje porque nos permite comunicarnos, utiliza marcas para indicar los datos que conforman la información que comunicamos y es extensible porque podemos extender el lenguaje a todas nuestras necesidades.

Los componentes léxicos, la sintaxis y semántica de este lenguaje es muy sencilla puden hallar infinidad de información en la red; sugiero que arranquen por el estándar.

Actualmente XML es utilizado absolutamente en todos lados, por supuesto permite el trabajo entre aplicaciones desarrolladas en diferentes plataformas, hasta se puede leer un documento XML con un simple editor de texto; de modo que es indiscutible las ventajas que el lenguaje facilita a los desarrolladores y consecuentemente a las organizaciones.

El Microsoft Framework facilita varias alternativas para trabajar con documentos XML, una de ellas es la posibilidad que los DataSet (representación en memoria de un conjunto de tablas de la base de datos) manipulen información en formato XML.

El siguiente ejercicio nos permite ver como se puede generar información en formato XML, y en el mismo ejercicio veremos cómo podemos utilizar un origen de datos en formato XML.

More...

Con esta publicación vamos a realizar lo que la mayoría de los desarrolladores denominan un ABM (Altas, Bajas y Modificaciones) que también se conoce como CRUD (Create, Retrieve, Update and Delete).

En esencia se trata de las operaciones básicas que pueden realizarse sobre una tabla de información de alguna base de datos.

Como mostré en publicaciones anteriores, el asistente que facilita Visual Studio permite generar un formulario o página web que lo hace todo, todas estas operaciones se pueden realizar con un GridView que "viene" con todo el comportamiento listo para utilizar. Sin embargo la implementación de todo el código en un único archivo (en este caso el .aspx) está lejos de ser un desarrollo en capas; por otro lado la o las aplicaciones pueden requerir de una lógica de negocios compleja que debe mantenerse en clases separadas de la interfaz de usuario.

Consecuentemente vamos a realizar el ejercicio tratando de separar un poco las responsabilidades, por un lado vamos a contar con una interfaz de usuario que nos permita mostrar la información, y otro componente que nos permita editar la información ya sea de un nuevo registro o de uno existente en la tabla. Obviamente vamos a implementar un mecanismo de acceso a datos en una clase que para este ejercicio será la misma entidad del ABM o CRUD.

More...

En la publicación anterior comenté algo sobre "eficiencia" y es porque estoy convencido que los desarrolladores siempre debemos tener esa palabra en mente; ahora vamos a realizar un ejercicio en el que implementaremos un DataSet con varias tablas, relaciones y además utilizaremos el Cache del servidor ASP para mantener los datos.

En la parte 4 de esta serie de publicaciones hicimos una implementación "económica" para acceder a la información de Provincias, Departamentos y Localidades permitiendo que el usuario seleccione los distintos ítems hasta obtener una Localidad en particular. Digo económica porque utilizamos objetos del tipo SqlDataReader que son más chicos y más rápidos que los DataSet, sin embargo cada vez que un usuario accede a todo el proceso de selección de una localidad se producen innumerables accesos al motor de la base de datos.

Ocurre que la información de Provincias, Departamentos y Localidades rara vez cambia (casi nunca) de manera que esta información es una excelente candidata para ser "cacheada" en RAM evitando de ese modo miles de accesos al servidor de datos. Por supuesto habrá que pensar algún mecanismo para actualizar el cache, lo que dejo para el final de esta publicación.

Por otro lado, lo que vamos a realizar es un objeto complejo que tendrá toda la información necesaria para brindar a cualquier usuario los datos de acuerdo a la selección que va realizando. Esto quiere decir que este objeto complejo tendrá toda la información de Provincias, Departamentos y Localidades con las relaciones necesarias para realizar el filtrado de datos correspondiente.

More...

Ahora vamos a mejorar el acceso a datos del ejercicio realizado en la publicación anterior.

Como dije en la parte 3, no es bueno tener el código de la interfaz de usuario y el código de acceso a los datos en la misma capa, siempre hace falta un poco de lógica o como veremos en este ejercicio una implementación que es más "económica" porque utiliza un DataReader (que es un componente conectado de ADO.NET) que nos permite obtener la información de la base de datos.

En este caso el objetivo es mejorar el acceso a datos de la publicación anterior; no es que la hecho en la publicación anterior esté mal, ocurre que se puede hacer lo mismo con menos recursos y eso se llama eficiencia.

More...

En esta oportunidad vamos a incorporar un poco de comportamiento en la interfaz de usuario y los componentes de ADO.NET.

En la publicación anterior se mostró como se puede utilizar un componente de interfaz de usuario (en ese caso un GridView) y "llenarlo" desde el código asociado con los datos. Obviamente esto nos permite separar dos aspectos importantísimos del desarrollo de software (la presentación y la lógica); por supuesto todavía estamos muy lejos de una arquitectura en capas, pero vamos en camino.

El objetivo de esta publicación es relacionar componentes de la interfaz de usuario, vamos a utilizar la información de Provincias, Departamentos y Localidades (que pueden obtener en la parte 2 de esta serie). En este caso vamos a lograr que el usuario pueda seleccionar de varios DropDownList la información de Provincia, Departamento y Localidad que necesite, obviamente cuando el usuario selecciona una Provincia en el DropDownList de Departamentos solamente pueden aparecer los que correspondan a esa provincia, he ahí la relación entre los componentes de la interfaz de usuario y por supuesto el código que debe soportar ese comportamiento.

More...

Continuamos con las publicaciones sobre ADO.NET.

En la publicación anterior vimos cómo se puede rápidamente construir una página que muestra el contenido completo de una tabla, si queremos podemos mostrar de varias tablas pero no es el caso.

En mi opinión esa no es la forma de trabajar, se puede utilizar para realizar un prototipo de interfaz de usuario pero de NINGUNA MANERA puede realizarse una aplicación de ese modo. Observen que todo está en un único archivo, la interfaz de usuario y el código de acceso a los datos. ¿Qué pasa cuando hace falta lógica de negocios?

Eso nos lleva a introducirnos más en lo que ADO.NET nos facilita, y en esta publicación vamos a ver un poco.

More...