分布式环境下对具有对象类型的属性的对象的添加、删除及修改

 

分布式环境下对具有对象类型的属性的对象的添加、删除及修改

1.     问题描述

要讨论问题首先要把问题说清楚才好讨论,下面是我们所要讨论的问题的描述。注意,我们这里不讨论对象传输时的marshalunmarshal问题,总之,对象能够在网络上传输(比如通过RMIWebServices等)。

1.1     问题

有时候对象的逻辑结构比较复杂,它不但有整型、字符串型等基本类型的属性,还包含对象类型的属性,对于处于分布式环境下的此类对象,进行对象的添加、删除及修改。

1.2     需要考虑的各个要素

对于这个问题,有以下几个方面需要考虑[K1] 

l         从业务逻辑的角度来看,由于此类对象就是应用程序应该处理的一个单元,所以,对于对象的操作应该是原子化的。而从用户操作的角度看来,应该在一个界面中就提供操作整个对象的能力,当然包括其下层对象。

l         如果服务器提供支持,允许客户端自己控制事务,那么,客户端可以保证自己所做的操作的原子化,但服务器要维护这个客户的状态;并且客户端在事务之间(已启动事务,但尚未提交或回滚)有可能由于某种原因失去于服务器的连接,服务器要处理这种情况有一定复杂度。

l         一般来说,为了提高吞吐量及容错性,服务器应该尽量是无状态的。

l         如果把整个对象信息包装在一个方法调用中传给服务器,那么对象定义可能会相当复杂,或者带来许多冗余工作(后面会逐一分析)。

1.3     示例

这里是一个例子,Application对象包含下层对象Parameter,如下图

注意此图只是用来表示对象间的关系,并不是对象的准确定义。

1.4     难点所在

当添加或删除此类对象时,问题不大。问题是,当用户对对象的下层嵌套对象做了修改以后,应该以何种方式把改变传给服务器,服务器应该以何种方式抽取对象的改变信息,并把改变更新到数据库。

2.     可选解决方案

对于此问题,我们有以下实现方法,下面逐一分析。

2.1     把对对象的操作拆分开

我们可以在用户界面上把对对象的操作拆分开,每一次方法调用只操作对象的一部分,要么是对象的基本信息,要么是其下层对象。此时对象本身只定义基本信息,其下层对象通过调用服务器上的方法取得,如以下伪代码(java风格):

//Parameter的类定义

class Parameter {

  private String id;

  private String name;

  private String description;

  //省略了gettersetter方法

}

//Application的类定义

class Application {

  private String id;

  private String name;

  private String description;  

  private String definition;

  //省略了gettersetter方法

}

//服务器上定义的方法,此处略去可能抛出的了异常

………………

public Application[] getApplications();

public void addApplication(Application app);

public void updateApplication(Applicaton app);

public void deleteApplication(Application app);//或者只传id

public Parameter[] getParamForApp(String appId);

public addParamToApp(String appId, Parameter param);

public updateParamForApp(String appId, Parameter param);//也可能不需要传入appId

public deleteParamFromApp(String appId, Parameter param);//

………………

2.1.1     优点

l         逻辑清晰,实现起来已很简单,用户的每个操作,都能很快得到反映,不会出现数据不一致的现象。

2.1.2     缺点

l         服务器接口上定义了大量小粒度的方法。

l         与服务器交互频繁,每次仅传输少量信息。

l         把逻辑上的一个对象人为的拆开,强迫用户做多次操作,不友好。

 

2.2     删除下级对象然后重新插入

由于用户所关心的仅仅是结果,我们只要保证用户操作成功后,对象的状态是用户所需要的状态就行了,用户不会关心我们是怎样实现的。所以,我们可以把对象定义成符合其逻辑定义,当需要更新对象时,仅对对象基本信息做update操作,对下层对象则采取先删除所有下层对象,然后在根据传入的信息重新生成一遍的方法。如以下伪代码:

//Parameter的类定义

class Parameter {

  private String id;

  private String name;

  private String description;

  //省略了gettersetter方法

}

//Application的类定义

class Application {

  private String id;

  private String name;

  private String description;  

  private String definition;

  private Parameter[] params

  //省略了gettersetter方法

}

//服务器上定义的方法

………………

public Application[] getApplications();

public void addApplication(Application app);

public void updateApplication(Applicaton app);

public void deleteApplication(Application app);

………………

使用此方法,客户端会暂时维护对象修改后的状态,于服务器端的交互会少些,但用户的操作不能马上得到反映,可也不会出现用户所做的工作被丢掉的现象;比如,系统中已经有一个nameappOneApplication,用户又修改某个别的Applicationname属性为appOne  并对此Application做了许多别的修改(比如添加了许多Parameter),假如业务上不允许有同名的Application存在,那么当用户确定提交其修改时,系统可以给出提示,告知用户不能使用此名字,用户可以按照提示把name属性改为合适的值后提交,其对Application所做的其它修改不会丢失。

2.2.1     优点

l         保留了对象逻辑上的完整性

l         逻辑清晰,实现简单,对对象的修改和添加对象很相似。

2.2.2     缺点

l         虽然不会出现大量小粒度的方法调用,但可能会在网上传输许多冗余信息。比如,仅修改了某个Application10Paramater中的某1个的description属性,实际的修改可能仅有十几个字节的数据量,却要在网上传输整个对象的信息。

l         对数据库进行的密集的操作有可能会大大降低应用的吞吐能力。如果对象类型的属性比较多或对象嵌套层次比较深的话(就是说涉及到数据库里多张表),服务器在操作数据库时会锁住多张表,其它对相关表的访问请求(可能来自其它客户端或其它应用)被阻塞,导致效率大大降低。

l         在特定情况下,此方法可能会导致复杂的处理或干脆不可行,比如,如果应用中有别的地方引用了Parameter对象,数据库中一般会定义外键,此时,更新Parameter的属性是合理的,但对Parameter的删除操作会失败,从而使更新操作失败。

2.3     标记所有相关对象的增、删、改状态

我们可以标记所有相关对象的当前状态,提供一种‘增量式的更新’方式。目前许多开发环境中提供的数据操作控件,一般都有batch模式,可以缓存对数据的操作,然后在真正提交时一次更新到数据库,以PowerBuilderDataWindow为例,其内部有四个缓冲区(primary,deleted等),并且每行数据都相应的状态记录(new,modified等),我们也可以采用类似的方式。如以下伪代码:

class Parameter {

  private String id;

  private String name;

  private String description;

  private int status;//0:None, 1: New; 2: Modified, 3: Deleted etc.

  //省略了gettersetter方法

  ……………………..

 

  /* use this method to get XML format String which indicate update information of this object

    @return a XML format String.

  */

  public String getChangeInfo() {

  }

}

//Application的类定义

class Application {

  private String id;

  private String name;

  private String description;  

  private String definition;

  private Parameter[] params

  private Parameter[] deletedParams

  private int status;

  //省略了gettersetter方法

  …………………

  /* use this method to get XML format String which indicate update information of this object, here the information include information of subordinate classes.

    @return a XML format String.

  */

  public String getChangeInfo() {

……………………………….

  }

}

//服务器上定义的方法

………………

public Application[] getApplications();

public void addApplication(Application app);

public void updateApplication(String changeInfo);

public void deleteApplication(Application app);

………………

使用此方法,对象的定义会复杂一些,因为对象要能够表明有那些下层对象被删掉啦,以上的例子中的对象定义仅为演示用,并不是最好的定义方式,比如,你也可以定义另外一个数组专门存放被修改过的Parameter等。

注意服务器上updateApplication方法的定义,此时,我们也可以传递的是一个XML格式的字符串,其中指明了对象的更新信息;其实,我们当然也可以传递一个Application对象,这样,我们也不会像第二种方法一样出现不能工作的情况,因为,服务器可以从对象中取得那些下层对象是应该更新的,那些是真正应该删除的。但如果仅仅修改了某一个下层对象的某一个简单属性的话,传递整个对象仍然会带来相当的冗余。比较好的方法是仅传入必须的修改信息,对于没有改动过的下层对象的信息,根本不再网络上传送,这里假设是使用XML来实现的。下面给出一个XML的例子:

<Application status = '2' id = '00001' name = 'appOne' description = '' definition = ''>
    
  <ParamInfo>
    
    <Deleted>
    
      <param id = 'param009'/>
    
      <param id = 'param005'/>
    
    </Deleted>
    
    <Modified>
    
       <param id = 'param003' name = 'ParamThree' description = 'Changed'/>
    
    </Modified>
    
    <Added>
    
       <param id = 'Server control' name = 'Other' description = ''/>
    
       <param id = 'Server control' name = 'Another' description = ''/>
    
    </Added>
    
  </ParamInfo>
    
</Application>
    

这段XML片断表明,id为‘00001’的Application其基本信息被修改了,因为status2,所以更新此Application应更新时应更新其基本信息,另外,此Application有两个Parameter对象(其id分别为‘param009’和‘param005’)被删除啦,用户修改了一个Parameter,并另加了两个新的Parameter

注意到此Applicationstatus所指明的状态是指的其基本信息,如果status0并不意味着Application对象的下层对象也没改变。戏法人人会变,各有巧妙不同,这里标记信息的定义及XMLschema的定义都有很大的弹性。

2.3.1     优点

l         保留了对象逻辑上的完整性

l         几乎没有冗余信息(这里用‘几乎’是因为XML标记本身是冗余信息,虽然数据量很小)

l         无须多余的数据库操作

l         如果对象定义的再复杂一些(比如定义一个Parameter的原始数据数组),用户甚至可以不用和服务器交互就回到对象原来的状态

l         灵活,弹性大,可扩展性比较强。

2.3.2     缺点

l         实现起来会比较复杂,潜在的犯错误的可能也就比较大。

3.     结论

好了,分析过了,是该做结论的时候了,我们的结论是——没有结论^_^ 所谓模式也是在特定情况下的对于特定问题的解决方法。已有了那么多经典模式,如果我只需要写一个‘Hello, World’程序的话,我还是会不使用模式,就是说,以上各种方法,我们应当根据手上问题的具体情况来决定具体选用那个。

一般来说,现在我们手上的工作,优先级比较高的是要短、平、快,我们需要尽快把东西搞出来,所以在条件允许的情况下,我们应该首选第二种方法。对于此方法的缺点,如果应用的规模大到这真的成了问题的程度的话,我们可以通过要求提高网络带宽及数据库服务器硬件的性能来克服^_^

第三种方法是最优雅的解决方法,如果你是完美主义者,或者想培养自己做科学家的品质的话,你可以优先选用此方法。对于我们普通俗人,只有在使用第二种方法不能接受的情况下才应该使用此方法。

第一种方法打破了对象本身的完整性,可能会惹恼‘上帝’,一般来说,不提倡使用,但某些应用模式下,有可能只能使用这种方式,而且用户也已对这种操作模式习以为常了,比如,用户界面是基于浏览器的瘦客户端,那么这时候也无需犹豫,就用这种方法好啦。

End of this document


 [K1]压力要素

  • 0
    点赞
  • 0
    收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
©️2022 CSDN 皮肤主题:大白 设计师:CSDN官方博客 返回首页
评论

打赏作者

Kean_Liu

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值