为服务层设计消息

我即将开发一个应该由服务器和富客户端组成的小应用程序。到目前为止，我将遵循以下设计原则：为服务层设计消息

从未暴露域对象到客户端
封装服务消息响应和请求对象
识别基于用例的服务程序，使他们总是原子

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

它们应该基于可重用的部分（例如数据对象，如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支持。

来源

2010-10-27 agent_harris

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

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

来源

2010-10-29 03:23:31 fabrizioM

我的问题不在于我不了解这种通信系统的基本思想。客户端和服务器接口以及使用消息至今都是绝对清晰的。我的重点实际上在于设计消息对象层次结构 – 2010-10-29 11:47:50

也许我需要一个关注您的具体示例，但我认为具有平坦的消息层次结构是最好的。您可以从包含每个消息对象所需字段的纯文本中自动生成所有相关消息描述。 – fabrizioM 2010-10-29 18:27:05

我编辑了我的原始文章，并试图提供一个更好的例子，我的意思是。 – 2010-10-30 09:27:50

为服务层设计消息

回答

相关问题