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

Question

更多的设计/概念问题。

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

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

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

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

任何支持和反对这一想法的想法（或链接）都将受到赞赏

PS我们是一个.NET商店（从vb迁移到C＃3.5）

编辑/更新Marked Dathan作为答案，我还没有完全卖掉（我仍然有点畏缩，尽管它可能没有我担心的那么糟糕），他提供了一个深思熟虑的答案。 我很感激所有的反馈。

Answer 1

这是一个值得怀疑的设计，但您的商店并不是唯一使用它的商店。

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

Answer 2

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

除了所有的Web服务理由之外，真正的问题是：

它会用多少钱？ 网站/网络服务/数据库格式确实会对网络服务器产生稍高的开销 - 如果网站受到重创，您需要在将另一项服务放在同一台计算机上之前考虑很长时间。 否则，增加的小的低效率可能不是什么大问题。 另一方面，如果网站受到重创，您可能仍希望水平扩展，并且您应该能够同时扩展Web服务。

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

你想扩大吗？ 你说它可能永远不会被单个网络应用程序以外的任何客户端使用，但这些东西都有增加大小的方法。 如果您的Web应用程序有可能在范围或受欢迎程度上增长，请考虑Web服务。 通过围绕Web服务进行设计，您已经将目标锁定在模块化的多主机解决方案上，因此您的应用程序可能会以较少的成长难度进行扩展。

如果您无法猜测，我是一名网络服务迷。 但以上也是我对这个问题的诚实（如果有些偏见）意见。 如果您确实使用Web服务路由，请务必将其简化 - 将应用程序逻辑保留在服务中的应用程序和服务逻辑中，并在扩展两者时尝试在它们之间绘制一条亮线。 并且设计您的服务以提高效率并配置托管以使其尽可能顺利地运行。

Answer 3

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

如果客户选择不使用我们的前端网站，它还可以让客户加入我们的数据库。 因此，我们获得了一个开放的API，几乎没有额外的努力。

如果速度是您最关键的问题，那么您必须减少图层。 但是，在大多数情况下，Web Service处理数据库请求所需的时间不会增加时间。 （这假设您正确地执行Web服务层，如果不观察它，可以轻松地使其变慢。）