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

Web服务是表示/ Web层的扩展吗？ ..或者它们是biz / data层的扩展？

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

• 他们可以为我检索数据(biz /数据层扩展)。示例：" GetUserData(userEmail)"，其中，Web表单上具有JavaScript，该javascript知道如何使用用户数据并更改标记
• 他们可以返回完全呈现的用户控件(html； Web层扩展)示例：RenderUserProfileControl(userEmail)，其中Web表单具有简单/笨拙的js，仅将Web服务html复制并粘贴到表单中

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

解决方案

我肯定不会说＃2，但是＃1是有效的。

我还认为(这是观点)Web服务作为数据访问层并不理想。该服务必须具有更多的价值(总的来说，我敢肯定有很多例外)。

即使在场景1中，该服务也将呈现数据层中可用的数据，而不是数据层本身的一部分，只是它以不同于UI格式(即JSON，xml等)的格式呈现数据。 )

关于我将使用哪种方案，我将选择方案＃1，因为该服务可在其他Web表单和其他方案中重用。

虽然通常使用＃1(而不是＃2)(正确的方法是仅将视图层所需的数据公开并在其中处理所有标记)，但是在设计中请谨慎使用服务的Web部分。

如果要远程使用数据，则仅应将其作为Web服务(SOAP / WSDL，REST)公开(某些SOA架构师可能会争论这一点，但我认为这超出了此问题的范围)，否则我们可能会这样做太多，并过度设计了请求和响应格式。使用对应用程序有意义的Ajax框架，可以促进客户端/服务器之间的通信并抽象出通信的基本格式可能会很有帮助。重要的是很好地封装用于检索所需数据的代码(可以将其称为服务，但可能只是一个写得很好的助手类)，以便可以重用它，然后将该数据公开到任何内容中方式对于给定的应用程序最有意义。

在我看来，Web服务具有2个特征：

• 它将数据公开给外部资源，即它们所驻留的应用程序以外的其他资源。在这种意义上，我同意@Pete的观点是，我们并不是在真正设计Web服务。我们正在设计一个帮助程序类，该类以类似于Web服务的方式响应请求。也许是一种语义上的区别，但事实证明对我有用。
• 它以可被多个使用者重用的格式返回数据(并且仅返回数据)。对我来说，这就是我们"为什么不是第二个"问题的答案-如果我们返回类似Web控件的结构，则将Web服务的有用性限制于其他潜在的调用者。他们必须以返回数据的方式显示数据，并且不能选择以其他方式表示数据，这会将整个服务的有用性(和可重复使用性)降到最低。

所有这些都说明了，如果我们真正要看的是一个像Web服务一样响应的帮助程序类，并且我们只打算在这个用例中使用它，那么我们可以做任何我们想做的事，而案例2将工作。但是，从我的角度来看，它打破了责任分离；我们正在将同一类中的数据访问和呈现功能结合在一起。我怀疑即使我们不关心MVC模式选项＃2也会使类难以维护，并且我们肯定会限制它们将来对用处。如果我们想访问相同的数据但呈现不同的数据，则需要进行重构。