关于写“灵活”的思考API？

发布于 2024-09-03 19:51:59 字数 598 浏览 3 评论 0原文

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

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

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

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

编辑：

下面建议我移动进程中的逻辑。这会快得多，但我们要远离它，因为它实际上要慢得多（在本例中）。原因是数据库位于一台服务器上，而 Web 应用程序位于另一台服务器上，并且 Web 应用程序在某些时候特别健谈（有些页面最终可能会进行 2K 往返 - （我无法控制减少此次数）建议之前的数字）），因此将逻辑移近数据库是提高其性能的下一个最佳方法。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

混浊又暗下来 2024-09-10 19:51:59

我会考虑为每个 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;
    }
}

I would look at creating a ViewModel per each MVC app/view. The service could just return the maximum amount of data for the "view" in a logical sense and each MVC app uses the information it wants when composing the ViewModel for it's view.

Your service is then only responsible for one thing, returning data specific to a view's function. The controller of each app is responsible for using/not using pieces of the returned data.

This will be more flexible as your ViewModels may require different validation rules as well. ViewModels also have MVC-specific needs(SelectList etc..) that shouldn't really be returned by a service layer. It seems like something can be shared at a glance, but there are generally lots of small differences that make sharing ViewModels a bad idea.

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

回复收藏 0 原文