2010-01-26 13 views
9

Sto usando JSON.NET per serializzare e deserializzare l'oggetto per diversi scopi. Sono un grande fan di DI ma il codice qui sotto mi dà i brividi. Odori come codice errato:DI e 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 ... 
} 

Il costruttore predefinito è la cosa che mi dà i brividi. Ho aggiunto questo per sostenere la deserializzazione causata da JSON.NET:

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

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

Privacy i inherrits classe Foo dalla classe base astratta Baz!

La mia domanda a tutti voi DI e JSON.NET geek là fuori: come posso modificare il codice per evitare l'odore del codice che il costruttore di default mi dà in classe Foo?

risposta

18

Questo è un problema comune con tutti i tipi di Data Transfer Objects, sia che si adattino a JSON.NET, WCF o altre tecnologie. In effetti, è possibile affermare che tutte le classi con limite di inclinazione delle applicazioni soffrono di questo problema a un livello o l'altro. Il problema è equivalente per Windows Forms Controls e altre tecnologie di visualizzazione.

Nell'altra estremità dello stack di applicazioni, vediamo lo stesso problema con gli oggetti di configurazione e potenzialmente con alcuni tipi di ORM (come le classi di Entity Framework).

In tutti i casi, l'approccio migliore consiste nel trattare tutti gli oggetti di confine come tipi stupidi con una struttura maggiore del comportamento. Sappiamo già che questa è la cosa giusta da fare per WCF DataContracts, ASP.NET MVC Views, Windows Forms Controls, ecc. Quindi sarebbe una soluzione ben nota al problema.

Proprio come abbiamo i controllori per popolare le viste in un'interfaccia utente, possiamo avere operazioni di servizio, mapper e quant'altro che mappano gli DTO agli oggetti del dominio. In altre parole, la soluzione migliore sarebbe non tentare di serializzare Foo.

Invece, definire una classe FooJson che rappresenta la struttura statica di Foo e utilizzare un Mapper per tradurre tra i due.