中间层的对象的粒度是粗一些好呢,还是细一些好。
举例来说,企业的入库单要分期初入库、采购入库、生产入库、其它入库等类别,但在业务逻辑上都一样,在做两层的C/S的时候,我们可以只建一个数据模块,然后用一个私有数据成员保存单据类型。但在三层结构中,远程数据模块是无状态的,不可能维护这样一个私有变量。有必要区分不同的单据类型建立不同的对象或接口吗?可它们的业务逻辑都是一样的呀?我现在的做法是针对不同的单据类型,提供不同的方法供客户端调用,让客户根据单据类型取得相应的数据,这种做法合理吗?有哪些局限性?怎样处理才会比较合适?
望大家积极发言,可惜我一次只能给100分。

解决方案 »

  1.   

    windindance(风舞轻扬) :我认为这样让客户端知道了太多的服务器的细节,有违封装性的原则
      

  2.   

    delphi的客户端不能把一个自定义的对象传递到服务器端,也就是说,要在客户端用参数定制不同的服务端行为。这本身就是非常复杂和死板的了。
      

  3.   

    楼上,用数据集做参数的话。是自定义的吗?
    如果自己用ADO原生的RecordSet怎么做?前提是客户端不知道数据库的任何结构。
    可不可以告诉苹果。
      

  4.   

    客户端不知道数据库的任何结构?
    你用XML看看,把数据库结构封装在XML中
      

  5.   

    XML的效率一直是让我担心的,这样做当然好,不知一个二维数组是否可以做到
      

  6.   

    客房端不知道数据库的任何结构这句话说起来也许有些mian qiang 但,也的确是这样的,XML也不一定可以看的很清楚;嘻嘻;
      

  7.   

    InterfaceV = Interface;
    ....
    end;InterfaceV1 = Interface(TInterfacedObject,InterfaceV);
    ///// InterfaceV1 = Interface(TObject,InterfaceV);会不会更灵活呢??从系统效率上来说的话,我觉得是否可以提供相同的方法,不同的参数这种书法不是特别好的;以为这有失组件的特性;
    我赞成建立不同的接口(尺度自己可以把握);因为接口不象类那样;希望说的不是太错的:)
    1:可它们的业务逻辑都是一样的呀?这没有什么关系,
    InterfaceV = Interface;
    ....
    end;InterfaceV1 = Interface(TInterfacedObject,InterfaceV);
    2:提供不同的方法供客户端调用,让客户根据单据类型取得相应的数据,这种做法合理吗?
    考虑到以后,我觉得可以这样做的;
    3:远程数据模块是无状态的,不可能维护这样一个私有变量。
    和私有变量没有关系:)
    xixi 有人来了,不灌了
      

  8.   

    怎么好久不见楼主了那个事务控制的问题我已经解决了至于粒度嘛自己把握了 ,怎样合适怎样分,我们毕竟还是要用到midas的强劲功能啊所以我认为没必要太细
    小小啊 书什么时间能写成啊
      

  9.   

    “A use case instance is the performance of a sequence of actions specified in a use case.In the metamodel UseCaseInstance is a subclass of Instance. Each method performed by a UseCaseInstance is performed as an atomic transaction; that is, it is not interrupted by any other UseCaseInstance. An explicitly described UseCaseInstance is called a scenario.” 
    从这段描述可以看出,用例有粒度的概念,但是并不是说粒度可以有大小,而是说粒度大小合适不合适,因为用例的实例是原子的,是不可分的。 
    另外用例可以细化: 
    细化过程将完成定义所需要的所有用例。测试用例是否“充足”,主要是从适于驱动设计、实现和测试的确切程度上,判断用例集是否已经描述了所有使用系统的方式。 
    需要指出的是,用例详尽描述不是分解系统。也就是说,无需把一个较高层次的用例分解成多个用例。相反,我们需要找到更多详细的actor与系统交互。因此,用例详尽描述更接近于细化动作序列而不是把动作分层地分解成子动作。模型中经常会有一些简单得不需要事件流的详细描述的用例,只要一个梗概就够了。这样做的准则是,用户没有对用例的含义提出异议而设计人员和测试人员也认为这种简单格式提供的细节程度是恰当的。 
      

  10.   

    WangPeter(Peter) 我得做法是:
    用同一个业务对象(入库单);多个协调对象(各种入库单)。共同的操作写在业务对象中,特别的操作(比如数据校验)现在协调对象中。eastliangliang(青苹果)(拈花一笑万山横) 
    更正苹果以前传参数的说法。
    还是写开吧,共同的部分就再写一层,由上一层调用。ihihonline(小小->简单些再简单些,平淡些再平淡些
    我赞成建立不同的接口(尺度自己可以把握);以上三种意见基本一致,在三层结构中大家还是赞成对象往细里分此比较好。 
     
      

  11.   

    呵呵看来这个问题还是挺有代表性的啊基本上呢,就是要保证transaction Dm 在被从Pool中重新取出的时候,要使其能够恢复到初试状态,至于怎么做嘛,先卖个关子 呵呵你们自己先试试啊还有在服务器端必须用用Dcom来建立其他的远程数据模块
    这一点非常重要,当然用createinstance什么的应该也可以 但我没有试试试吧  
    解决了 告诉我一声 还有问题的话 我负责解决到底