DTO模式只有在与一些缓存或MVVM结合使用时才有用

本文关键字：结合 MVVM 有用 缓存 模式 DTO | 更新日期: 2023-09-27 18:03:20

这个问题不是要与设计争论，而是要理解如何充分利用这种设计模式。现在，总结一下，我从ServiceStack的设计文档中得出的结论是，使用粗粒度系统(DTO模式)减少了来自服务器的往返，以及其他好处，如小的服务表面积等。

然而，它回避了一个问题，如果我真的想利用服务堆栈服务作为客户端返回给我的粗粒度响应DTO，我需要尽可能地重用它。在去服务器获取数据之前，我必须在客户端检查该对象是否存在。如果我不这样做，那么我就没有充分利用设计，我可以更好地使用像WebAPI这样的东西，它需要我每次都去服务器。

现在，有几个问题

  1. 我的评估是，当没有与适当的重用机制相结合时，粗粒度DTO模式没有得到最佳使用或使用不足?
  2. 这几乎听起来像一个MVVM客户端(Angular, Knockout)，它将对象绑定到一个视图模型上，以便反复使用，这是一个理想的设计。将MVVM客户端与ServiceStack DTO服务相结合是一种常见的做法吗?
  3. 如果DTO模式在具有高度动态数据的环境中使用该怎么办?例如，为用户对象使用DTO，同时在每次服务调用时将用户和他的游戏点数带到，希望在GamePoints每秒变化时重用用户数据和他的GamePoint属性。在我们带来数据的那一刻，它是陈旧的，DTO模式在这种环境中仍然相关吗?

DTO模式只有在与一些缓存或MVVM结合使用时才有用

返回粗粒度响应不应该对您在客户端上使用的客户端技术或视图模式有任何影响，也就是说，它不会强迫您在客户端上维护缓存。

在单页应用中，我将使用ServiceStack的TypeScript添加ServiceStack引用来获取填充在类型响应dto中的响应，我将直接在客户端状态中维护这些响应。

Gistlyn代码库展示了这样的例子，它使用通用的JsonServiceClient和TypeScript DTO来制作API端到端的类型化API请求，就像你使用任何其他ServiceStack支持的类型化客户端一样(这是ServiceStack的网关/DTO/Facade方法的一个好处，无论使用哪种语言，API请求都是相同的)。

下面是一个典型的例子，它从一个实时运行的c#脚本中获取所有的变量信息，并将它们直接加载到Redux Store中:

const client = new JsonServiceClient("/");
const request = new GetScriptVariables();
request.scriptId = state.activeSub.id;
client.get(request)
    .then(r => {
        store.dispatch({ type: "VARS_LOAD", variables: r.variables });
    });

然后，为了渲染视图，我只需使用TypeScript装饰器将Redux中维护的状态直接注入React Components属性中，例如:

@reduxify(
    (state) => ({
        inspectedVariables: state.inspectedVariables,
    })
)
class App extends React.Component<any, any> { ... }

所以我直接使用来自填充dto的数据，而不是将它们映射到任何临时客户端视图模型。所以我甚至不需要创建客户端视图模型，因为它们是由TypeScript的Add ServiceStack Reference自动生成的。

在(非TypeScript) JavaScript数据库中，JSON Response作为一个普通的JavaScript对象返回，我将像上面一样直接使用它，唯一的区别是不需要访问TypeScript的Type Safety来进行数据访问。

一些MVVM框架更喜欢一个单独的视图模型，但这是独立的，如果你使用ServiceStack或不使用，使用ServiceStack的好处是，它提供了一个类型化的DTO映射到你的客户端视图模型，给你类型安全的好处。

相关文章：