asp.net - AJAX Web 服务 - Web 或商务层的扩展？

Question

我的问题可能是一个微妙的问题:

Web 服务 - 它们是表示/Web 层的扩展吗？ ..或者它们是业务/数据层的扩展？

这可能看起来是个愚蠢的问题。 Web 服务是web 层的扩展。不过我不太确定。我正在构建一个非常标准的 Web 表单，具有一些 AJAX-y 功能，在我看来，我可以通过以下两种方式之一构建 Web 服务:

1. 他们可以为我检索数据(商业/数据层扩展)。
   示例:GetUserData(userEmail)
   其中 Web 表单上有 javascript，它知道如何使用用户数据并对标记进行更改
2. 它们可以返回完全渲染的用户控件(html；Web 层的扩展)
   示例:RenderUserProfileControl(userEmail)
   其中 Web 表单具有简单/愚蠢的 js，仅将 Web 服务 html 复制并粘贴到表单中

我可以看到它在任何一种情况下都有效，但我对不同的观点感兴趣......想法？

Answer 1

在我看来，网络服务有两个特征:

1. 它将数据暴露给外部源，即数据所在应用程序之外的其他源。在这个意义上我同意@Pete因为您并不是真正在设计 Web 服务；您正在设计一个帮助程序类，它以类似 Web 服务的方式响应请求。也许是一种语义上的区别，但事实证明它对我很有用。
2. 它以可供多个消费者重复使用的格式返回数据(并且仅返回数据)。对我来说，这就是您的“为什么不#2”问题的答案 - 如果您返回类似 Web 控件的结构，那么您就限制了 Web 服务对其他潜在调用者的有用性。他们必须以您返回数据的方式呈现数据，并且不能选择以其他方式表示数据，这会最大限度地降低整个服务的有用性(和重用性)。

综上所述，如果您真正关注的是一个像 Web 服务一样响应的帮助程序类，并且您只打算在这个用例中使用它，那么您可以做任何您喜欢的事情，以及您的情况#2 将起作用。但从我的 Angular 来看，它打破了职责分离；您将数据访问和渲染功能组合在同一个类中。我怀疑，即使您不关心 MVC 模式，选项 #2 也会使您的类更难维护，而且您肯定会限制它们 future 对您的用处；如果您想要访问相同的数据但以不同的方式呈现它，您需要重构。