Question

哪一个是更优选的实现业务对象的方式（以及为什么）？

没有单独的“背景”

class Product
{
   public string Code { get; set; }

   public void Save()
   {
       using (IDataService service = IoC.GetInstance<IDataService>())
       {
           service.Save(this);
       }
   }
}

使用方法是：

Product p = new Product();
p.Code = "A1";
p.Save();

使用单独的“上下文”

class Product
{
    private IContext context;

    public Product(IContext context)
    {
        this.context = context;
    }

    public string Code { get; set; }

    public void Save()
    {
        this.context.Save(this);
    }
 }

使用方法是：

using (IContext context = IoC.GetInstance<IContext>())
{
    Product p = new Product(context);
    p.Code = "A1";
    p.Save();
}

这一切都发生在BL层（除了用法示例）之外，与数据库等无关.IDataService是数据层的接口，用于保存“某处”的业务对象。 IContext基本上以某种方式包装IDataService。实际业务对象更复杂，具有更多属性和相互引用（如Order - ＆gt; OrderRow＆lt; - Product）。

我的观点是，第一种方法（太）简单，第二种方法在单一业务对象实例之外提供更多控制....是否有类似这样的指导方针？

Answer 1

我个人选择第三个版本，其中对象本身不知道如何保存自己，而是依赖另一个组件来保存它。当有多种方法来保存对象时，例如将其保存到数据库，json流，xml流，这会变得很有趣。这些对象通常称为Serializers。

所以在你的情况下，我会这么简单：

class Product
{
    public string Code { get; set; }
}

IContext序列化的序列化将是：

class ContextSerializer
{
    public void SaveProduct(Product prod)
    {
        using(IContext context = IoC.GetInstance<IContext>())
        {
           context.Save(prod);
        }
     }
}

用法是：

public void SaveNewProduct(string code)
{
   var prod = new Product() { Code = code };
   var contextSerializer = new ContextSerialzer();
   contextSerializer.SaveProduct(prod);
}

这可以防止对象保留上下文（示例中的字段）并使您的业务对象保持简单。它也引起了人们的关注。

如果您遇到业务对象中有继承的情况，请考虑Visitor Pattern。

具有上下文的业务对象与否？

1 个答案: