Lo que en principio se nos antoja como una buena práctica, en la mayoría de las ocasiones, debido a una utilización mal estructurada del fichero de configuración, se convierte en una lista incontrolable y sin organización alguna de entradas en el nodo appSettings.

Para evitar esto existe una solución alternativa, más elegante, más clara y, más optima. Las clases ConfigurationSection, ConfigurationElement y ConfigurationElementCollection permiten definir secciones, elementos y colecciones de elementos en el fichero de configuración y utilizarlas como cualquier otro objeto en nuestro aplicativo.

Vamos a definir una pequeña sección en el fichero de configuración y comentamos un poquito cómo realizarla.

La clase EjemploData heredará de ConfigurationElement y tendrá dos propiedades Name y PropiedadBooleana, de tipo string y bool respectivamente. Las propiedades de ambas deberán tener el atributo ConfigurationProperty con el nombre que tomará en el fichero de configuración, su valor por defecto (si queremos especificarlo) y si es obligatoria.

public class EjemploData : ConfigurationElement
    {
        #region Public Properties
 
        private const string NamePropertyName = "name";
 
        [ConfigurationProperty(NamePropertyName, IsRequired = true)]
        public string Name
        {
            get { return this[NamePropertyName].ToString(); }
            set { this[NamePropertyName] = value; }
        }
 
        private const string PropiedadBooleanaPropertyName = "propiedadBooleana";
        [ConfigurationProperty(PropiedadBooleanaPropertyName, DefaultValue = "true", IsRequired = false)]
        public bool PropiedadBooleana
        {
            get { return (bool)this[PropiedadBooleanaPropertyName]; }
            set { this[PropiedadBooleanaPropertyName] = value; }
        }
 
        #endregion
    }

Crearemos una clase EjemploDataCollection que herede de ConfigurationElementCollection, tal y como se muestra, no requiere mucha explicación

public class EjemploDataCollection : ConfigurationElementCollection
{
#region ConfigurationElementCollection Members
 
protected override ConfigurationElement CreateNewElement()
{
return new EjemploData();
}
 
protected override object GetElementKey(ConfigurationElement element)
{
return ((EjemploData)element).Name;
}
 
public EjemploData this[int index]
{
get
{
return (EjemploData)BaseGet(index);
}
set
{
if (BaseGet(index) != null)
{
BaseRemoveAt(index);
}
BaseAdd(index, value);
}
}
 
#endregion
}

Finalmente, crearemos la clase que nos permita manejar este tipo de objetos. Esta clase debe heredar de ConfigurationSection, la cual nos servirá para marcar el ámbito en el cual obtendremos los valores dentro del fichero de configuración. Debe tener:

• Una constante pública que nos indique cómo llegar a la sección adecuada del fichero de configuración.
• Constantes privadas que nos marquen cómo se llamarán los atributos.
• Nodos hijos que podremos definir en el fichero de configuración
• Sus respectivas propiedades públicas que nos permitirán utilizarlas en cualquier parte de nuestro aplicativo.

En nuestro ejemplo definiremos la seccion como “oxxigeno/ejemploSettings”, lo que significa que en el fichero de configuración tendremos que definir un nodo oxxigeno y dentro uno ejemploSettings.

Queremos que exista una atributo en el nodo ejemploSettings, para lo cual crearemos una constante privada que nos diga como debe llamarse, “nuevaPropiedad”, y una propiedad pública que nos permita recuperarlo del fichero de configuración y utilizarlo en el aplicativo. Para ello crearemos una propiedad normal que nos devolverá un objeto de tipo string y le establecemos un atributo a la propiedad de tipo ConfigurationProperty, que indique cómo se va a llamar ese atributo en el fichero de configuración y si es obligatorio o no que exista.

Además nos interesa que bajo el nodo ejemploSettings exista una colección de nodos del mismo tipo (en nuestro caso EjemploData). Para ello procederemos igual que para la propiedad actual, pero definiremos su salida como EjemploDataCollection, y le agregaremos el atributo ConfigurationCollection pasándole como parámetro el tipo de objetos que se coleccionarán.

public sealed class EjemploSettings : ConfigurationSection
{
 
public const string SectionName = "oxxigeno/ejemploSettings";
 
#region Public Properties
 
private const string NuevaPropiedadPropertyName = "nuevaPropiedad";
 
[ConfigurationProperty(NuevaPropiedadPropertyName, IsRequired = true)]
public string NuevaPropiedad
{
get { return this[NuevaPropiedadPropertyName].ToString(); }
set { this[NuevaPropiedadPropertyName] = value; }
}
 
private const string ColeccionDeEjemploPropertyName = "coleccionDeEjemplo";
 
[ConfigurationProperty(ColeccionDeEjemploPropertyName, IsRequired = true, IsDefaultCollection = true)]
[ConfigurationCollection(typeof(EjemploData))]
public EjemploDataCollection ColeccionDeEjemplo
{
get { return (EjemploDataCollection)this[ColeccionDeEjemploPropertyName]; }
}
 
#endregion
}

Así pues, para cargar datos en el fichero de configuración, debemos cargar la clase controladora (EjemploSettings) y montar el árbol de nodos que hemos definido en las clases.

Dentro del nodo configurationSections debemos crear un nodo SectionGroup como se muestra, y dentro un nodo section. Pueden existir múltiples nodos sectionGroup pero no con el mismo nombre. Cada nodo sectionGroup puede tener en su interior multiples nodos section.

   <sectionGroup name="oxxigeno">
      <section name="ejemploSettings" type="Oxxigeno.Ejemplo.Configuration.EjemploSettings, Oxxigeno.Ejemplo, Version=1.0.0.0, Culture=neutral, PublicKeyToken=96df930e30970c00">
   </sectionGroup>

Y despues creamos el árbol de nodos tal como lo hemos definido, quedaría algo así:

   <oxxigeno> 
      <ejemploSettings nuevaPropiedad="valorDeLaPropiedad"&gt; 
         <coleccionDeEjemplo&gt; <clear/&gt;
            <add name="nombreDeLaEntrada1" propiedadBooleana="false" /&gt; 
            <add name="nombreDeLaEntrada2" propiedadBooleana="true" /&gt; 
         </coleccionDeEjemplo>
      </ejemploSettings>
   </oxxigeno&gt;

La forma de recuperar estos valores sería la siguiente:

EjemploSettings ejemploSettings = ConfigurationManager.GetSection(EjemploSettings.SectionName) as EjemploSettings;
string nuevaPropiedad = ejemploSettings.NuevaPropiedad;
foreach (EjemploData obj in ejemploSettings.ColeccionDeEjemplo)
{
string nombre = obj.Name;
bool propiedadBooleana = obj.PropiedadBooleana;
}

Considero que este método de utilización del fichero de configuración es:

• Más útil: Los valores se encuentran parseados al tipo necesario, no se obtienen unicamente valores de tipo string como pasa si utilizamos AppSettings, lo cual facilita el trabajo del desarrollador.
• Más estructurado: Los valores dentro del fichero de configuración son facilmente localizables y, por lo tanto, modificables.

Esta tecnología integra en una única metodología de programación las hasta ahora incompatibles COM+ (Serviced Components), .NET Remoting y Servicios Web. Para ello, un servicio WCF debe definir una serie de puntos de acceso (denominados EndPoints) que representan una puerta de entrada al servicio publicado, permitiendo así que un mismo servicio sea consultado mediante distintos tipos de comunicación.
Los EndPoints deben presentar:

• Dirección: representada por la clase EndPointAddress, indica dónde está la aplicación
• Enlace: representada por la clase Binding, indica cómo se puede accesar esa aplicación: Protocolo del transporte, Codificación y Seguridad.
• Contrato: representada por una clase con atributos de tipo ServiceContractAttribute, se trata de una definición de los datos que van a ser comunicados por el aplicativo.

WCF utiliza mensajes SOAP para la comunicación de estos datos, siguiendo así un estándar de comunicación. Sin embargo, cuando se realiza una comunicación entre dos procesos WCF se optimiza esta comunicación, aplicando una codificación en formato binario para los mensajes SOAP. De esto podemos olvidarnos totalmente, ya que al fin podemos crear un servicio sin preocuparnos de cómo ni quién va a acceder a él.

Vayamos con un ejemplo y veamos si es realmente lo que nos venden. Creamos una interfaz y una entidad que serán las que utilizaremos para dar vida al servicio.

[ServiceContract]
    public interface IExample
    {
        [OperationContract]
        string GetData(int value);
 
        [OperationContract]
        ExampleType GetDataUsingDataContract(ExampleType composite);
 
        [OperationContract]
        string[] GetNames();
    }
 
    [DataContract]
    public class ExampleType
    {
        bool _delete = false;
        string _name = "Name";
 
        [DataMember]
        public bool Delete
        {
            get { return _delete; }
            set { _delete = value; }
        }
 
        [DataMember]
        public string Name
        {
            get { return _name; }
            set { _name = value; }
        }
    }

Los atributos DataContract y OperationContract son, para entendernos, los atributos que sustituyen a WebService y WebMethod. Mientras que los atributos DataContract y DataMember son los atributos que servirán para serializar las entidades que se publicarán a través del servicio.

Ahora, una vez creada la interfaz que publicará el servicio y la entidad, procedemos a implementar la funcionalidad del servicio.

public class ExampleService : IExample
    {
        public string GetData(int value)
        {
            return string.Format("You entered: {0}", value);
        }
 
        public ExampleType GetDataUsingDataContract(ExampleType composite)
        {
            if (!composite.Delete)
            {
                composite.Name += " y Apellido";
            }
            return composite;
        }
 
        public string[] GetNames()
        {
            List<string> lista = new List<string>();
            for (int i = 0; i < 5; i++)
            {
                lista.Add("nombre" + i.ToString());
            }
            return lista.ToArray();
        }
    }

Con esto ya tenemos el código necesario para crear un servicio con WCF. Nos falta darle posibles puntos de entrada, para poder publicarlo. Lo hacemos a través del web.config del servicio.

<system.serviceModel>
    <services>
      <service name="Namespace.ExampleService" behaviorConfiguration="Namespace.ExampleServiceBehavior">
        <!-- Service Endpoints -->
        <endpoint address="" binding="wsHttpBinding" contract="Namespace.IExample">
          <identity>
            <dns value="localhost"/>
          </identity>
        </endpoint>
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
      </service>
    </services>
    <behaviors>
      <serviceBehaviors>
        <behavior name="Namespace.ExampleServiceBehavior">
          <serviceMetadata httpGetEnabled="true"/>
          <serviceDebug includeExceptionDetailInFaults="false"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>

Voy a intentar explicarlo de forma esquemática. Dentro de la etiqueta “services” creamos cada uno de los servicios que queramos publicar, mientras que dentro de la etiqueta “behaviors” definiremos diferentes comportamientos que podrán utilizarse en los servicios publicados.

Pero volvamos a la etiqueta “services”. Dentro de ella crearemos tantas etiquetas “service” como servicios queramos publicar. Cada una se define mediante nombre y comportamiento (“name” y “behaviorConfiguration”). Además debemos definir una serie de puntos de entrada (“endpoint”) con las propiedades “address”, “binding” y “contract”, y un nodo interno de tipo “identity” (como se ve en el código). Vamos con ellos:

• Etiqueta Service:
  • Address: Especificamos la URI, que puede estar como cadena vacía.
  • Binding: Especificamos el binding a utilizar, lo cual define el tipo de transporte, la seguridad y el encoding utilizado. Podemos utilizar un binding definido por nosotros.
  • Contract: Especifica la interfaz que define se publicará con el servicio.
• Etiqueta Behavior:
  • Name: Nombre del behavior, único en el web.config
  • ServiceMetadata: Especifica la publicación de los metadatos del servicio y de la información asociada.
  • ServiceDebug: Especifica las características de la información de depuración y de la ayuda para un servicio de la WCF.

Para una descripción más detallada podemos recurrir a la siguiente url de Microsoft: http://msdn.microsoft.com/en-us/library/ms733932.aspx

Respecto al cliente, su uso es tan sencillo como agregar la referencia al servicio a la solucion e invocarlo desde el código.

Al agregar la referencia al servicio podemos ver que el web.config ha sido modificado, añadiendo la configuracion necesaria para accesar dicho servicio. Veamos qué ha añadido:

<system.serviceModel>
        <bindings>
            <wsHttpBinding>
                <binding name="WSHttpBinding_IExample" closeTimeout="00:01:00"
                    openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
                    bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard"
                    maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
                    messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true"
                    allowCookies="false">
                    <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
                        maxBytesPerRead="4096" maxNameTableCharCount="16384" />
                    <reliableSession ordered="true" inactivityTimeout="00:10:00"
                        enabled="false" />
                    <security mode="Message">
                        <transport clientCredentialType="Windows" proxyCredentialType="None"
                            realm="" />
                        <message clientCredentialType="Windows" negotiateServiceCredential="true"
                            algorithmSuite="Default" establishSecurityContext="true" />
                    </security>
                </binding>
            </wsHttpBinding>
        </bindings>
        <client>
            <endpoint address="http://localhost:3153/ExampleService.svc"
                binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IExample"
                contract="ExampleServiceReference.IExample" name="WSHttpBinding_IExample">
                <identity>
                    <dns value="localhost" />
                </identity>
            </endpoint>
        </client>
    </system.serviceModel>

Él solo ha creado todo el arbol de etiquetas de configuracion necesario para acceder al servicio mediante el endpoint que deseemos. Si nos fijamos en la etiqueta “endpoint” dentro de “client” podemos ver cómo ha agregado la direccion del servicio, el tipo de binding, la configuracion del mismo, la interfaz que presenta y el nombre (que es lo que utilizaremos para crear el objeto client en código):

ExampleClient clientDefault = new ExampleClient("WSHttpBinding_IExample");
            string[] namesDefault = clientDefault.GetNames();

Vamos a crear otro endpoint en el web.config del servicio y vamos a refrescar la referencia en el cliente para ver cómo cambia el web.config, añadiendo el nuevo endpoint y veremos cómo referenciarlo. Agregamos dos endpoints:

 <endpoint address="Soap11" contract="Namespace.IExample" binding="basicHttpBinding"/>
            <endpoint address="Soap12" contract="Namespace.IExample" binding="wsHttpBinding"/>

Y refrescamos la referencia al servicio en el cliente. Miramos el web.config y descubrimos que tenemos nuevas formas de acceder al servicio:

 <endpoint address="http://localhost:3153/ExampleService.svc/Soap11"
                binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IExample"
                contract="ExampleServiceReference.IExample" name="BasicHttpBinding_IExample" />
            <endpoint address="http://localhost:3153/ExampleService.svc/Soap12"
                binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IExample"
                contract="ExampleServiceReference.IExample" name="WSHttpBinding_IExample1">
                <identity>
                    <userPrincipalName value="ivinuales@oxxigeno-networks.spain" />
                </identity>
            </endpoint>

Además, nos ha creado una nueva entrada dentro de bindings:

<basicHttpBinding>
                <binding name="BasicHttpBinding_IExample" closeTimeout="00:01:00"
                    openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
                    allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
                    maxBufferSize="65536" maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
                    messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
                    useDefaultWebProxy="true">
                    <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
                        maxBytesPerRead="4096" maxNameTableCharCount="16384" />
                    <security mode="None">
                        <transport clientCredentialType="None" proxyCredentialType="None"
                            realm="" />
                        <message clientCredentialType="UserName" algorithmSuite="Default" />
                    </security>
                </binding>
            </basicHttpBinding>

De tal forma que ahora en el código fuente podemos instanciarlo de 3 formas distintas:

            ExampleClient clientDefault = new ExampleClient("WSHttpBinding_IExample");
            string[] namesDefault = clientDefault.GetNames();
 
            ExampleClient clientSOAP11 = new ExampleClient("BasicHttpBinding_IExample");
            string[] namesSOAP11 = clientSOAP11.GetNames();
 
            ExampleClient clientSOAP12 = new ExampleClient("WSHttpBinding_IExample1");
            string[] namesSOAP12 = clientSOAP12.GetNames();

Lo primero que debemos hacer es identificar esa entidad y crear una clase para guardar esos datos. Después debemos tener algun mecanismo para rellenar esta clase con los valores de cada una de las filas (cada fila del fichero supondrá un objeto de ésta clase).

Pongamos un ejemplo.  Supongamos un fichero csv como el siguiente:

Edad; Nombre; Apellido
15; Pepito; Perez
57; Ernesto; Román
RowCount = 2

En ocasiones los csv traen una cabecera y/o un pie de fichero y en otras no, por lo que no podemos tratar de procesarlas siempre.

Vamos a empezar creando una clase entidad como la siguiente:

public class Edades
{
    private int _edad;
    private string _nombre;
    private string _apellido;
    public int Edad
    {
        get { return _edad; }
        set { _edad = value; }
    }
    public string Nombre
    {
        get { return _nombre; }
        set { _nombre = value; }
    }
    public string Apellido
    {
        get { return _apellido; }
        set { _apellido = value; }
    }
}

Como vemos, se trata de una clase tonta con 3 atributos y sus 3 correspondientes propiedades publicas. En este ejemplo sería muy sencillo por cada fila crearnos un objeto y asignar a Edad el primer valor de la fila, a Nombre la segunda y a Apellido la tercera, serían 3 simples líneas. Sin embargo, a medida que el csv (y la clase) contengan más campos esto se haría más complejo, y sería muy complejo de modificar si algún día deciden introducir un campo nuevo en mitad del csv.

Claro este punto, debemos tener alguna forma de relacionar cada propiedad de la clase con la posicion que ocupa ese valor en el csv. Para esto tenemos dos opciones:

• Si la posición de cada campo es susceptible de ser modificada periódicamente deberíamos determinar esta relación en el web.config (si es una aplicación web) o en app.config (si es una aplicación de escritorio)
• Si la posición de cada campo no es susceptible de ser modificada, es preferible agregar atributos a la clase que indique donde debemos buscar el valor de cada propiedad.

Voy a centrarme en este segundo supuesto, el primero posiblemente lo trataremos en otro artículo. Vamos a generar una clase que herede de Attribute para poder indicar en la clase que acabamos de crear donde buscaremos cada valor.

public class CSVFieldAttribute : Attribute
{
    private int _order;
    public int Order
    {
        get { return _order; }
        set { _order = value; }
    }
    public CSVFieldAttribute(int order)
    {
        _order = order;
    }
}

Ahora modificamos la clase de la entidad, añadiéndole a cada propiedad un atributo indicando su posición en el csv. La clase quedaría como sigue:

public class Edades
{
    private int _edad;
    private string _nombre;
    private string _apellido;
 
    [CSVField(0)]
    public int Edad
    {
        get { return _edad; }
        set { _edad = value; }
    }
    [CSVField(1)]
    public string Nombre
    {
        get { return _nombre; }
        set { _nombre = value; }
    }
    [CSVField(2)]
    public string Apellido
    {
        get { return _apellido; }
        set { _apellido = value; }
    }
}

En este punto podemos elegir partir de una base en 0 o una base en 1. Yo he preferido partir de base 0 porque es la utilizada en los arrays por C#.
Ya tenemos relacionada la clase de entidad con los valores del csv, ahora falta buscarnos la vida para rellenar un objeto a partir de una fila del csv. Propongo utilizar Reflexion y las Templated classes para generalizar este proceso, creando una clase que trasforme un array de valores en un objeto del tipo que le indiquemos. A las propiedades de ese objeto les asignaremos el valor (mediante reflexion) que haya en el array de valores en la posición indicada. Vayamos al tema:

public class CSVConverter<T>
{
    public T Convert(string[] values)
    {
        Type type = typeof(T);
        T obj = Activator.CreateInstance<T>();
        try
        {
            CSVFieldAttribute att = null;
            object[] attributes = null;
            foreach (PropertyInfo prop in type.GetProperties())
            {
                attributes = prop.GetCustomAttributes(typeof(CSVFieldAttribute), false);
                if (attributes.Length &gt; 0)
                {
                    att = attributes[0] as CSVFieldAttribute;
                    /* Si hemos optado por usar base 1 debemos poner:
                        values[att.Order - 1]
                    */
                    if (!(values[att.Order].Trim().Equals(string.Empty)))
                    {
                        prop.SetValue(obj,
                           Convert.ChangeType(values[att.Order], prop.PropertyType),
                           null
                        );
                    }
                }
            }
        }
        catch (Exception ex)
        {
            throw new Exception("Error al intentar hacer la conversión de tipos.\r\n" + ex.Message, ex);
        }
        return obj;
    }
}

Ya solo queda procesar el fichero para ir creando los objetos y hacer lo que tengamos que hacer con ellos. Para ello, nos crearemos una clase base a partir de la cual heredaremos las clases de negocio que creamos oportunas para procesar distintos modelos de csv.

public class ProcessCSV<T>
{
    protected StreamReader _streamReader;
    protected string _line;
    public void Process(string filename)
    {
        try
        {
            _streamReader = new StreamReader(filename);
            this.ProcessHeader();
            this.ProcessBody();
            this.ProcessFooter();
        }
        catch (Exception ex)
        {
            throw ex;
        }
        finally
        {
            if (_streamReader != null)
                _streamReader.Close();
        }
    }
    protected virtual void ProcessHeader()
    {
        throw new Exception("No implementado");
    }
    protected virtual void ProcessFooter()
    {
        throw new Exception("No implementado");
    }
    protected virtual void ProcessOneObject(T obj)
    {
        throw new Exception("No implementado");
    }
    protected void ProcessBody()
    {
        T obj = Activator.CreateInstance<T>();
        _line = _streamReader.ReadLine();
        while (!_streamReader.EndOfStream && _line != null && _line.Trim() != string.Empty)
        {
            try
            {
                string[] values = _line.Split(';');
                CSVConverter<T> converter = new CSVConverter<T>();
                obj = converter.Convert(values);
                this.ProcessOneObject(obj);
            }
            catch (Exception ex)
            {
                // Aquí escribiríamos algo en el log indicando qué fila ha fallado
            }
        }
    }
}

Ya tenemos nuestra clase genérica. Pero claro, con esto no hacemos nada, si intentas parsear algo llamando a esta clase te van a saltar excepciones porque no está implementados algunos métodos necesarios. Generemos la clase que realmente usaremos.

Partimos de varios supuestos: el csv es el que he puesto arriba (con cabecera y pie), no vamos a usar para nada ni la cabecera ni el pie y queremos agregar a una lista para luego procesarlos (esto no lo voy a contemplar en el articulo).
Al tema:

public class EdadesBL : ProcessCSV<Edades>
{
    private List<Edades> _list;
    public EdadesBL()
    {
        _list = new List<Edades>();
    }
    protected override void ProcessHeader()
    {
        // Solo leemos porque no queremos conservar la cabecera
        _streamReader.ReadLine();
    }
    protected override void ProcessFooter()
    {
        // Solo leemos porque no queremos conservar la cabecera
        _streamReader.ReadLine();
    }
    protected override void ProcessOneObject(Edades obj)
    {
        // Solo queremos agregarlo a la lista.
        _list.Add(obj);
    }
    public List<Edades> Edades
    {
        get { return _list; }
    }
}

Ahora solo tenemos que procesar el fichero con dos simples líneas (en nuestro pequeño ejemplo 3 para recoger tambien la lista de Edades):

EdadesBL business = new EdadesBL();
business.Process(filename);
List todos = business.Edades;

Los sitios web desarrollados bajo el .NET framework son publicados con una precompilación del código fuente, sin embargo, las páginas aspx y los controles ascx son interpretados en tiempo de ejecución. Es decir: cada vez que un usuario solicita una página aspx ésta es interpretada por el servidor de aplicaciones y presentada al cliente.

Como puede suponerse, el hecho de que la página aspx contenga código fuente que deba ser compilado ralentizará la carga de la misma, puesto que se pasa de interpretar html y devolverlo a compilar código de servidor con más o menos lógica.

En muchas ocasiones es posible pensar que no nos es posible crear la página aspx tal y como queremos sin incluir código de servidor en la misma, esto es un error muy común, pero facilmente subsanable, siguiendo las siguientes recomendaciones.

• Solo está permitido utilizar código de servidor para cargar elementos dentro de controles de tipo DataBound (GridView, FormView, etc.). Aun así es poco recomendable porque sigue requiriendo compilación. Se recomienda la utilización del control Repeater.

 
                <%# Eval("TipoDePagina.Nombre") %>
 
                Editar Contenidos

• Si necesitamos que un elemento HTML obtenga propiedades (style, href, title, etc.) desde el lado del servidor, porque utilice alguna lógica de negocio debemos identificar a éste elemento con runat=server y asignar dichas propiedades desde el code-behind, que va precompilado cuando se publica.

aspx no recomendado:

<div id="global" class="fondo-menu-&lt;%= ambitoCabecera %&gt;">
<div id="cabecera" class="cabecera-&lt;%= ambitoCabecera%&gt;">
<div id="cabecera-logo">
            <a title="Alt" href="#">
                <img id="imgLogo" src="../images/&lt;%= image%&gt;" alt="Grupo Banco Popular" width="148" height="50" />
            </a></div>
<div id="shortcuts">
<ul class="horizontal">
	<li><a href="#">Atención al cliente</a> |</li>
	<li><a href="#">Sucursales</a> |</li>
	<li><a href="#">Tarifas</a> |</li>
	<li><a href="#">Simuladores</a></li>
</ul>
</div>
<div id="buscador">
            <fieldset>
 
            </fieldset></div>
</div>
</div>

Código no recomendado:

// Imagen por omision para el logo
public string _image = "default.jpg";
// Ambito por omision para la cabecera
public string _ambitoCabecera = "normal";
 
protected void Page_Load(object sender, EventArgs e)
{
 
    #region Dar valores a las variables
    ...
    #endregion
 
}

aspx recomendado:

<div id="global">
<div id="cabecera">
<div id="cabecera-logo">
            <a title="Alt" href="#">
                <img alt="Grupo Banco Popular" width="148" height="50" />
            </a></div>
<div id="shortcuts">
<ul class="horizontal">
	<li><a href="#">Atención al cliente</a> |</li>
	<li><a href="#">Sucursales</a> |</li>
	<li><a href="#">Tarifas</a> |</li>
	<li><a href="#">Simuladores</a></li>
</ul>
</div>
<div id="buscador">
            <fieldset>
 
            </fieldset></div>
</div>
</div>

Código recomendado:

protected void Page_Load(object sender, EventArgs e)
{
    // Imagen por omision para el logo
    string image = "default.jpg";
    // Ambito por omision para la cabecera
    string ambitoCabecera = "normal";
 
    #region Dar valores a las variables
    ...
    #endregion
 
    this.global.Attributes.Add("class", "fondo-menu-" + ambitoCabecera);
    this.cabecera.Attributes.Add("class", "cabecera-" + ambitoCabecera);
    this.imgLogo.Src = "../images/" + image;
 
}

• Si necesitamos que un elemento HTML reciba su identificador, propiedades sensibles o una maquetación compleja dependiente de una lógica de negocio, la solución optima es crear un custom web control para definirlo, éste tipo de controles heredan de la clase WebControl.

namespace Example.Web.UI.Controls
{
    [DefaultProperty("Text"), ToolboxData("&lt;{0}:OnlyText runat=server&gt;<!--{0}:OnlyText-->")]
    public class OnlyText : System.Web.UI.WebControls.WebControl
    {
        #region Attributes
 
        private string _text = "";
 
        #endregion
 
        #region Properties
 
        [Bindable("true"), Category("Data"), DefaultValue("")]
        public string Text
        {
            get { return _text;}
            set { _text = value;}
        }
 
        #endregion
 
        #region Overrides Methods
 
        protected override void  Render(HtmlTextWriter writer)
        {
             writer.Write(Text);
        }
 
        #endregion
    }
}