更多的是设计/概念问题。
在工作中，我们决定通过网络服务调用我们的数据访问层。因此，我们的网站会为进出数据库的任何/所有数据调用网络服务。网站和 Web 服务都将在同一台机器上(因此不会跨网)，但数据库在单独的机器上(因此无论如何都需要跨网)。这都是内部的，网站、网络服务和数据库都在同一家公司内(据我所知，网络服务不会被另一方重复使用)。
据我所知:该网站将打开一个端口到 web 服务，然后 web 服务将打开另一个端口并通过网络连接到数据库服务器以获取/提交数据。跨越电线的旅程是不可避免的，但我担心站在中间的网络服务。
我同意功能之间需要有不同的层(例如业务层、数据访问层等)，但这对我来说似乎过于复杂。我还感觉到 future 会出现一些性能问题。
在我看来，最好在解决方案中直接引用 (DAL) 程序集，从而取消第一个端口到端口的连接。
任何支持和反对这个想法的想法(或链接)都将不胜感激
附言我们是一家 .NET 商店(从 vb 迁移到 C# 3.5)
编辑/更新 将 Dathan 标记为答案，我仍然没有完全卖掉(我仍然有点犹豫，虽然倾斜它可能没有我担心的那么糟糕)，他提供了一个深思熟虑的答案。我感谢所有反馈。
最佳答案
两种设计(应用程序到 Web 服务再到数据库；应用程序到数据库通过 DAL)都非常标准。在与客户端交互时，通常会使用 Web 服务来标准化数据访问的语义。与底层持久存储相比，Web 服务通常能够更准确地表示数据模型的语义，因此通过抽象和封装特定于 IO 的关注点有助于系统的可维护性。 Web 服务还有一个额外的目的，即通过通常可跨防火墙访问的协议(protocol)为您的数据提供一个公共(public)接口(interface)(尽管“公共(public)”可能仍然意味着您的公司内部)。当使用 DAL 直接连接到数据库时，可以以类似的方式封装数据 IO 问题，但最终您的客户端必须直接访问数据库。通过将 IO 限制为定义明确的语义(通常是 CRUD+Query)，您可以添加额外的安全层。这对您来说不是什么大问题，因为您运行的是 Web 应用程序 - 所有数据库访问都已通过受信任的代码完成。不过，Web 服务确实提高了对 SQL 注入(inject)的鲁棒性。
抛开所有网络服务的理由，真正的问题是:
它会被使用多少？ 网站/网络服务/数据库格式确实会给网络服务器带来稍微高一些的开销 - 如果网站受到重创，您需要在投入之前考虑很长时间同一台机器上的另一个服务。否则，增加的小的低效率可能不是什么大问题。另一方面，如果站点受到重创，您可能仍然希望水平扩展，并且您应该能够同时扩展 Web 服务。
您能获得多少 yield ？拥有 Web 服务的重要原因之一是为客户端代码提供数据可访问性 - 特别是在需要支持多个可能的应用程序版本时。由于您的 Web 应用程序是唯一使用 Web 服务的客户端，因此这不是问题 - 实际上，自行对应用程序进行版本控制可能更省力。
您想要扩展吗？您说它可能永远不会被除单个 Web 应用程序之外的任何客户端使用，但这些东西有办法增加规模。如果您的 Web 应用程序的范围或受欢迎程度有可能增长，请考虑 Web 服务。通过围绕 Web 服务进行设计，您已经瞄准了模块化、多主机解决方案，因此您的应用程序可能会以更少的成长烦恼进行扩展。
如果您猜不到的话，我是网络服务迷。但以上也是我对这个问题的诚实(如果有点偏见)意见。如果你真的走 web 服务路线，一定要让它简单——将应用程序逻辑保留在应用程序中，将服务逻辑保留在服务中，并在扩展两者时尝试在它们之间划清界限。并设计您的服务以提高效率并配置托管以使其尽可能平稳运行。
关于c# - 设计 : Website calling a webservice on the same machine，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2494955/