2010-01-26 14 views
9

Estoy usando JSON.NET para serializar y deserializar objetos para diferentes propósitos. Soy un gran admirador de DI, pero el siguiente código me da escalofríos. Huele mal al código:DI y JSON.NET

public class Foo : Baz 
{ 
    private readonly IBar bar; 

    public Foo() 
     : this(ObjectFactory.GetInstance<IBar>()) 
    { } 

    public Foo(IBar bar) 
    { 
     if (bar == null) 
      throw new ArgumentNullException("bar"); 

     this.bar = bar; 
    } 

    ... rest of class ... 
} 

El constructor predeterminado es lo que me da escalofríos. He añadido esto para apoyar la deserialización causada por JSON.NET:

string jsonString = ...; 
string concreteBazType = ...; 

Baz baz = (Baz)JsonConvert.DeserializeObject(jsonString, Type.GetType(concreteBazType); 

Aviso inherrits los Foo clase de la clase base abstracta Baz!

Mi pregunta a todos los frikis de DI y JSON.NET: ¿cómo puedo cambiar el código para evitar el olor de código que el constructor predeterminado me da en la clase Foo?

Respuesta

18

Este es un problema común con todo tipo de Data Transfer Objects, ya sea que quepan en JSON.NET, WCF u otras tecnologías. De hecho, se podría decir que todas las clases de orientadas a la frontera sufren este problema en un grado u otro. El problema es equivalente para los controles de Windows Forms y otras tecnologías de visualización.

En el otro extremo de la pila de aplicaciones, vemos el mismo problema con los objetos de configuración y posiblemente con algunos tipos de ORM (como las clases de Entity Framework).

En todos los casos, el mejor enfoque es tratar todos los Boundary Objects como tipos tontos con más estructura que comportamiento. Ya sabemos que esto es lo correcto para WCF DataContracts, ASP.NET MVC Views, Windows Forms Controls, etc. por lo que sería una conocida solución al problema.

Al igual que tenemos controladores para poblar vistas en una interfaz de usuario, podemos tener operaciones de servicio, mapeadores y otras cosas que correlacionan DTO con objetos de dominio. En otras palabras, tu mejor recurso sería no intentar serializar a Foo en absoluto.

En su lugar, defina una clase FooJson que represente la estructura estática de Foo y utilice un asignador para traducir entre los dos.