4

哪一种是实现业务对象的首选方式（为什么）？

没有单独的“上下文”

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 -> OrderRow <- Product）。

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

4

1 回答 1

3

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

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

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);
}

这可以防止对象保留上下文（示例中的字段）并使您的业务对象保持简单。它还消除了担忧。

如果您遇到业务对象继承的情况，请考虑访问者模式。

于 2012-05-13T09:32:23.160 回答