Question

许多.net框架对象，尤其是UI小部件，喜欢将其操作数作为通用对象，然后使用反射来查找描述应如何使用它们的特定于组件的属性。但我不想用一堆与显示相关的属性污染我的业务逻辑对象，也不希望属性的排列由某些外部组件的口味决定。我处理这个问题的冲动是创建适配器类。例如，假设我有这个对象：

public class BusinessLogicObject
{
   public int Prop1 { get; set; }
   public int Prop2 { get; set; }
   public int Prop3 { get; set; }

   void Operation1() { /* ... */ }
   void Operation2() { /* ... */ }
}

要与PropertyGrid一起使用，我可以这样做：

public class BLOPropertyGridAdapter
{
   private readonly BusinessLogicObject _blo;

   public BLOPropertyGridAdapter(BusinessLogicObject blo)
   {
      _blo = blo;
   }

   [Category("BLO Properties")]
   [Description("This is property 1")]
   [DisplayName("Property 1")]
   public int Prop1
   {
      get { return _blo.Prop1; }
      set { _blo.Prop1 = value; }
   }

   [Category("BLO Properties")]
   [Description("This is property 2")]
   [DisplayName("Property 2")]
   public int Prop2
   {
      get { return _blo.Prop2; }
      set { _blo.Prop2 = value; }
   }

   // don't want Prop3 to be visible in the grid, so omitted
}

但后来我决定我也想要XML序列化（我知道还有其他方法可以实现这一点，而且无论如何都要设计代码;为了这个例子，请耐心等待）：

public class BLOXmlAdapter
{
   [XmlElement("Property1")]
   public int Prop1 { get; set; }

   [XmlElement("Property2")]
   public int Prop2 { get; set; }

   [XmlElement("Property3")]
   public int Prop3 { get; set; }

   // yuk!
   public void ApplyToBLO(BusinessLogicObject blo)
   {
      blo.Prop1 = Prop1;
      blo.Prop2 = Prop2;
      blo.Prop3 = Prop3;
   }

   // yuk!
   public void PopulateFromBLO(BusinessLogicObject blo)
   {
      Prop1 = blo.Prop1;
      Prop2 = blo.Prop2;
      Prop3 = blo.Prop3;
   }

}

现在也许我决定要在应用程序的BusinessLogicObject文件中保存Settings，所以我必须再次执行此操作。除了我必须做的所有额外工作之外，我还创造了一个可维护性的噩梦。当然有更好的方法吗？！

我可能尝试的一件事是将所有适配器组合到一个加载了大量属性的“属性”类中，然后用该类的实例组合业务逻辑对象：

public class BusinessLogicObject
{
   private BLOProperties _properties;

   public BusinessLogicObject(BLOProperties properties)
   {
      _properties = properties;
   }

   public void Operation1() { /* ... */ }
   public void Operation2() { /* ... */ }
}

始终如一地，这将导致代码库由哑数据对象和用于对其进行操作的函数集合组成。换句话说，C。

处理这个问题的正确方法是什么？

Answer 1

一般来说，对于这种类型的事物推荐，你采用这种方法，因为它允许你将BL与消费者分离。

我认为您需要更具体地了解您认为＆＃34; 可维护性的噩梦＆＃34;。每个消费者拥有一个适配器似乎是很自然的，因为每个消费者很可能会有不同的要求。

如何避免为业务逻辑类创建多个特定于用例的适配器类？

1 个答案: