【问题标题】:DI and JSON.NETDI 和 JSON.NET
【发布时间】:2011-01-09 14:29:56
【问题描述】:

我使用 JSON.NET 为不同目的序列化和反序列化对象。我是 DI 的忠实粉丝,但下面的代码让我不寒而栗。闻起来像坏代码:

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 ...
}

默认构造函数是让我不寒而栗的东西。我添加了这个来支持 JSON.NET 引起的反序列化:

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

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

注意类 Foo 从抽象基类 Baz 继承!

我对所有 DI 和 JSON.NET 极客的问题是:如何更改代码以避免默认构造函数在 Foo 类中给我的代码气味?

【问题讨论】:

    标签: .net json dependency-injection json.net


    【解决方案1】:

    这是各种Data Transfer Objects 的常见问题,无论它们是否适合 JSON.NET、WCF 或其他技术。事实上,您可以说所有面向应用程序边界的 类都在某种程度上受到了这个问题的困扰。该问题与 Windows 窗体控件和其他显示技术相同。

    在应用程序堆栈的另一端,我们看到配置对象和某些 ORM 类型(例如实体框架类)可能存在相同问题。

    在所有情况下,最好的方法是将所有此类边界对象视为结构多于行为的哑类型。我们已经知道,对于 WCF DataContracts、ASP.NET MVC 视图、Windows 窗体控件等,这是正确的做法,因此这将是该问题的众所周知的解决方案。

    就像我们在 UI 中使用控制器来填充视图一样,我们可以使用服务操作、映射器等将 DTO 映射到域对象。换句话说,您最好的办法是根本不尝试序列化 Foo。

    相反,定义一个 FooJson 类来表示 Foo 的静态结构,并使用 Mapper 在两者之间进行转换。

    【讨论】:

      猜你喜欢
      • 2014-03-23
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2022-06-28
      • 2019-05-05
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多