设计：网站在同一台机器上调用 web 服务答案

【问题标题】：Design: Website calling a webservice on the same machine设计：网站在同一台机器上调用 web 服务
【发布时间】：2011-01-30 11:57:58
【问题描述】：

更多的是设计/概念问题。

在工作中，我们决定通过 Web 服务调用我们的数据访问层。因此，我们的网站会调用 Web 服务来获取进出数据库的任何/所有数据。网站和 Web 服务都将在同一台机器上（因此不会跨线），但数据库在单独的机器上（因此无论如何都需要跨线）。这都是内部的，网站、网络服务和数据库都在同一家公司内（AFAIK，网络服务不会被另一方重用）。

据我所知：网站将打开一个连接到 Web 服务的端口，而 Web 服务将依次打开另一个端口并通过网络连接到数据库服务器以获取/提交数据。无法避免跨越电线的行程，但我担心站在中间的 Web 服务。

我同意功能之间需要有不同的层（例如业务层、数据访问层等），但这对我来说似乎过于复杂。我也感觉到会有一些性能问题。

在我看来，最好在解决方案中直接引用 (DAL) 程序集，从而否定第一个端口到端口的连接。

任何支持和反对这个想法的想法（或链接）都将不胜感激

附：我们是 .NET 商店（从 vb 迁移到 C# 3.5）

编辑/更新将 Dathan 标记为答案，我还没有完全卖掉（我仍然有点犹豫不决，虽然倾斜它可能没有我担心的那么糟糕），他提供了一个深思熟虑的答案。我感谢所有的反馈。

【问题讨论】：

不要将 Web 服务用作 DAO 的链接。这对您的代码以及您的 Web 服务器的性能造成重大影响。为什么要添加该层？所以你可以使用 AJAX 调用来访问 DAO？您真的希望您的 UI 直接与您的 DAO 对话吗？糟糕的举动，恕我直言

标签： c# web web-services

【解决方案1】：

两种设计（应用程序到 Web 服务到数据库；应用程序到数据库通过 DAL）都是非常标准的。在与客户端交互时，通常使用 Web 服务来标准化数据访问的语义。 Web 服务通常能够比底层持久存储更准确地表示数据模型的语义，因此通过抽象和封装 IO 特定的关注点来帮助系统的可维护性。 Web 服务还具有额外的目的，即通过通常可跨防火墙访问的协议为您的数据提供公共接口（尽管“公共”可能仍指公司内部）。当使用 DAL 直接连接到数据库时，可以以类似的方式封装数据 IO 关注点，但最终您的客户端必须直接访问数据库。通过将 IO 限制为明确定义的语义（通常是 CRUD+Query），您可以添加额外的安全层。这对您来说没什么大不了的，因为您正在运行一个 Web 应用程序 - 所有数据库访问都已经从受信任的代码完成。不过，Web 服务确实提高了对 SQL 注入的鲁棒性。

抛开所有网络服务的理由，真正的问题是：

将使用多少？ 网站/网络服务/数据库格式确实对网络服务器施加了稍高的开销 - 如果网站受到重创，您需要在投入之前仔细考虑同一台机器上的另一个服务。否则，增加的小效率低下可能没什么大不了的。另一方面，如果网站受到重创，您可能无论如何都希望水平扩展，并且应该能够同时扩展 Web 服务。

您能获得多少？ 拥有 Web 服务的重要原因之一是为客户端代码提供数据可访问性 - 特别是在需要支持多个可能的应用程序版本时。由于您的 Web 应用程序是使用 Web 服务的唯一客户端，因此这不是问题 - 实际上，自行对应用程序进行版本控制可能更省力。

你想要扩展吗？你说它可能永远不会被除单个 Web 应用程序之外的任何客户端使用，但这些东西有办法扩大规模。如果您的 Web 应用程序的范围或受欢迎程度有可能增长，请考虑 Web 服务。通过围绕 Web 服务进行设计，您已经瞄准了模块化、多主机解决方案，因此您的应用可能会随着成长的痛苦而扩展。

如果你猜不到，我是网络服务爱好者。但以上也是我对这个主题的诚实（如果有些偏见）的看法。如果你真的走 web 服务路线，一定要简单——把应用程序逻辑保留在应用程序中，将服务逻辑保留在服务中，并在扩展两者时尝试在它们之间划清界限。并设计您的服务以提高效率并配置托管以使其尽可能平稳地运行。

【讨论】：

@Dathan：为什么 Web 服务比具有与 Web 服务相同接口的 DAO 更有帮助？此外，我可能不希望我的客户访问我在应用程序中使用的相同数据访问权限。我可能想保留某些操作，甚至数据库的整个部分，供我自己使用，而不是将它们暴露给客户。
@John 我在回答中指出，就接口和职责分离而言，Web 服务和设计良好的进程内 DAL 之间没有实际区别。根据我的经验，Web 服务的扩展性更好。对于功能，我假设“不向我的客户公开它们”是指您要发布缺少这些功能的 DAL？ Web 服务通过身份验证和授权提供相同的功能。您可以通过授权限制已发布的元数据和实际可访问的功能，而无需维护 DAL 的两个不同版本。 FTW。（C：
@Dathan：我提供给客户的数据视图可能与我在我的网站上使用的不同。我的 DAL 显然会为我提供我需要的一切。在规模方面，考虑到相同数量的实际数据库服务器，我希望看到服务与等效 DAL 之间差异的数字。
@John 如果您想控制通过 Web 应用程序为客户提供的数据视图，那很好。表示/控制器逻辑非常适合该目的 - 甚至可能比在服务层控制数据模型视图凭据更好。我喜欢扩展到 Web 服务提供的胖客户端/服务器模型的可能性，虽然 - 超出了 OQ 的范围，但 IMO 是 Web 应用程序的获胜功能之一。
@John 就数字而言，如果您只是增加服务器上的负载，您会发现 - 正如您显然预期的那样 - app/service/db 版本瓶颈早于 app/dal /db 版本。但是，IO 逻辑通常是一个瓶颈，围绕 Web 服务中间层构建可以让您通过将 Web 服务迁移到另一个盒子，甚至跨多台机器和负载平衡来更好地进行水平扩展。这就是我所说的更好扩展的意思。

【解决方案2】：

这是一个有问题的设计，但您的商店并不是唯一使用它的人。

由于您使用的是 .NET 3.5 并在同一台机器上运行，因此您应该将 WCF 与 netNamedPipesBinding 一起使用，它仅在同一台机器上使用命名管道上的二进制数据传输。这应该会在一定程度上缓解性能问题。

【讨论】：

【解决方案3】：

我喜欢这个想法，因为它为您提供了灵活性。我们使用了一种非常相似的方法，因为我们可以使用不止一种类型的数据库来存储我们的数据（MSSQL 或 Oracle），具体取决于我们的客户安装选择。

如果客户选择不使用我们的前端网站，它还可以让他们连接到我们的数据库。因此，我们无需付出额外的努力即可获得一个开放的 API。

如果速度是您最关键的问题，那么您必须减少层数。但是在大多数情况下，您的 Web 服务处理来自数据库的请求所花费的时间不会增加分配的时间。（这是假设你正确地做你的 Web 服务层，如果你不看它，你很容易让它变慢。）

【讨论】：

嗯，您可以拥有不止一种类型的数据库，而无需使用这种 Web 服务额外层方法。
+1 此外，这使应用程序更易于扩展；如果需要，可以很容易地分离这些层，甚至可能在它们之间添加一些负载平衡。
@systempuntoout 是的，你可以。尤其是 NHibernate，但我们没有得到快速的 API，这是服务的主要原因。