Question

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

我有一个ASP.Net MVC应用程序，它调用WCF服务来获取将要呈现的ViewModel。（它使用WCF服务的原因是其他小型MVC应用程序也可以为这些ViewModel调用...仅在内部，它不是公开可用的东西所以我可以改变服务的任何一方。任务是移动网站中的逻辑，更接近服务器/数据库，因此往返不是那么昂贵 - 并且只从Web服务器到数据库服务器进行一次往返。）

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

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

修改

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

Answer 1

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

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

这将更加灵活，因为您的ViewModel也可能需要不同的验证规则。 ViewModels也有特定于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?

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

2 个答案: