当我试图描述我在研究论文中构建的系统时，我在尝试表示我创建的系统的复杂性时遇到了以下符号问题：
- 假设我设计服务 A，仅通过其 RESTful 端点与世界通信。然后，我设计服务 B，它使用服务 A 作为其主干，并将其数据表示给外部世界。
- 假设服务 A 有自己的模型和数据控制器。那么，是否应该将 RESTful 端点概念化为 MVC 模式中的视图？
- 假设服务 B 有自己的一组代理模型，这些模型或多或少直接映射服务 A 的模型。它为用户提供一组 GUI 视图，以及一组完全独立的控制器。服务 A 在 MVC 中的位置？它应该表示为封装模型吗？
真实世界的例子（与我正在处理的问题无关）将是：
- del.icio.us 和 pinboard.in 提供大致相似的 API 集，因此可以作为服务客户端的服务 A 交换（出于问题的目的，假设它们都是基于 MVC 模式构建的，但可能具有完全不同的模型和控制器集）
- Delibar 是一个 iOS 应用程序，因此遵循 MVC 架构并匹配服务 B 的要求;假设 Delibar 在 API 端点中表示的服务 A 的数据模型之后对其数据进行建模。
因此，pinboard.in 和 del.icio.us 是Delibar的典范吗？RESTful 端点是视图吗？因此，pinboard.in 和 del.icio.us 的观点集是否相同？
端点是控制器上的操作/操作。视图是控制器为响应 HTTP GET 请求而返回的数据（HTML、XML、JSON 或其他）。
服务A 不表示为服务 B 的 MVC 三元组的一部分，因为 MVC 处理针对模型的交互和控制器对视图的选择。通过服务 B 的数据访问层访问服务 A。如果使用"活动记录"模式，则服务 B 中的控制器对模型的查询或更改将由模型本身传递到数据访问层。如果您使用的是域服务/数据映射器/存储库模式，控制器将调用封装数据访问的此层。