asp.net - 关于编写 “flexible” API的想法？

Question

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

我有一个ASP.Net MVC应用程序，它在其中调用WCF服务以获取将要呈现的ViewModel。 (之所以使用WCF服务，是因为其他小型MVC应用也可能会调用这些ViewModel ...只是在内部，这不是公开可用的东西，因此我可以在服务的任何一边进行更改。想法是移动网站中的逻辑，更靠近服务器/数据库，因此往返的成本并不高-从Web服务器到数据库服务器的总往返仅进行一次。

我正在尝试找出从服务中返回这些“ViewModels”的最佳方法。有很多常见的功能，但是每个页面可能想要显示这些内容的不同子集(因此主页可能是表列表，下一页，表列表和可用的用户)。

那么，在Web服务不知道页面的情况下，返回页面所需信息的最佳方法是什么？

编辑:

有人建议我在下面处理逻辑。这会快很多，除非这是我们要远离的地方，因为它实际上要慢得多(在这种情况下)。这样做的原因是数据库位于一台服务器上，而webapp在另一台服务器上，并且webapp在某些方面特别健谈(有些页面最终可能会进行2K次往返-(我无法控制减少该操作建议在此数字之前))，因此将逻辑移近数据库是提高性能的第二个最佳方法。

Answer 1

我将考虑为每个MVC应用程序/ View 创建一个ViewModel。该服务可能只是从逻辑上返回“ View ”的最大数据量，并且每个MVC应用程序在为其 View 组成ViewModel时都会使用其所需的信息。

这样，您的服务仅负责一件事，返回特定于 View 功能的数据。每个应用程序的 Controller 负责使用/不使用返回的数据。

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

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;
    }
}