C# 设计：在同一台机器上调用Web服务的网站

更多的是设计/概念问题

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

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

我同意功能之间需要有不同的层（如业务层、数据访问层等），但这对我来说太复杂了。我还感觉到，接下来会出现一些性能问题

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

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

另外，我们是一个.NET商店（从vb迁移到C#3.5）

编辑/更新

---

标记为Dathan作为答案，我仍然没有完全被说服（我仍然有点犹豫不决，尽管它可能没有我担心的那么糟糕），他提供了一个深思熟虑的答案。我感谢所有的反馈。

我喜欢这个想法，因为它给了你灵活性。我们使用非常类似的方法，因为根据客户的安装选择，我们可以有多种类型的数据库存储数据（MSSQL或Oracle）

如果客户选择不使用我们的前端网站，它还使他们能够连接到我们的数据库。因此，我们几乎不需要额外的努力就可以得到一个开放的API

---

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

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

由于您使用的是.NET 3.5并在同一台机器上运行，因此应将WCF与

netNamedPipesBinding

一起使用，它仅在同一台机器上使用命名管道上的二进制数据传输。这应该在一定程度上缓解性能问题。

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

抛开所有web服务的理由不谈，真正的问题是：

要用多少钱？网站/ Web服务/数据库格式确实在Web服务器上造成了更高的开销——如果网站被锤打，你要在把另一个服务放在同一台机器之前考虑长时间和困难。否则，额外的小效率可能不是什么大问题。另一方面，如果站点受到冲击，您可能希望横向扩展，并且您应该能够同时扩展web服务

你能得到多少？拥有web服务的一个重要原因是为客户机代码提供数据可访问性，特别是当需要支持多个可能的应用程序版本时。由于您的web应用程序是唯一使用web服务的客户端，因此这不成问题—实际上，它可能会减少应用程序自身版本的工作量

你想扩张吗？你说除了单一的web应用程序之外，它可能永远不会被任何客户端使用，但是这些东西有一种扩大规模的方式。如果你的Web应用有可能在范围或流行度上增长，那就考虑一下Web服务。通过围绕web服务进行设计，您已经瞄准了一个模块化的多主机解决方案，因此您的应用程序可能会以较少的成长烦恼进行扩展

---

如果你猜不到的话，我是一个网络服务迷。但以上也是我在这个问题上的诚实（尽管有些偏见）的观点。如果你确实选择了web服务路线，那么一定要让它变得简单——在应用程序中保留应用程序逻辑，在服务中保留服务逻辑，并在扩展两者时尝试在两者之间划出一条清晰的界线。请务必为提高效率而设计服务，并配置主机以使其尽可能平稳地运行。

不要将web服务用作DAO的链接。这对代码和web服务器都是一个重要的性能影响。为什么要添加该层？那么您可以使用AJAX调用访问DAO？您真的希望UI直接与DAO对话吗？糟糕的举动，嗯，你可以有一种以上的da