Question

我即将开发一个应该包含服务器和富客户端的小应用程序。到目前为止，我将遵循以下设计准则：

永远不会将域对象暴露给客户端
将服务消息封装到响应和请求对象
根据用例识别服务例程，以便它们始终是原子的

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

它们应该基于可重用的部分（例如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组合的一部分。

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

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

Answer 1

定义两个接口：客户端和服务器，以便协议和通信介质可以变化（例如，这对于仅使用内存缓冲区进行单元测试通信非常有用）。客户端界面可以非常简单（on_message（MESSAGE_ID，NUM_OPS，OPS））;

您可以为每个消息创建或生成（请参阅Google's protocoll buffers）一个类。然后从Message_ID创建MAP到消息对象。消息对象将验证消息并执行相对操作。

设计服务层的消息

1 个答案: