使用 Web 服务作为 .NET 中数据访问层的接口答案

【问题标题】：Using a webservice as an interface for a data access layer in .NET使用 Web 服务作为 .NET 中数据访问层的接口
【发布时间】：2010-10-16 02:00:19
【问题描述】：

我目前正在为学校做一个CRUD 项目，基本上他们希望我们有这种结构（3 个项目）：

这基本上意味着我们不能直接从网站访问类库：

Website
       \
        \
         Web Service
                    \
                     \
                      Class Library

当然，现在有多种解决方案可供选择，以便在 Web 服务中提供抽象以分离例如检索文章的方法和检索类别的方法（它们是两个不同的实体，并且在类中有两个单独的类库）：

我可以做一个包含所有方法（GetAllArticles、GetAllCategories、GetArticleByID 等）的 Web 服务，并且该网站只引用这个 Web 服务。但这当然会导致所有方法都在一个类中（即一个 Web 服务）
或者我可以创建多个 Web 服务（Articles.asmx、Categories.asmx 等...）并从网站上引用所有这些服务，然后根据我需要检索的数据调用我需要的服务。

但我的意思是，上述解决方案并不理想，因为如果我有第一个解决方案，我将在一个类中拥有大量方法（没有任何抽象），而在第二个解决方案中，我将不得不参考网站上大约 10 种不同的网络服务（一种用于文章，一种用于分类等）

在学校，他们告诉我们使用 Web 服务（或多个 Web 服务）访问类库，然后使用 Web 方法从类库中检索数据，但我前面提到的两种解决方案似乎都有些不靠谱。

有没有更好的方法来实现这个结构？

【问题讨论】：

【解决方案1】：

在您的示例中，您建议为文章提供一项服务，为类别建议一项服务。这当然可能只是一个例子，但在这种情况下，将它们分开是没有意义的，因为查询和/或例程同时使用类别数据和文章数据是很可能和常见的。

考虑到这一点，通常最有意义的做法是将例程按彼此相关的程度进行分组。如果您可以将所有可能的例程分成三个几乎没有重叠的干净组，那么拥有三个服务是有意义的。如果您无法完全分离任何例程，则应将自己限制为一个 Web 服务。

但是关于你的陈述“没有抽象”是一个网络服务的缺点 - 这不一定是真的。您始终可以在 Web 服务背后创建抽象层，以便服务类本身只是一个包含许多瘦方法调用的外观，这些方法调用在其他地方进入更庞大的逻辑。

最后，唯一真正重要的方法是：尽可能采用最简单的方法，仅在几层中构建您需要构建的东西尽你所能;仅当您遇到无法以比增加复杂性更好的方式解决的问题时才增加复杂性。增加复杂性总是比消除复杂性更容易。

【讨论】：

【解决方案2】：

我会将所有网络方法放在同一个类中。 webmethods 应该只是您业务类的包装器以及您需要的任何输入验证和授权。

由于 Web 服务通常由机器而不是人类使用，因此没有迫切需要层次结构。如果您为每个业务类创建一个 webmethod 类，管理 URL 和 Web 服务器可能会成为一种负担。

如果您计划使用浏览器自动生成的 HTML 页面来调用您的 Web 服务作为您的主要用户界面，您需要小心一点。例如，如果您需要对请求进行身份验证，您将无法依赖 SOAP 标头。

【讨论】：

【解决方案3】：

为什么不使用 ADO.Net 数据服务？

【讨论】：