ViewModel类设计 - 应该在服务器端还是客户端?

时间:2017-01-17 00:42:12

标签: viewmodel

在我的应用程序中,我有一个View,它需要来自多个服务器端数据模型的数据。

我们有两种选择。

  1. 调用一次WebSevice并从服务器端获取ViewModel类对象并将其绑定到View。

  2. 调用多个WebServices并获取不同的服务器端模型类,并在客户端创建一个新的View Model Class并将其绑定到视图。

  3. 这两种选择中最好的方法是什么?请指教。

1 个答案:

答案 0 :(得分:0)

如果有疑问,请考虑您的用户体验。

从用户的角度来看,最令人沮丧的事情之一就是等待他们的应用在他们按下某些内容后做出回应。

每当您的应用向您的服务器发出请求时,用户都会遇到延迟 - 每次额外请求都会增加延迟时间。大多数典型用户对这类事情的容忍度非常低,然后才会感到烦躁,并将您的应用程序解密为“慢速”#34;

为了最大限度地减少内容加载所需的时间,请将客户端和服务器API之间的呼叫数量保持在最低限度 - 通常,呼叫越少越好。这很大程度上倾向于单一的ViewModel'方法

还要注意ViewModel有效负载的大小;当大部分数据转储永远不会被看到或使用时,不要向用户返回一个巨大的数据转储 - 这不仅会浪费带宽并使速度变慢,而且还意味着客户端将会做更多的事情不必要的工作

这对您的服务器也有好处;如果您的服务器需要满足更少的请求,那么在扩展应用程序以应对更多用户时,您将在以后做更少的工作。

最后,考虑一下简单的轻量级" dumb"客户端只负责演示和用户交互,而不是重量级客户端应用程序。

  • 通过让您的服务器负责生成ViewModel并完成所有艰苦工作,您可以避免客户端上的业务逻辑;因此,在业务和应用程序层之间保持清晰的分离。

  • 另一方面,如果您需要多个服务器API调用,那么您的客户端可能需要更多的复杂性来构建您的View模型,这可能会模糊线条在您的应用程序和业务层之间。

如果您最终构建多个调用同一服务器的不同客户端应用程序,您可能会发现自己需要在这些应用程序之间重用该业务逻辑;它可以更容易地重用已经存在于服务器上的业务逻辑 - 特别是如果您的客户端应用程序使用不同的技术(例如Web客户端和移动应用程序)。

相关问题