【发布时间】: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