Programando yo el otro día en c#… necesitaba realizar un copia integra de un objeto, pero duplicando direcciones de memoria, es decir un objeto completamente nuevo pero que contenga los mismos datos… me interesaba que fuera una rutina universal que me sirviera para copiar cualquier objeto independientemente de su tipo.

A partir del artículo de Christian Bigentini descubrí que utilizando técnica de serialización y deserialización podia hacer lo que me proponia.

Pero por otro lado, me interesaba que el método que realiza una copia de mi objeto estuviera de algun modo asociado al tipo… para esto, lo mejor es utilizar las extensiones, una técnica que c# ha incluido a partir de la versión 3.0.

El código resultante es éste:

public static class MyExtensions{
  public static MiTipo Copia(this MiTipo plugin) {
    MemoryStream ms = new System.IO.MemoryStream();
    BinaryFormatter bf = new BinaryFormatter(null,
      new StreamingContext(StreamingContextStates.Clone));
    bf.Serialize(ms, plugin);
    ms.Seek(0, SeekOrigin.Begin);
    MiTipo copia = (MiTipo)bf.Deserialize(ms);
    ms.Close();
    return copia;
  }
}

Un ejemplo de su uso:

using espacio.nombres.declaracion.extensiones...
MiTipo objeto1 = new MiTipo();
objeto1.propiedad = "hola";
MiTipo objeto2 = objeto1.Copia();
...

Un truco para ahorrar código y quebraderos de cabeza cuando trabajamos con datasets de .NET es la propiedad NullValue que se encuentra en de la definición de las columnas de un DataTable. Si quieres mas detalles sobre DefaultValue y NullValue, lee éste artículo .

Pero en resumen, para ‘NullValue’ se trata de ahorrar la comprobación si el valor de la columna es nulo o no de modo que si la propiedad ‘NullValue’ la dejamos en blanco, de esto:

if (!row.IsObservacionesNull())
  obs = row.Observaciones;
else  
  obs = “”;

sólo necesitaremos hacer esto:

obs = row.Observaciones;

Con DefaultValue, la idea es que al dar a ciertas columnas valores por defecto, al insertar una nueva fila al Dataset sólo nos tendremos que preocupar por dar un valor a los campos que nos interese.

Cuando añades una partial class a una clase «Linq to SQL» de LINQ tienes todos los números que en un momento u otro acabe saliendo un error «‘MSLinqToSQLGenerator’ failed. Unspecified error» ¡incluso aunque tengas instalado el SP1 de Visual Studio 2008!. Gracias a éste enlace pude solucionar el problema.

1º paso: los using debe estar dentro del «namespace». Es decir de esto:

using System.Linq;
using System.Collections.Generic;
using System.Data;

namespace SIRAMcenter.Datos.Plugins
{
 partial class PluginInstanceDataContext
 {
   public IEnumerable GetNombreClasePluginsNoIControl(int idCentro)
   {

debes pasar a esto:

namespace SIRAMcenter.Datos.Plugins
{
 using System.Linq;
 using System.Collections.Generic;
 using System.Data;

 partial class PluginInstanceDataContext
 {
   public IEnumerable GetNombreClasePluginsNoIControl(int idCentro)
   {

2º paso: Ejecutar explicitamente la herramienta personalizada(MSLinqToSQLGenerator) de nuevo:

3ºpaso: limpia el proyecto y vuelve a compilar.

LINQ por defecto utiliza la consulta diferida. Cuando «navegamos» entre las clases de un LINQ to SQL (.dbml) éste en background va generando las consultas y de este modo nos ahorramos consultas inutiles.

El problema viene cuando queramos devolver una clase que forma parte de un .dbml como resultado de un método marcado como [OperationContract].

Es necesario modificar el comportamiento por defecto de consulta diferida a una consulta forzada. Ejemplo:

PluginInstanceDataContext pluginsContext =  new PluginInstanceDataContext();

var orderloadOption = new System.Data.Linq.DataLoadOptions();
DataLoadOptions dlo = new DataLoadOptions();
dlo.LoadWith(p => p.PluginParametro);
dlo.LoadWith(p => p.PluginTipoControl);
pluginsContext.LoadOptions = dlo;

var consulta = from plugins in pluginsContext.Plugin
                    where plugins.IdCentro == idCentro
                    select plugins;

Sino lo hacemos así nos encontraremos que las «clases hijas» no contienen datos.