【问题标题】:Designing Messages for Service Layer为服务层设计消息
【发布时间】:2010-10-27 14:02:21
【问题描述】:

我即将开发一个应该由服务器和富客户端组成的小型应用程序。 到目前为止,我将遵循以下设计准则:

  • 永远不要向客户端公开域对象
  • 将服务消息封装到响应和请求对象中
  • 根据用例识别服务例程,使它们始终是原子的

我真正的问题(与语言无关)是我不知道在消息设计(响应和请求对象)方面做出什么决定。

它们应该基于可重复使用的部分(例如,像 CustomerDTO 或 CustomerData 这样的数据对象)还是应该每条消息都是单独的;可能使用嵌套类来获取详细信息和嵌入项)。

我知道并非每个用例都需要甚至允许显示或更改所涉及实体的所有属性,因此导致设计中的多个消息应该是一组封闭的类。

你有什么建议?

最好的问候,

agent_harris

编辑:

举一个更详细的例子。

假设我们有以下接口:

interface CustomerService {

    /**
     * this use-case should return all necessary data to
     * edit a customer record, including the associated 
     * invoice/delivery addresses
     */

    CustomerRecordResponse getUserRecord(int userId);

}

现在的问题是如何以这种方式编写 CustomerRecordResponse,它的组件 可重用,但不会为其他可能无法使用的用例透露太多信息 允许访问或更改特定属性。

我的一个想法是引入可以在必要时扩展的小类。 例如:

class CustomerData {

    private String firstName;
    private String lastName;

    // ...
}

这基本上只是一组属性(一个平面对象)。 现在,当涉及到以原子方式编辑完整记录时,包括地址选项 可能是将 CustomerData 类(可能在本地作为嵌套类)扩展为:

class CustomerRecordResponse {
    // nested class:
    class ExtendedCustomerData extends CustomerData {
        private AddressCountryData[] addresses;
    }
}

在这里我会看到我可以重用基本类型的组件来喂养的优势 一个已经存在的 UI 小部件,它可能是 UI 组合的一部分。

否则,在设计完全独立的平面消息对象时,所有数据都会发散,并且双方都需要大量开销。

然而,我的目标是设计一个客户端/服务器应用程序,该应用程序已在第一阶段明确实施 采用同构技术(.NET Remoting 或 Java RMI),但可以轻松启用 SOAP 支持。

【问题讨论】:

    标签: architecture service message dto


    【解决方案1】:

    定义两个接口:客户端和服务器,以便协议和通信媒介可以变化(这对于仅使用内存缓冲区对通信进行单元测试很有用)。 客户端接口可以很简单(on_message(MESSAGE_ID, NUM_OPS, OPS));

    对于每条消息,您可以创建或生成(参见Google's protocoll buffers)一个类。 然后创建一个从 Message_ID 到消息对象的 MAP。 消息对象将验证消息并执行相关操作。

    【讨论】:

    • 我的问题不是我不理解这种通信系统的基本概念。到目前为止,客户端和服务器接口以及使用消息是绝对清楚的。我的重点实际上在于设计消息对象层次结构
    • 也许我需要一个具体的例子来说明你的担忧,但我认为扁平的消息层次结构是最好的。您可以从包含每个消息对象所需字段的纯文本中自动生成所有相关消息描述。
    • 我已经编辑了我的原始帖子,并试图提供一个更好的例子来说明我的意思。
    猜你喜欢
    • 1970-01-01
    • 2015-06-21
    • 2011-06-16
    • 2017-01-31
    • 2013-01-15
    • 1970-01-01
    • 2012-11-26
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多