关于编写“灵活”API 的想法？

Question

我在这里可能有错误的“模式”，但我认为这是一个公平的话题。

我有一个 ASP.Net MVC 应用程序，它在其中调用 WCF 服务以取回将要呈现的 ViewModel。 （它使用 WCF 服务的原因是，其他小型 MVC 应用程序也可以调用这些 ViewModel ......仅在内部，它不是公开可用的东西，所以我可以更改服务的任何一方。这个想法是移动网站中的逻辑，更靠近服务器/数据库，因此往返成本不高 - 从网络服务器到数据库服务器的整体往返仅一次）。

我正在尝试找出从服务中返回这些“ViewModel”的最佳方法。有许多常见的小功能，但每个页面可能希望显示这些内容的不同子集（因此主页可能是表格列表、下一页、可用表格和用户列表）。

那么返回页面所需信息的最佳方式是什么，希望网络服务不知道该页面？

编辑：

下面有人建议我移动正在处理的逻辑。这会快得多，除了我们要远离的地方，因为它实际上要慢得多（在这种情况下）。原因是数据库在一台服务器上，而 webapp 在另一台服务器上，并且 webapp 在某些时候特别健谈（有些页面最终可能会进行 2K 往返 - （我无法控制减少这个建议之前的数字）），因此将逻辑移近 db 是使其性能更高的下一个最佳方法。

Answer 1

我会考虑为每个 MVC 应用程序/视图创建一个 ViewModel。从逻辑上讲，该服务可以只为“视图”返回最大数量的数据，并且每个 MVC 应用程序在为它的视图编写 ViewModel 时都会使用它想要的信息。

您的服务只负责一件事，即返回特定于视图功能的数据。每个应用的控制器负责使用/不使用返回的数据。

这将更加灵活，因为您的 ViewModel 也可能需要不同的验证规则。 ViewModel 还具有 MVC 特定的需求（SelectList 等），这些需求实际上不应该由服务层返回。似乎可以一目了然地共享某些内容，但通常存在许多小的差异，这使得共享 ViewModel 成为一个坏主意。

class MyServiceViewResult
{       
    public int SomethingEveryViewNeeds { get; set; }
    public bool OnlyOneViewMightNeedThis { get; set; }
}

class ViewModel1
{
    public int IdProperty { get; set; }

    public ViewModel1(MyServiceViewResult result)
    {
        IdProperty = result.SomethingEveryViewNeeds;
    }
}

class ViewModel2
{
    public int IdProperty { get; set; }
    public bool IsAllowed { get; set; }

    public ViewModel2(MyServiceViewResult result)
    {
        IdProperty = result.SomethingEveryViewNeeds;
        IsAllowed = result.OnlyOneViewMightNeedThis;
    }
}

Answer 2

您为什么不直接将服务实现为封装所需功能的可重用库，而不是拥有 Web 服务？

这也将允许您使用 多态性 来实现自定义。 WCF 不以灵活的方式支持多态性...

使用进程内服务也会快很多。

有关多态解决方案的概述，请参阅此相关问题：Is this a typical use case for IOC?