Hace unas semanas, en el post Cambiar la ubicación de las vistas en ASP.NET MVC estuvimos viendo cómo era posible aprovechar la flexibilidad del framework para saltarse las convenciones respecto a la ubicación de los archivos de vistas (.aspx, .ascx y .master).

En esta ocasión vamos a seguir profundizando en los puntos de extensión del framework, centrándonos en la facilidad con la que podemos modificar el ControllerFactory, que es el componente encargado de localizar y crear las instancias de los controladores que deben procesar las peticiones.

Y vamos a ilustrarlo con un ejemplo, en el que desmontaremos otra de las convenciones del framework MVC: el nombre de los controladores. Como sabemos, cuando se recibe una petición que según su ruta debe ser procesada por un controlador llamado XYZ, el motor por defecto intentará instanciar una clase denominada XYZController.  Lo que vamos a hacer es retocar este comportamiento para que nuestros controladores puedan denominarse “ControladorDeXYZ”, un nombre mucho más acertado en nuestro idioma.

En este post veremos cómo podemos modificar la forma en que este componente localiza las clases de controladores y adaptarla a nuestras preferencias.

Pero antes, recuerda:

Saltarse las convenciones = malo

Hazlo sólo cuando realmente esté justificado... o por diversión, como es el caso ;-)

Lo que vamos a hacer en el post no es una implementación eficiente, y por supuesto no es válida para un entorno de producción; se trata simplemente de un experimento que demuestra la facilidad para sustituir ciertos componentes del framework, y la flexibilidad que nos aporta. Los conceptos que vamos a tratar pueden ser utilizados con otros fines, como facilitar la inyección de dependencias en controladores, que probablemente veamos en un futuro post.

Y ahora, al tema…

1. El proceso básico de la petición

Antes de empezar la faena, es conveniente estudiar un poco el funcionamiento del framework; así podremos entender mejor qué estamos tocando.

Cuando se recibe una petición, su tratamiento pasa a través de una serie de componentes que se encargan de procesarla a distintos niveles siguiendo el ciclo de vida definido para el framework. Así, una vez que el sistema de enrutamiento ha terminado su tarea detectando la información presente en la URL y determinando, por tanto, su destino, utilizará un manejador MvcHandler para continuar procesando la petición desde el método ProcessRequest().

La porción de código de ASP.NET MVC framework donde se define este método es la siguiente (en el archivo MvcHandler.cs, recordad que el código fuente está disponible en Codeplex):

   1: protected internal virtual void ProcessRequest(HttpContextBase httpContext) 

   2: {

   3:     [...]

   4:     

   5:     // Get the controller type

   6:     string controllerName = 

   7:         RequestContext.RouteData.GetRequiredString("controller");

   8:     

   9:     // Instantiate the controller and call Execute

  10:     IControllerFactory factory = 

  11:         ControllerBuilder.GetControllerFactory();

  12:             

  13:     IController controller = 

  14:         factory.CreateController(RequestContext, controllerName);

  15:             

  16:     if (controller == null) 

  17:     {

  18:         throw new InvalidOperationException(...); // Simplificado

  19:     }

  20:     try 

  21:     {

  22:         controller.Execute(RequestContext);

  23:     }

  24:     finally 

  25:     {

  26:         factory.ReleaseController(controller);

  27:     }

  28: }

Resumidamente, podríamos decir que el sistema procesa las peticiones siguiendo estos pasos:

• en primer lugar, obtiene el nombre del controlador desde el contexto de la petición (normalmente desde la ruta). En el código anterior, se guarda en la variable controllerName.
• a continuación obtiene una instancia de la factoría de controladores desde la clase ControllerBuilder.
• una vez obtenida la factoría según el paso anterior, se le pide mediante una llamada a su método CreateController() que cree el controlador que procesará la petición, enviándole como parámetro el nombre obtenido anteriormente.
• y por último, se invoca al método Execute del controlador para que realice las acciones oportunas, liberando al final los recursos utilizados mediante una llamada a ReleaseController.

Como en otras muchas partes del framework, se puede observar en el código anterior la utilización de interfaces en lugar de clases para los elementos que intervienen en el proceso, lo que da pistas sobre la flexibilidad de ASP.NET MVC: casi cualquier elemento puede ser sustituido por otro siempre que se cumpla el contrato definido.

2. La factoría de controladores, a corazón abierto

Visto el procedimiento anteriormente descrito, está claro que la lógica de localización e instanciación del controlador es responsabilidad de las factorías de controladores, y más exactamente del método CreateController() que éstas deben implementar.

ASP.NET MVC utiliza como factoría la clase DefaultControllerFactory  de forma predeterminada, sin embargo, nada en el código anterior obliga a que esto sea así. Si logramos crear una nueva factoría que implemente el interfaz IControllerFactory e indicamos al framework que la utilice, ya casi tendremos el trabajo hecho.

En el código de la clase DefaultControllerFactory (la factoría predeterminada), se puede observar que el proceso de creación está compuesto por dos pasos; en el primero de ellos se obtiene el tipo de controlador mediante una llamada a GetControllerType(), mientras que en el segundo se obtiene una instancia de dicho tipo llamando a GetControllerInstance(), que es la que retorna el método:

   1: public virtual IController 

   2:     CreateController(RequestContext requestContext, string controllerName) 

   3: {

   4:     [...] // Simplificado

   5:     Type controllerType = GetControllerType(controllerName);

   6:     IController controller = GetControllerInstance(controllerType);

   7:     return controller;

   8: }

Dado que lo único que queremos sustituir es el mecanismo de localización, lo más sencillo es crear nuestra nueva factoría, a la que llamaremos AcmeControllerFactory, heredando de DefaultControllerFactory y sobrescribir el método GetControllerType, que afortunadamente es virtual.

El código completo para esta nueva clase es el siguiente:

   1: public class AcmeControllerFactory: DefaultControllerFactory

   2: {

   3:   protected override Type GetControllerType(string controllerName)

   4:   {

   5:       Type r = base.GetControllerType(controllerName);

   6:       if (r == null)

   7:       {

   8:           Assembly current = Assembly.GetExecutingAssembly();

   9:           r = (from t in current.GetTypes()

  10:                where

  11:                (

  12:                        t.Name.Equals("ControladorDe" + controllerName,

  13:                                       StringComparison.InvariantCultureIgnoreCase)

  14:                   && t.IsPublic

  15:                   && !t.IsAbstract 

  16:                   && typeof(IController).IsAssignableFrom(t)

  17:                )

  18:                select t).FirstOrDefault();

  19:       }

  20:       return r;

  21:   }

  22: }

Como podemos observar, lo primero que hacemos es intentar localizar el controlador con el nombre que nos llega en el parámetro, pero utilizando el método propuesto por la factoría por defecto, es decir, llamando al método GetControllerType() original. Es decir, vamos a ser al menos algo respetuosos con las convenciones de nombrado existentes ;-) … primero intentaremos localizar el controlador ciñéndonos a ellas, y sólo si no tenemos éxito aplicaremos nuestro propio criterio de nombrado.

Así, ante una petición rutada hacia el controlador Cliente, primero buscaremos la clase ClienteController (según la convención), y si no existe es cuando intentaremos localizar un tipo llamado ControladorDeCliente. Obviamente, podríamos hacerlo al revés, es decir, buscar primero según nuestro criterio de nombrado y si no tenemos éxito buscar utilizando el estándar, o bien ni siquiera intentar esta última opción.

Por tanto, si el método por defecto no es capaz de encontrar un controlador correspondiente a dicha denominación es cuando ejecutamos nuestra lógica adicional, que consiste en buscar en el ensamblado actual, mediante una consulta LINQ, aquellas clases cuyo nombre corresponda con el patrón que pretendemos emplear (“ControladorDe”+controllerName), y que sean públicas, instanciables, e implementen el interfaz IController.

No se han implementado optimizaciones, como la inclusión de un caché, que permitan mejorar el rendimiento en esta consulta. Cada petición deberá recorrer, en el peor de los casos, todo el ensamblado en busca de un controlador apropiado.

Tampoco se ha implementado ningún tipo de resolución de conflictos; si existe más de un controlador con el mismo nombre en distintos namespaces, se retornará el primero que se encuentre.

Eso os lo dejo de deberes ;-)

3. Sustituir la factoría de controladores

Ya tenemos creada la clase AcmeControllerFactory, nuestra propia factoría de controladores, y está lista para entrar en acción. Pero, ¿cómo le decimos al framework que queremos utilizar una factoría de controladores distinta a la predeterminada?

Volvamos a estudiar el código de procesado de las peticiones que vimos anteriormente. Como se puede observar, el IControllerFactory a utilizar es obtenido desde la clase ControllerBuilder:

   1: protected internal virtual void ProcessRequest(HttpContextBase httpContext) 

   2: {

   3:   [...]

   4:   // Instantiate the controller and call Execute

   5:   IControllerFactory factory = 

   6:             ControllerBuilder.GetControllerFactory();

   7:             

   8:   IController controller = 

   9:             factory.CreateController(RequestContext, controllerName);

  10:     [...]

  11: }

Y aquí de nuevo entra en juego la flexibilidad del diseño de ASP.NET MVC: ControllerBuilder viene preparada para que podamos sustituir muy fácilmente la factoría a instanciar, por lo que podemos indicarle el tipo concreto que queremos que utilice.

En el siguiente código estamos indicando al ControllerBuilder que nuestra factoría por defecto, es decir, la clase encargada de buscar e instanciar los controladores, será AcmeControllerFactory. Como  se define en la inicialización de la aplicación (Application_Start del global.asax), todas las peticiones utilizarán esta factoría para crear los controladores:

   1: protected void Application_Start()

   2: {

   3:     RegisterRoutes(RouteTable.Routes);

   4:     ControllerBuilder

   5:         .Current

   6:         .SetControllerFactory(typeof(AcmeControllerFactory));

   7: }

4. Probar que realmente funciona

Podemos comprobar el funcionamiento de todo este invento de forma muy sencilla. Una vez seguidos los pasos anteriores, basta con crear un nuevo controlador que ya atienda a nuestra propia convención de nombrado, como el siguiente:

   1: [HandleError]

   2: public class ControladorDeCliente : Controller

   3: {

   4:   public ActionResult Listar()

   5:   {

   6:       return View();

   7:   }

   8:  

   9:   public ActionResult Editar()

  10:   {

  11:       return View();

  12:   }

  13: }

Creamos, asimismo, una vista “Listar.aspx” y otra “Editar.aspx” en la carpeta “Views\Cliente” para que el motor pueda localizarlas y podamos ver algún resultado en pantalla. A partir de este momento, ejecutando el proyecto, podremos comprobar cómo si introducimos la URL  http://localhost:tupuerto/Cliente/Listar el flujo de ejecución pasará por el método Listar() visto anteriormente. También podemos invocar a la acción Editar(), y el resultado será el esperado.

Y para los perezosos, ahí va el código fuente del proyecto (requiere Visual Studio 2008 o Web Developer Express con SP1 y ASP.NET MVC 1.0):

Publicado en: Variable not found.

Joe Cartano, perteneciente al Visual Web Development Team de Microsoft, ha publicado en el blog oficial (Visual Web Developer Team Blog) un post anunciando que ha actualizado la plantilla que permite crear directamente proyectos ASP.NET MVC con tests unitarios NUnit.

Así, una vez instalado, al crear un proyecto de tipo ASP.NET MVC nos aparecerá un cuadro de diálogo como el siguiente, en el que se nos brindará la oportunidad de crear en la solución un proyecto de pruebas unitarias utilizando NUnit:

Para los poseedores de algunas de las versiones profesionales de Visual Studio 2008, esta ventana no es nueva, puesto que por defecto ya se incluyen los proyectos de tests propios de Microsoft, pero sí lo es para la versión express del IDE, que no incluye el framework de pruebas y en el que había que crear el proyecto a mano.

El proyecto, que se crea automáticamente, realiza 27 tests sobre la plantilla original de proyectos ASP.NET MVC, y pueden servir como base para seguir creando nuestro propio conjunto de pruebas:

La plantilla se instala descargando el archivo .zip cuyo enlace encontraréis en el post original y ejecutando, si es necesario con un usuario con privilegios de administrador, el script installNUnit.cmd disponible en el raíz del directorio donde lo hayáis descomprimido.

Para que todo vaya bien, debéis contar con NUnit previamente instalado en vuestro equipo. Pero ojo, las plantillas están preparadas para la versión 2.4.8.0 y la versión actual es la 2.5.0.9122, por lo que puede que no os funcionen bien si estáis a la última.

En este caso, es necesario tocar a mano los archivos de plantillas. Podéis seguir estos pasos:

1. Descargad el archivo de plantillas desde el blog del Visual Web Developer Team.
2. Descomprimidlo sobre cualquier carpeta.
3. En los subdirectorios CSharp y Visual Basic encontraréis un archivo llamado MvcApplication.NUnit.Tests.zip. Son las plantillas para cada uno de esos lenguajes.
4. El interior de dicho zip está el archivo de proyecto (MvcApplication.NUnit.Test.vbproj en el caso de Visual Basic, MvcApplication.NUnit.Test.csproj en C#). Descomprimid sólo estos archivos y buscar en ambos la cadena “2.4.8.0” y sustituirla por la versión de NUnit que tengáis instalada (en mi caso, “2.5.0.9122”). Al acabar, actualizad de nuevo el .zip con el archivo que acabáis de editar.
5. Ejecutad el script de instalación installNUnit.cmd.

Publicado en: Variable not found.

Existen numerosas aplicaciones que permiten analizar nuestros desarrollos con el objetivo final de incrementar la calidad de los mismos. FxCop, por ejemplo, es capaz de analizar los ensamblados y avisarnos cuando se encuentra con incumplimientos de las pautas de diseño para desarrolladores de librerías para .Net Framework (Design Guidelines for Class Library Developers). También hace tiempo comenté por aquí la disponibilidad de  Microsoft Source Analysis for C#, una herramienta que se centra en el código fuente y el cumplimiento de reglas de codificación.

Ahora, gracias al ofrecimiento de Patrick Smacchia, lead developer del producto, he podido probar NDepend, una herramienta de análisis de código de la que había oído hablar y que va mucho más allá que las citadas anteriormente.

La principal misión de NDepend es ayudarnos a incrementar la calidad de nuestros sistemas desarrollados con .NET mediante el análisis de sus ensamblados y código fuente desde distintas perspectivas, como la complejidad de sus módulos, el tamaño de los mismos, las interdependencias entre ellos, etc. Es decir, a diferencia de otros analizadores, su objetivo no es avisarnos de aspectos como la utilización de convenciones de codificación (aunque también puede hacerlo), o el uso de buenas prácticas de diseño, sino ayudarnos a determinar, por ejemplo, cuándo ponemos en peligro la mantenibilidad y evolución de un sistema debido a la complejidad  o al fuerte acoplamiento de algunos de sus componentes, por citar sólo algunos criterios.

El entorno gráfico

VisualNDepend es el entorno gráfico de la herramienta, y nos ofrece un entorno de trabajo muy potente e intuitivo, aunque durante los primeros minutos pueda resultar algo complejo debido a la cantidad de información mostrada.

Iniciar el análisis de un sistema es muy sencillo; una vez seleccionado el ensamblado, conjunto de ensamblados o proyecto a estudiar, el sistema realiza el análisis, del cual se obtiene un informe bastante completo, basado en web, sobre el mismo (podéis ver un ejemplo de informe en la página del producto). En él se recogen:

• métricas de la aplicación, entre las que encontramos el número de líneas de código, comentarios, número de clases, métodos, etc., así como datos estadísticos relativos a la complejidad, extensión y estructura del código.
• métricas por ensamblado, donde se refleja, por cada uno de los ensamblados que componen la solución, datos sobre su tamaño, grados de cohesión, acoplamiento, y otros aspectos relativos a su complejidad e interdependencia.
• vista de estructura (captura de la derecha) que muestra la distribución de componentes, la granularidad y su complejidad relativa según el tamaño de los bloques visualizados.
• diagrama de abstracción e inestabilidad, que posiciona cada ensamblado en función del número de clases abstractas e interfaces que presenta y su dependencia del resto de elementos.
• relación entre ensamblados, que detalla las interdependencias entre ensamblados del proyecto, los posibles ciclos, así como un posible orden de generación.
• consultas y restricciones CQL, que realiza una serie de consultas predefinidas sobre los ensamblados y el código que nos ayuda a detectar una infinidad de problemas en nuestros desarrollos, desde aspectos relativamente simples como el exceso de métodos en clases o el incumplimiento de ciertas convenciones de nombrado, hasta problemas en la cobertura de los tests generados con NCover o Visual Studio Team System.

Pero lo mejor del entorno gráfico no es poder generar un análisis en formato web para poder consultarlo más adelante, de hecho esto puede conseguir también con la aplicación de consola que incluye NDepend. Lo mejor son las fantásticas herramientas interactivas que nos permiten navegar a través de nuestras aplicaciones, cambiar de vista, ampliar información sobre cualquier elemento, y realizar consultas en tiempo real, siempre ofreciendo unos resultados muy claros y visuales, como:

• diagrama de dependencias entre todo tipo de elementos, como clases, espacios de nombres, o ensamblados. Resulta muy útil, además, configurar el tamaño de los bloques, el grosor del borde y el de las flechas de unión para que sean proporcionales a la complejidad, tamaño y una larga lista de criterios.
• matriz de dependencias, que muestra de forma visual las relaciones de utilización entre espacios de nombres, tipos, métodos o propiedades, con posibilidad de ir ampliando información.
• comparación entre ensamblados, mostrándonos los cambios producidos entre, por ejemplo, dos versiones de una misma librería o aplicación.
• navegación avanzada por el código a través del uso del menú contextual que facilita la rápida localización de referencias, directas e indirectas, hacia y desde un método, propiedad o tipo existente.
• enlace con Reflector, una herramienta indispensable, con la que se integra perfectamente gracias a su plugin.

CQL (Code Query Language)

Sin duda, una de las características más interesante que tiene NDepend es el soporte del lenguaje de consulta CQL (Code Query Language), que nos ofrece la posibilidad de tratar nuestro código y ensamblados como si fuesen una gigantesca base de datos sobre la que podemos realizar consultas de forma muy natural.  Las posibilidades que esto ofrece son tan amplias que prácticamente todas las funcionalidades de la aplicación están basadas en órdenes CQL prediseñadas que acompañan al producto, aunque podemos crear todas las consultas personalizadas que necesitemos, como por ejemplo:

/* Obtiene los métodos que escriben una propiedad */
SELECT METHODS WHERE IsDirectlyWritingField "Model.Cliente.Nombre"

/* Obtiene métodos que acceden incorrectamente a los
   datos desde la capa de interfaz
*/
SELECT METHODS FROM NAMESPACES "Interfaz" WHERE IsDirectlyUsing "MySql.Data"

/* Obtiene los 10 métodos con más líneas de código */
SELECT TOP 10 METHODS ORDER BY NbLinesOfCode DESC

/* Obtiene los métodos considerados "peligrosos" según su complejidad ciclomática */
SELECT METHODS WHERE CyclomaticComplexity > 20

Además de consultas CQL cuyo resultado podremos observar de forma directa tanto visualmente como en forma de listado, es posible incluir restricciones (WARN) que hará que el sistema nos alerte durante el análisis de un proyecto que cumpla las condiciones especificadas. Por ejemplo, la siguiente restricción nos avisará cuando exista un cierto tufillo a complejidad excesiva en un método (que haya sido definido con más de 10 parámetros):

WARN IF Count > 0 IN  SELECT METHODS WHERE NbParameters > 10

Estas consultas pueden ser añadidas (en la versión Pro) e integradas en los análisis, así como modificar las existentes, de forma que el producto puede ser personalizado a nuestras convenciones o necesidades específicas.

Otra posibilidad es incluir dentro del código de un ensamblado las restricciones que deseamos que se cumplan, expresándolas en lenguaje CQL embebido en un atributo de tipo CQLConstraint aplicado a sus elementos:

Afortunadamente existe mucha información disponible en la web sobre el lenguaje CQL, y consultas que nos muestran cómo sacarle el máximo partido.

Instalación e integraciones

NDepend se distribuye en formato .zip, y que puede ejecutarse directamente una vez descomprimido el contenido sobre una carpeta. La licencia, una vez obtenida, es un archivo XML firmado digitalmente que debemos colocar en el directorio de la aplicación, y listo.

Ya en ejecución, desde el menú “options” es posible configurarlo para que se integre con Visual Studio 2005, 2008 y como he comentado anteriormente, con el magnífico Reflector, con el que hace una excelente pareja.

Asimismo, es posible utilizarlo en sistemas como MSBuild y NAnt, facilitando así su uso en entornos de integración continua y montaje automatizado, para los que ofrece librerías

Finalmente, he de aclarar que NDepend es una aplicación comercial, aunque dispone de una versión limitada gratuita utilizable por universidades, desarrolladores open source e incluso, durante un tiempo determinado, de prueba en proyectos comerciales.

En cualquier caso, no dudéis en probarlo: os dará un control sobre vuestro código difícil de conseguir con otras herramientas.

Publicado en: www.variablenotfound.com

Escenario de partida

  Function Maximo(ByVal uno As Integer, ByVal otro As Integer) _
                  As Integer
    If uno > otro Then Return uno
    Return otro
  End Function

  Function Maximo(ByVal uno As Integer, ByVal otro As Integer) _
                  As Integer
    ' ...  
  End Function
  Function Maximo(ByVal uno As Long, ByVal otro As Long) _
                  As Long
    ' ...  
  End Function
  Function Maximo(ByVal uno As Decimal, ByVal otro As Decimal) _
                  As Decimal
    ' ...  
  End Function

  ' Y así hasta que te aburras...

  Function Maximo(ByVal uno As IComparable, ByVal otro As Object) As Object
    If uno.CompareTo(otro) > 0 Then Return uno
    Return otro
  End Function

El método genérico

  Function Maximo(Of T As IComparable) _
                 (ByVal uno As T, ByVal otro As T) As T
    If uno.CompareTo(otro) > 0 Then Return uno
    Return otro
  End Function

  Function MiMetodo(Of T1, T2, TResult) _
                   (ByVal par1 As T1, ByVal par2 As T2) As TResult

Restricciones en parámetros genéricos

  Function Maximo(Of T As IComparable) _
                 (ByVal uno As T, ByVal otro As T) As T
    If uno.CompareTo(otro) > 0 Then Return uno
    Return otro
  End Function

• As Structure, indica que el argumento debe ser un tipo valor.
• As Class, indica que T debe ser un tipo referencia.
• As New, fuerza a que el tipo T disponga de un constructor público sin parámetros; es útil cuando desde dentro del método se pretende instanciar un objeto del mismo.
• As nombredeclase, indica que el argumento debe heredar o ser de dicho tipo.
• As nombredeinterfaz, el argumento deberá implementar el interfaz indicado.
• As nombredetipogenérico, indica que el argumento al que se aplica debe ser igual o heredar del tipo, también argumento del método, indicado por nombredetipogenérico (observad en el siguiente ejemplo el parámetro T2).

  Function MiMetodo(Of T1 As {Class, IEnumerable}, _
                       T2 As {T1, New}, _
                       TResult As New) _
                   (ByVal par1 As T1, ByVal par2 As T2) As TResult
    ' ... Cuerpo del método
  End Function

Uso de métodos genéricos

  Dim mazinger As String = Maximo(Of String)("Mazinger", "Afrodita")
  Dim i99 As Integer = Maximo(Of Integer)(2, 99)

  Dim mazinger As String = Maximo("Mazinger", "Afrodita")
  Dim i99 As Integer = Maximo(2, 99)

Otro ejemplo de método genérico

  Function CreaLista(Of T)(ByVal ParamArray pars() As T) As List(Of T)
    Dim list As New List(Of T)
    For Each elem As T In pars
      list.Add(elem)
    Next
    Return list
  End Function

  ' ...
  ' Uso:
  Dim nums = CreaLista(Of Integer)(1, 2, 3, 4, 5, 6, 7)
  Dim noms = CreaLista(Of String)("Pepe", "Juan", "Luis")

  Dim nums = CreaLista(1, 2, 3, 4, 5, 6, 7)
  Dim noms = CreaLista("Pepe", "Juan", "Luis")

  ' Incluso con tipos anónimos de VB.NET 9
  Dim v = CreaLista( _
                     New With {.X = 1, .Y = 2}, _
                     New With {.X = 3, .Y = 4} _
                   )
  Console.WriteLine(v(1).Y) ' Muestra "4"

 // Necesitaremos estos namespaces...
 using System.Net.Mail;
 using System.Net.Mime;
 ...

 // Montamos la estructura básica del mensaje...
 MailMessage mail = new MailMessage();
 mail.From = new MailAddress("origen@miservidor.com");
 mail.To.Add("destinatario@miservidor.com");
 mail.Subject = "Mensaje con imagen";

 // Creamos la vista para clientes que
 // sólo pueden acceder a texto plano...

 string text = "Hola, ayer estuve disfrutando de "+
               "un paisaje estupendo.";

 AlternateView plainView = 
     AlternateView.CreateAlternateViewFromString(text, 
                             Encoding.UTF8,
                             MediaTypeNames.Text.Plain);


 // Ahora creamos la vista para clientes que 
 // pueden mostrar contenido HTML...

 string html = "<h2>Hola, mira dónde estuve ayer:</h2>" +
               "<img src='cid:imagen' />";

 AlternateView htmlView = 
     AlternateView.CreateAlternateViewFromString(html, 
                             Encoding.UTF8,
                             MediaTypeNames.Text.Html);

 // Creamos el recurso a incrustar. Observad
 // que el ID que le asignamos (arbitrario) está
 // referenciado desde el código HTML como origen
 // de la imagen (resaltado en amarillo)...

 LinkedResource img = 
     new LinkedResource(@"C:\paisaje.jpg", 
                         MediaTypeNames.Image.Jpeg);           
 img.ContentId = "imagen";

 // Lo incrustamos en la vista HTML...

 htmlView.LinkedResources.Add(img);

 // Por último, vinculamos ambas vistas al mensaje...

 mail.AlternateViews.Add(plainView);
 mail.AlternateViews.Add(htmlView);

 // Y lo enviamos a través del servidor SMTP...

 SmtpClient smtp = new SmtpClient("smtp.miservidor.com");
 smtp.Send(mail);

Escenario de partida

  public int Maximo(int uno, int otro)
  {
    if (uno > otro) return uno;
    return otro;
  }

  public int Maximo(int uno, int otro) { ... }
  public long Maximo(long uno, long otro) { ... }
  public string Maximo(string uno, string otro) { ... }
  public float Maximo(float uno, float otro) { ... }
  // Hasta que te aburras...

  public object Maximo(IComparable uno, object otro)
  {
    if (uno.CompareTo(otro) > 0) return uno;
    return otro;
  }

El método genérico

  public T Maximo<T>(T uno, T otro) where T: IComparable
  {
    if (uno.CompareTo(otro) > 0) return uno;
    return otro;
  }

  public TResult MiMetodo<T1, T2, TResult>(T1 param1, T2 param2)
  {
      // ... cuerpo del método
  }

Restricciones en parámetros genéricos

  public T Maximo<T>(T uno, T otro) where T: IComparable
  {
    if (uno.CompareTo(otro) > 0) return uno;
    return otro;
  }

• where T: struct, indica que el argumento debe ser un tipo valor.
• where T: class, indica que T debe ser un tipo referencia.
• where T: new(), fuerza a que el tipo T disponga de un constructor público sin parámetros; es útil cuando desde dentro del método se pretende instanciar un objeto del mismo.
• where T: nombredeclase, indica que el argumento debe heredar o ser de dicho tipo.
• where T: nombredeinterfaz, el argumento deberá implementar el interfaz indicado.
• where T1: T2, indica que el argumento T1 debe ser igual o heredar del tipo, también argumento del método, T2.

  public TResult MiMetodo<T1, T2, TResult>(T1 param1, T2 param2)
    where TResult: IEnumerable
    where T1: new(), IComparable
    where T2: IComparable, ICloneable
    {
        // ... cuerpo del método
    }

Uso de métodos genéricos

  string mazinger = Maximo<string>("Mazinger", "Afrodita");  
  int i99 = Maximo<int>(2, 99);

  string mazinger = Maximo("Mazinger", "Afrodita");  
  int i99 = Maximo(2, 99);

Otro ejemplo de método genérico

  public List<T> CreaLista<T>(params T[] pars)
  {
    List<T> list = new List<T>();
    foreach (T elem in pars)
    {
      list.Add(elem);
    }
    return list;
  }

  // ...
  // Uso:
  List<int> nums = CreaLista<int>(1, 2, 3, 4, 6, 7);
  List<string> noms = CreaLista<string>("Pepe", "Juan", "Luis"); 

  List<int> nums = CreaLista(1, 2, 3, 4, 6, 7);
  List<string> noms = CreaLista("Pepe", "Juan", "Luis"); 

  // Incluso con tipos anónimos de C# 3.0:
  var p = CreaLista(
            new { X = 1, Y = 2 }, 
            new { X = 3, Y = 4 }
          );
  Console.WriteLine(p[1].Y); // Pinta "4"