protected void Page_Load(object sender, EventArgs e)
{
      Page.MaintainScrollPositionOnPostBack = true;
}

Esta propiedad funciona correctamente en IExplorer, pero no funciona en todos los navegadores, como por ejemplo, en Chrome. Para que funcione en Chrome, debemos incluir un archivo de exploradores (Browser File) en nuestro proyecto.
Este es un archivo especial que podemos añadir a nuestra solución desde Visual Studio, desde el dialogo de Añadir Nuevo Elemento. El archivo de navegadores tendrá extensión .browser, y se colocará en la carpeta APP_BROWSERS.
Debemos incorporar lo siguiente para que la posición del Scroll se mantenga en los postback de las páginas:

Como podéis observar, el identificador del navegador que hay que utilizar para que funcione con Chrome, es Safari1Plus.
Para averiguar si el navegador sobre el que estamos ejecutando nuestra aplicación soporta por defecto esta propiedad, así como el identificador que debemos utilizar, y el resto de capacidades que tiene, podemos consultar las propiedades del objeto Request.Browser.

System.Web.HttpBrowserCapabilities browser = Request.Browser;

Para más información, MSDN:
Browser Definition File Schema (browsers Element)
How to: Detect Browser Types and Browser Capabilities in ASP.NET Web Pages

Hasta ahora evitábamos esto deshabilitando la validación en la página a través de la propiedad ValidateRequest de la directiva Page:

Pero sería más óptimo deshabilitar la validación sólo para aquellos campos en los que necesitemos que se puedan introducir este tipo de textos. Para ello, deberemos únicamente cambiar el nombre de nuestro control y ponerle dos guiones bajos delante.

Podéis ampliar la información en este post de la Web VARIABLE NOT FOUND:

http://www.variablenotfound.com/2010/09/validacion-de-peticiones-en-aspnet-o.html

Al aplicar estos estilos, al seleccionar una fila desde la web, esta no aparece destacada, si no que se muestra una flecha en el lateral de la fila.

Rejilla fila seleccionada

Si esta rejilla la configuramos para que se muestre la numeración de las filas (en displayLayout, AllowRowNumberingDefault=”Continuous”), la flecha que marca la fila seleccionada deja de aparecer.

Para indicarle al usuario qué fila es la que está seleccionada, tanto si tenemos habilitada como si no la numeración de las filas, debemos indicar en la propiedad SelectTypeRowDefault el tipo de selección que haremos (Single – una única fila ; Extended – Múltiples filas)

[...]

De esta manera, las filas aparecerán destacadas en la rejilla, esté o no habilitada la opción de numeración de filas.

Rejilla Fila destacada

(Infragistics 2008)

Primero, enumeramos las alternativas que nos proporciona Visual Studio 2008 para realizar este precompilado. La precompilación la realizaremos desde la opción de Publicar Sitio Web.

• Permitir que este sitio precompilado se actualice

Habilitado: Los archivos ASPX (.aspx, .ascx, .master…) no se compilaran y se copiaran tal cual, sólo se incluirá en ellos una referencia al ensamblado en el que se encuentra el código correspondiente a su archivo CS asociado.

Deshabilitado: Los archivos ASPX se compilan y por lo tanto, no se puede ni ver ni modificar su código en la web una vez ésta está generada.

• Utilizar nomenclatura fija y ensamblados de una sola página

Habilitado: Se genera un ensamblado por cada una de las páginas, por lo que se debe limitar el número de páginas del proyecto. El nombre de cada ensamblado se corresponde con la ruta virtual de la página, y en caso de que esta sea excesivamente larga, con un código HASH. El nombre de los ensamblados siempre es el mismo.

Deshabilitado: Se genera un ensamblado por cada lote de archivos (en función de la carpeta en que esté, etc.). El nombre de los ensamblados de lote varía cada vez que se realiza una publicación.

• Habilitar nombre seguro en los ensamblados precompilados

Habilitado: Permite que se especifique un archivo de claves para generar los nombres de los ensamblados y poder asegurar que no se han alterado.

Deshabilitado: Los nombres se general de forma normal.

Ahora, si hemos utilizado el namespace ASP, al ir a realizar la publicación de un sitio Web, debemos tener en cuenta lo siguiente:  el namespace ASP se asigna por defecto a las clases vinculadas a los archivos de interfaz (ascx, aspx, etc.)  Si realizamos alguna llamada en nuestro código a este namespace en la publicación, si marcamos la opción Permitir que este sitio precompilado se actualice, se producirá un error de este estilo:

El tipo o el nombre del espacio de nombres ‘nombreControl’ no existe en el espacio de nombres ‘ASP’ (¿falta una referencia de ensamblado?)

Para solucionarlo, tenemos las siguientes opciones:

• Desmarcar la opción Permitir que este sitio precompilado se actualice.

• Utilizar un ensamblado propio.

Para utilizar un namespace propio en lugar del namespace ASP, deberemos indicar en el archivo control.ascx el nombre del nuevo namespace, forzando de esta manera que se utilice nuestro namespace en lugar del namespace por defecto:

Por otro lado, en el archivo que contiene la clase asociada, control.ascx.cs, indicaremos el namespace:

namespace Proyecto.NameSpacePropio
{
public partial class control : System.Web.UI.UserControl
{...

Y por último, en el archivo donde hacíamos referencia al namespace ASP, incluiremos una referencia al nuevo ensamblado:

using Proyecto.NameSpacePropio;

Para evitar que esto ocurra, debemos hacer uso de la propiedad wmode, con el valor transparent. Esta propiedad nos permitirá ubicar el flash por detrás del objeto que necesitemos superponer.

<object width=”730″ height=”65″>

<param name=”movie” value=’banner.swf‘></param>
<param name=”allowFullScreen” value=”false”></param>
<param name=”allowscriptaccess” value=”always”></param>
<param name=”wmode” value=”transparent”></param>
<embed src=’banner.swf‘ type=”application/x-shockwave-flash”
allowscriptaccess=”always” allowfullscreen=”false”
width=”730″ height=”65″
wmode=”transparent”></embed>

</object>

Para ello, desde JavaScript, podemos obtener el ancho y el alto de la pantalla que el usuario está utilizando  (no el de la ventana del navegador, si no el de la pantalla). Lo haremos de la siguiente forma:

var alto = screen.height;
var ancho = screen.width;

Y para que funcione en Chrome y en Firefox, podremos lo siguiente:

var ancho = screen.width + "px";

Cuando trabajamos con aplicaciones Web, el archivo WEB.CONFIG contiene la configuración del proyecto, y esta configuración está dividida en varios bloques.  La división del WEB.CONFIG en varios archivos nos permite aislar estos bloques para facilitar su localización y actualización.

Además, algunos de estos bloques son diferentes si estamos en el entorno de desarrollo, en el entorno de pre-producción, o en el entorno de producción, por lo que aislando las partes que sean propias de los diferentes entornos con los que trabajemos, facilitaremos las puestas en producción.

Para dividir el web.config en varios archivos debemos de utilizar la propiedad configSource, e indicar el nombre del archivo en el que está el bloque que hemos aislado. Por ejemplo, si queremos aislar el bloque de las cadenas de conexión, haremos lo siguiente:

ARCHIVO WEB.CONFIG

  [.....]

[.....]

ARCHIVO CONEXION.CONFIG

Si realizamos esta división, debemos tener en cuenta lo siguiente:

Cuando en un proyecto, que se está ejecutando, se realiza una modificación sobre el WEB.CONFIG, la aplicación se reinicia. Esto se produce porque hay determinadas partes del WEB.CONFIG que requieren que se fuerce un reinicio de la aplicación  si se realizan cambios sobre ellas. Esto viene establecido, a nivel de bloque,  en el MACHINE.CONFIG (con la variable restartOnExternalChanges a false para aquellos bloques que no requieren reinicio).

Si aislamos un bloque que no requiera que la aplicación se reinicie, por ejemplo, appSettings, conseguiremos que los cambios que se produzcan sobre este archivo no fuercen un reinicio de la aplicación.

A continuación, mostraremos unos ejemplos de código fuente sencillo para permitir el acceso a una base de datos SQL Server.

Deberíamos utilizar las siguientes referencias using:

using Microsoft.Practices.EnterpriseLibrary.Data;
using System.Data;

Los ejemplos son los siguientes:

/// Ejecución de consulta devolviendo un dataset.
try
{
   string consulta = "SELECT * col1, col2 FROM TABLA_PRUEBA";
   Database db = DatabaseFactory.CreateDatabase();
   System.Data.Common.DbCommand cmd = db.GetSqlStringCommand(consulta);
   DataSet ds = db.ExecuteDataSet(cmd);           

   // Ejemplo de recorrido.
   DataTable DT = ds.Tables[0];
   int j = DT.Rows.Count;
   for (int i = 0; i < j; i++)
   {
         ListaCualquiera.Add(DT.Rows[i]["DS_Tratamiento"].ToString());
   }
 }
 catch (Exception ex)
 {
     bool reThrow = ExceptionPolicy.HandleException(ex, "BaseDatos");
     if (reThrow) throw;
 }

/// Ejecución de consulta obteniendo escalar.
try
{
    string sentencia = "select max(col1) from TABLA_PRUEBA";
    Database db = DatabaseFactory.CreateDatabase();
    System.Data.Common.DbCommand cmd = db.GetSqlStringCommand(sentencia);
    int cd = (int) db.ExecuteScalar(cmd);
}
catch (Exception ex)
{
    bool reThrow = ExceptionPolicy.HandleException(ex, "BaseDatos");
    if (reThrow) throw;
}

/// Ejecución de insert, utiliza parámetros.
try
{
     String valor = "Valor2";
     sentencia = "insert into TABLA_PRUEBA values ('Valor1', @valor)";
     cmd = db.GetSqlStringCommand(sentencia);

     //Asociar tipos y variables al comando
     db.AddInParameter(cmd, "valor", DbType.String, valor);

     //Ejecutamos el comando
     int resultado = db.ExecuteNonQuery(cmd);
}
catch (Exception ex)
{
     bool reThrow = ExceptionPolicy.HandleException(ex, "BaseDatos");
     if (reThrow) throw;
}

/// Ejecución delete.
try
{
    Database db = DatabaseFactory.CreateDatabase();
    String sentencia = "delete from TABLA_PRUEBA where DCol1 = 'valor5'";
    System.Data.Common.DbCommand cmd = db.GetSqlStringCommand(sentencia);

    int resultado = db.ExecuteNonQuery(cmd);
}
catch (Exception ex)
{
    bool reThrow = ExceptionPolicy.HandleException(ex, "BaseDatos");
    if (reThrow) throw;
}

Para que estos ejemplos funcionen correctamente se debe configurar en el fichero de configuración de la aplicación la cadena de conexión y establecerla como “por defecto”.

Además, los ejemplos utilizan el bloque de aplicación de excepciones de Enterprise Library.

Unity Application Block permite a los desarrolladores realizar ingeniería del software basada en componentes. Las aplicaciones modernas están formadas por objetos de negocio particulares y por componentes que realizan tareas genéricas o específicas dentro de la aplicación. Además, están formadas por componentes individuales ejecutados de forma transversal como traceo, autenticación, autorización, cacheo y manejo de excepciones.

Una de las claves para conseguir desarrollar con éxito este tipo de aplicaciones es conseguir un diseño de código desacoplado o lo menos acoplado posible. Con un diseño y desarrollo software desacoplado conseguiremos aplicaciones más flexibles y fáciles de mantener.

Existen diferentes técnicas para permitir el diseño y desarrollo de software desacoplado. En este artículo nos centraremos en los patrones de diseño Inversión del Control (IoC – Inversion of Control) e Inyección por Dependencia (DI – Dependency Injection) pero existen otras como el patrón de diseño Intercepción (Interception pattern).

El patrón Inversion of Control (IoC) es un patrón de diseño genérico que describe técnicas para soportar arquitecturas con la capacidad de intercambio de software (plug-in) donde los objetos pueden buscar instancias de otros objetos que éstos necesitan.

El patrón de diseño Dependency Injection (DI) es un caso especial del patrón IoC y es una técnica de programación basada en interfaces consistente en alterar el comportamiento de la clase sin cambiar internamente ésta. El desarrollador genera código contra un interface para la clase y usa un contenedor que inyecta la instancia de la clase, basándose en el interface o el tipo del objeto. Las técnicas para inyectar instancias son: inyección por interface, inyección por constructor, inyección por propiedad (setter) e inyección por método.

Realizar con éxito un proyecto de desarrollo software es una empresa complicada. presupuestos limitados, diferentes tecnologías, resistencia al cambio, necesidades mal definidas y cambiantes, carencia de profesionales cualificados, son algunos de los problemas con los que se encuentra un equipo de ingenieros del software cuando pretenden ofrecer una solución que resuelva o al menos minimice el impacto de estos y otros problemas posibles.

Con asiduidad nos hemos enfrentado ante casos en los que se plantea una funcionalidad transversal utilizada desde diferentes puntos del sistema y que además puede cambiar y ser ampliada con frecuencia.

Ante estos casos no sólo es deseable disponer de un buen diseño orientado a objetos que nos permita poder actuar sobre la funcionalidad cambiante y poder ampliar a nuevos casos sino que también es interesante la actualización “en caliente” de estos cambios. Sería deseable que cuando nuestro sistema esté en producción, ante un cambio de funcionalidad o extensión de ésta, no tuviéramos que abrir nuestro compilador con el proyecto entero, codificar los cambios, parar el aplicativo en producción (y las personas que trabajan sobre él), hacer el cambio y volver a levantar el entorno.

Una solución deseable consistiría en implementar el cambio o la nueva funcionalidad en una DLL, implantar esta DLL en producción y configurar la creación de los objetos que disparan esa funcionalidad desde un fichero XML.

El caso que nos ocupa trata de resolver un problema (simplificado) de gestión de alertas en un proyecto software. Podríamos decir que vamos a diseñar una solución orientada a objetos que nos permita definir una alerta con la capacidad de ejecutarse en un día, hora y minuto concreto. En la solución final cada alerta tendrá una implementación concreta. Además, existirá un planificador que será el encargado de ejecutar las alertas en el momento adecuado, por ejemplo, ejecutándose desde un servicio windows.

Para la implementación de este caso práctico simplificado utilizaremos implementación de DLLs, que trata de concentrar en un fichero funcionalidades concretas, Microsoft Unity Application Block 1.2, que nos ofrece un contenedor para la inyección de código mediante constructor (parametrós con arrays), y configuración de inyección mediante fichero XML.

Toda la funcionalidad la vamos a implementar en una DLL llamada Solusoft.DC. En esta DLL vamos a tener tanto la funcionalidad de las alertas como la del planificador. Realmente no debería ser así y deberían estar en dos DLLs separadas para dividir aún más el código.

A continuación se muestra una implementación de las Alertas utilizando un interfaz y una jerarquía de clases. Nos aprovecharemos del método ejecutar() para lanzar la tarea cuando se cumplan las condiciones de estar en el día, hora, minuto correctos. Nótese que los tipos devueltos por el interfaz son de tipo string por comodidad a la hora de hacer la inyección de código.

// namespace Solusoft.DC.Alertas.Interfaces
public interface IAlertable
{
       void Ejecutar();
       System.String DiaEjecucion();
       System.String HoraEjecucion();
       System.String MinutoEjecucion();
}

// namespace Solusoft.DC.Alertas
public abstract class Alerta
{
    protected System.String dia;
    protected System.String hora;
    protected System.String minuto;

    public Alerta(System.String dia, System.String hora, System.String minuto)
    {
        this.dia = dia;
        this.hora = hora;
        this.minuto = minuto;
    }
}

public class AlertaX : Alerta , Interfaces.IAlertable
{
    public AlertaX(System.String dia, System.String hora, System.String minuto)
    : base(dia, hora, minuto)
    {
        ;
    }

    public void Ejecutar()
    {
        Console.WriteLine("Se ha ejecutado la alerta X");
    }

    public System.String DiaEjecucion()
    {
        return this.dia;
    }

    public System.String HoraEjecucion()
    {
        return this.hora;
    }

    public System.String MinutoEjecucion()
    {
        return this.minuto;
    }
}

public class AlertaY : Alerta, Interfaces.IAlertable
{

    public AlertaY(System.String dia, System.String hora, System.String minuto)
                           : base(dia, hora, minuto)
    {
        ;
    }

    public void Ejecutar()
    {
        Console.WriteLine("Se ha ejecutado la alerta Y");
    }

    public System.String DiaEjecucion()
    {
        return this.dia;
    }

    public System.String HoraEjecucion()
    {
        return this.hora;
    }

    public System.String MinutoEjecucion()
    {
        return this.minuto;
    }
}

El planificador es algo más sencillo pero tiene una característica importante y es la de incorporar en el constructor un array de referencias a objetos que implementen el interfaz IAlertable. Esto nos servirá para poder indicarle al contenedor cuáles son las instancias concretas de alertas que se deben planificar.

// namespace Solusoft.DC.Alertas.Interfaces
public interface IPlanificable
{
        void Ejecutar();
}

// namespace Solusoft.DC.Alertas
public class Planificador : Interfaces.IPlanificable
{
    //Array de alertas
    private Interfaces.IAlertable [] Alertas;

    public Planificador(Interfaces.IAlertable [] alertas)
    {
        this.Alertas = alertas;
    }

    public void Ejecutar()
    {
        Console.WriteLine("Se ha ejecutado el planificador");
        for (int i = 0; i < Alertas.Length; i++)
        {   // Comprobar si ejecutar
            Alertas[i].Ejecutar();
        }
     }

     public void quienSoy()
     {
          Console.WriteLine("Soy el planificador");
     }
}

Con esta implementación basada en interfaces y herencia estamos en predisposición de tener un software lo más desacoplado posible. Esto unido a la utilización de Microsoft Unity Application Block 1.2 mediante configuración por diseño nos va a permitir indicar incluso en tiempo de ejecución cuáles son las intancias concretas de las alertas que el planificador debe controlar para su ejecución.

A continuación, se muestra el fichero de configuración completo para este ejemplo:

La configuración de la sección Unity para este ejemplo incorpora los siguientes elementos:

Una vez que tenemos la estructura de clases/interfaces y el contenedor configurado tan solo nos queda saber utilizarlo desde el código de nuestra aplicación. El ejemplo es el siguiente:

IUnityContainer container = new UnityContainer();
var section =
           (UnityConfigurationSection)ConfigurationManager.GetSection("unity");
           section.Containers.Default.Configure(container);

// Alerta alerta = container.Resolve<Alerta>();

IAlertable alertaX = container.Resolve<IAlertable>("AlertaX");
Console.WriteLine(alertaX.MinutoEjecucion());

IAlertable alertaY = container.Resolve<IAlertable>("AlertaY");
Console.WriteLine(alertaY.MinutoEjecucion());

string objetoPlanificador = ConfigurationSettings.AppSettings[CFG_PLANIFICADOR] as string;

IPlanificable planificador = container.Resolve<IPlanificable>(objetoPlanificador);

planificador.Ejecutar();

Console.ReadLine();  

La utilización del contedor una vez configurado es muy sencilla. En primer lugar hay que decirle a nuestro aplicativo que se prepare para utilizar un contenedor y que lo haga cargando la configuración desde la sección Unity. En este ejemplo, el fichero de configuración es el App.Config de una aplicación en modo consola pero podría ser cualquier otro (consultar documentación para cargar la configuración de otro archivo).

Mediante llamadas container.Resolve conseguimos pedir al contenedor los objetos que hayan sido configurados previamente en diseño. Con esto hacemos la llamada a: IPlanificable planificador = container.Resolve_IPlanificable_(objetoPlanificador); para pedirle el objeto concreto que esté capacitado para planificar. Nótese como en este caso ya estará configurado con las alertas precisas a ejecutar y una llamada simple a planificador.Ejecutar(); permitirá su ejecución.

Un interbloqueo es una situación en la que dos transacciones están esperando para utilizar un recurso bloqueado.

SQL Server detecta automáticamente una situación de interbloqueo mediante un método denominado detección de cadenas circulares de bloqueos. Cuando un interbloqueo ocurre, SQL Server termina el proceso que haya generado la cadena circular de bloqueos.

Los interbloqueos no se producen únicamente a nivel de página de datos, de hecho, muchos interbloqueos se producen a nivel de página de índice.

Minimización de la contienda de bloqueo

Para minimizar el número de interbloqueos se deben considerar las siguientes recomendaciones:

• Las transacciones deben ser cortas y afectar al menor número de datos posibles.
• Se debe dar preferencia a la utilización de alguna de las técnicas del enfoque optimista.
• Puede resultar conveniente establecer una prioridad baja (“set deadlockpriority low”) para las consultas DSS y una alta (“set deadlockpriority normal”) para las consultas OLTP.
• El orden de acceso a las tablas debe ser siempre el mismo en las distintas partes del código.
• Se debe minimizar el uso de “holdlock”. Por ejemplo, el código:

declare @SEQNO int

begin transaction
   select @SEQNO = isnull(SEQ#,0)+1
   from SEQUENCE with holdlock
   /*
      En ausencia de holdlock el bloqueo compartido sería liberado
      por lo que si otra transacción concurrente ejecutara el mismo
      comando obtendría el mismo número de secuencia
   */
   update SEQUENCE
   set SEQ# = @SEQNO
   /*
      Ahora puede hacerse lo que se desee con este número de
      secuencia
   */
   …
commit transaction
podría reescribirse como:
declare @SEQNO int

begin transaction
   update SEQUENCE
   set @SEQNO = isnull(SEQ#,0)+1
   from SEQUENCE
   select @SEQNO
   …
commit transaction

De esta forma se obtiene directamente el bloqueo de actualización eliminándose la posibilidad de que se produzca un interbloqueo.

• SQL Server proporciona un soporte completo para establecer la granularidad del bloqueo a nivel de fila. Una granuralidad del bloqueo más fina proporciona una mejor concurrencia, minimizando el número de interbloqueos, aunque aumenta el trabajo del servidor para gestionar los bloqueos.
• Se debe evitar las interactuaciones con el usuario dentro de una transacción con el fin de minimizar el tiempo de duración de la misma.
• Se debe seleccionar cuidadosamente el nivel de aislamiento de una transacción, ya que el nivel de aislamiento determina el tipo de bloqueo. Es posible reducir el número de interbloqueos bajando el nivel de aislamiento.

Gestión de interbloqueos

SQL Server devuelve el error 1205 al cliente cuando termina un proceso como resultado de un interbloqueo.

Leer más sobre:

1. Gestión de transacciones en SQL Server (1/7)
2. Gestión de bloqueos en SQL Server (2/7)
3. Enfoques de control de transacciones en SQL Server (3/7)
4. Enfoque optimista de gestión de transacciones en SQL Server (4/7)
5. Enfoque pesimista de gestión de transacciones en SQL Server (5/7)
6. Enfoque mixto de gestión de transacciones en SQL Server (6/7)
7. Interbloqueos en SQL Server (7/7)