服务器对象的UI表示

时间:2011-08-16 08:35:44

标签: c# architecture

我有一个应用程序,其中创建了大量对象,其属性经常被用户更改。服务器中有各种模块,每个模块创建一个会话。每个会话包含一个客户端和一个运行主应用程序的用户。用户只是干扰对象并修改其属性,当前我正在使用Windows窗体中的属性网格来执行此操作。客户端如何连接到主应用程序尚未决定。我在考虑双工WCF服务。我需要两个建议:

  1. 如何在客户端UI上表示远程对象?我想在VS表单设计器上手动创建UI项目并放置一个映射XML文件,初始化的UI使用映射表来获取每个UI元素的属性详细信息并进行相应的修改。当映射对象的故障状态为真时,UI中的面板将填充一些颜色。

  2. 由于服务器上的对象经常更改,因此告诉客户端更新UI的最佳方法是什么。我在考虑双工WCF,如果客户端注册了特定对象,他将被告知对象的更改。我的问题是我们应该将整个对象转移到客户端,还是仅将更新的属性与对象Id(包装在新类型中)

    一起转移
    interface IChange
    {
        string ObjectName { get; set; }
        string PropertyName { get; set; }
        object NewValue { get; set; }
        object OldValue { get; set; }
    }
    
  3. 建议我实现目标的替代或更好方法

    修改

    目前没有任何对象不多,但它可能会急剧增长。这个应用程序是基于插件的,开发人员可能会添加数千个对象+可能有几个插件。物体尺寸我预计不会高于10-20kB,但不确定。点是如果我将整个对象发送到客户端(90%的对象是无用的,只有更新的属性与客户端相关。),客户端必须扫描所有属性并更新UI。但是,如果我只向客户发送更改,那么客户端知道要更改的内容。对象的更新可能非常频繁,因为对象的一个​​属性的任何更改,它会触发对其他对象的多次更改(链式反应的类型),并且应通知所有更改。例如,如果我更改了我家的主交换机的IsOn属性,则会触发所有设备关闭。所有这些对象更改都需要通知客户端。一旦客户端收到关闭每个对象的通知,它将在UI上显示所有设备未运行。

1 个答案:

答案 0 :(得分:0)

  
    

我的问题是我们是应该将整个对象传输到客户端还是仅将更新的属性与对象ID(包装为新类型)一起传输?

  

效果:取决于数据对象的大小,以及任何时候有多少更改。例如,如果您有1000个对象,每个对象的大小为1Mb,具有1000个不同的属性,并且平均只进行了1或2次微小更改,那么仅发送更改是有意义的。

  • 减少网络负载
  • 内存/处理密集程度
  • 如果必须反序列化大量XML,则尤其如此。

复杂性:有时候更容易将任何变化的东西吹走,从头开始;你不需要太担心维护对象状态,处理同一对象的多个更改等等。

  

由于服务器上的对象经常变化,最好的是什么   告诉客户更新UI的方法?

回到可能对象的数量,它们改变的频率以及它们的来源(“客户端将如何连接到主应用程序尚未决定”)。还取决于UI需要的最新状态。如果服务器上的对象发生更改,并且您有100个需要更新的客户端 - 它们需要多久才能更新?

请记住,更频繁,更快速的事情会改变您应用程序的“繁琐”,这将开始破坏性能,您必须跨越更多的边界(域,进程,服务器,网络......)。

修改

所以听起来像unit of work模式可能会有所帮助:

  • 当变更请求进入时,让所有连锁变更生效。
  • 然后将所有更改(增量而非整个对象)作为单个“批处理”/集合发回给调用者。
  • 如果您有很多想要新数据的客户,可能会使用某种缓存。