2010-09-27 52 views
0

设计理念问题之间进行切换:模式的行为的离散模式

  1. 假设我有绘制的对象的集合的特性的曲线图的用户控件。
  2. 该控件放置在具有长寿命控制器类的窗体上,该类暴露要绘制的对象集合。
  3. 该窗体还包含一个控件,可以在“模式”或不同的绘图样式之间切换。不同模式之间从使用中揭示其公共属性的对象的逻辑是不同的,但控件并不关心这一点。
  4. 将数据初始缓存到对象实例相当费力,并导致显示控件的某些功能出现性能问题。
  5. 尽管具有不同的逻辑,该对象实例表示同一组的建模变量/事物(但是你喜欢想象它们)之前和模式改变

问题的中点处的性质3表明,后所收集的实例应该被视为抽象的基础,并且存在具有不同内部逻辑的两个不同的派生类。不幸的是,这表明应该在每个模式开关中完全重新生成整个对象集合,浪费时钟周期。

有没有人有任何一个简单模式的基地不同实施之间传输缓存数据的例子?我认为一个重载的构造函数需要一个基类的实例,但这听起来非常可怕。也许人们不同意和喜欢这种风格,在这种情况下,我会考虑解决这个问题。

编辑#1:

一些澄清这个问题的具体情况;我猜想我的原始问题可能很模糊......

例如,让控件附加的绑定属性为List<BaseClass> ControllerClass.Items

让该控制询问办性质的工作是一些类似

double BaseClass.NumericProperty 
IEnumerable<Thing> BaseClass.AggregateProperty 

让我们有(至少)的BaseClass两个不同的子类称为DerivedClass1DerivedClass2。当控制切换模式时,意图是ControllerClass.Items将表示执行适当的内部逻辑以公开这些属性的项目的列表。

我建议在内部模式开关,即设定Controller.Mode = NewMode,控制器会通过执行类似_list_internal[i] = new DerivedClass2(_list_internal[i])目前在那里_list_internal包含一组DerivedClass1 S创建一套新的DerivedClass2,然后引发一个事件(像INotifyPropertyChanged的或其他)通知控制。 DerivedClass1DerivedClass2的构造函数都以BaseClass作为参数,将其细分为检索两者共有的数据。

我的问题是,这是一个公认的模式;如果没有,为什么不,以及有什么替代方案,牢记效率和每次UI执行任何操作时不要丢弃数据的需要。

+0

我在跟着你,关于你的对象是如何构成的小麻烦。代码示例可能有所帮助。 – mikemanne 2010-09-27 18:22:03

回答

2

我同意mikemanne这个问题有点模糊,但是从我的理解,以获得最大性能模式切换的时候,你就不得不接受一个略高的启动紧缩:

  • 控制器应与图形用户控件和模式切换器一起工作。基本上,它变成了页面控制器而不是任务控制器。
  • 控制器应预先保湿并维护包含所有显示模式基础数据的对象集合。这些可以是来自域模型的实际对象,也可以是包含从域计算出的结果的轻量级DTO集合。
  • 当控制器被要求切换模式时,应该使用一个独立的DrawHelper类将数据点转换为图形。每个DrawHelper都适用于一种绘图模式,并且它们都与控制器相同(它们从相同的基本类型或接口继承)。这被称为战略模式。

以下是无号:

  • 切勿将打开数据转换成图表点到你的域模型所需的逻辑。域模型不应该知道你打算如何使用它的数据,因为如果它做了,并且发生了变化,当域(它的基本职责,它应该是它唯一的一个)没有的时候,域对象会改变。
  • 不要每次都重新灌水数据。这就是你知道你试图避免的,但要做到这一点,确保你的控制器实际上是“长寿”的。许多Web框架生命周期会摧毁请求之间在服务器端使用的所有内容,只会保留“会话”状态包并要求您重新保存控制器。
  • 请勿将绘图逻辑放入控制器中;它会变得巨大。你甚至不应该把DrawHelper选择逻辑放在控制器中;相反,让Controller知道一个“工厂”,可以根据当前模式为其提供所需的DrawHelper。
+0

被接受为答案,因为** KeithS **所说的话促使我改变了一些策略。我正在尝试使'BaseClass'成为一个通用的,这需要我称之为'PluggableDTO'的东西。通过这种方式,功能逻辑可以与主控制器交换出来,因为它们之间有一个额外的抽象层,也就是设计恰当的BaseClass。如果有人有兴趣,我会在接近工作的地方发布代码示例。 – 2010-09-29 18:18:34