ViewModel Class 设计 - 应该在服务器端还是客户端？
ViewModel Class Design - Should it be on Server Side or Client Side?
在我的应用程序中，我有一个视图，它需要来自多个服务器端数据模型的数据。
我们有两个选择。
调用一次单一 WebSevice 并从服务器端获取 ViewModel class 对象并将其绑定到视图。
调用多个 WebServices 并获取不同的服务器端模型 Classes 并在客户端创建一个新的视图模型 Class 并将其绑定到视图。
这两个选项中最好的方法是什么？请指教
如有疑问，请考虑您的用户体验。
从用户的角度来看，最令人沮丧的事情之一是在他们按下某些内容后等待您的应用响应。
每次您的应用向您的服务器发出请求时，用户都会遇到延迟 - 每个额外的请求都会增加延迟的时间。大多数典型用户在被激怒并谴责您的应用 "slow" 之前，对这类事情的容忍度非常低。
为了尽量减少加载内容所需的时间，请将客户端和服务器之间的调用次数 API 保持在绝对最低限度 - 通常，调用越少越好。这严重倾向于 'single request, single ViewModel' 方法。
还要注意 ViewModel 负载的大小；不要只是 return 一个巨大的 data-dump 给你的用户，因为其中大部分永远不会被看到或使用 - 这不仅会浪费带宽并使速度变慢，而且还意味着客户端正在运行做额外的不必要的工作。
这对您的服务器也有好处；由于您的服务器需要满足的请求更少，因此以后在扩展您的应用程序以应对更多用户时，您要做的工作就会更少。
最后，考虑仅负责演示和用户交互的简单轻量级 "dumb" 客户端与 heavy-weight 客户端应用程序之间的区别。
通过让您的服务器负责生成 ViewModel 并完成所有艰苦的工作，您可以避免客户端上的业务逻辑；因此保持业务层和应用层之间的清晰分离。
另一方面，如果您需要多个服务器 API 调用，那么很可能您需要在客户端上增加很多复杂性来构建您的视图模型，这有模糊的风险您的应用程序和业务层之间的界限。
如果您最终构建了多个调用同一服务器的不同客户端应用程序，您可能会发现自己需要 re-use 这些应用程序之间的业务逻辑； re-use 服务器上已经存在的业务逻辑更容易 - 特别是如果您的客户端应用程序使用不同的技术（例如 Web 客户端和移动应用程序）。
在我的应用程序中，我有一个视图，它需要来自多个服务器端数据模型的数据。
我们有两个选择。
调用一次单一 WebSevice 并从服务器端获取 ViewModel class 对象并将其绑定到视图。
调用多个 WebServices 并获取不同的服务器端模型 Classes 并在客户端创建一个新的视图模型 Class 并将其绑定到视图。
这两个选项中最好的方法是什么？请指教
如有疑问，请考虑您的用户体验。
从用户的角度来看，最令人沮丧的事情之一是在他们按下某些内容后等待您的应用响应。
每次您的应用向您的服务器发出请求时，用户都会遇到延迟 - 每个额外的请求都会增加延迟的时间。大多数典型用户在被激怒并谴责您的应用 "slow" 之前，对这类事情的容忍度非常低。
为了尽量减少加载内容所需的时间，请将客户端和服务器之间的调用次数 API 保持在绝对最低限度 - 通常，调用越少越好。这严重倾向于 'single request, single ViewModel' 方法。
还要注意 ViewModel 负载的大小；不要只是 return 一个巨大的 data-dump 给你的用户，因为其中大部分永远不会被看到或使用 - 这不仅会浪费带宽并使速度变慢，而且还意味着客户端正在运行做额外的不必要的工作。
这对您的服务器也有好处；由于您的服务器需要满足的请求更少，因此以后在扩展您的应用程序以应对更多用户时，您要做的工作就会更少。
最后，考虑仅负责演示和用户交互的简单轻量级 "dumb" 客户端与 heavy-weight 客户端应用程序之间的区别。
通过让您的服务器负责生成 ViewModel 并完成所有艰苦的工作，您可以避免客户端上的业务逻辑；因此保持业务层和应用层之间的清晰分离。
另一方面，如果您需要多个服务器 API 调用，那么很可能您需要在客户端上增加很多复杂性来构建您的视图模型，这有模糊的风险您的应用程序和业务层之间的界限。
如果您最终构建了多个调用同一服务器的不同客户端应用程序，您可能会发现自己需要 re-use 这些应用程序之间的业务逻辑； re-use 服务器上已经存在的业务逻辑更容易 - 特别是如果您的客户端应用程序使用不同的技术（例如 Web 客户端和移动应用程序）。