更多的设计/概念问题。
在工作中决定通过webservices调用我们的数据访问层。因此，我们的网站将调用webservices以获取进出数据库的任何/所有数据。网站和＆amp; webservices将在同一台机器上（所以没有通过电线跳闸），但数据库是在一个单独的机器上（所以无论如何都需要穿越电线）。这些都是内部的，网站，网络服务和数据库都在同一家公司内（AFAIK，webservices不会被另一方重用）。
据我所知：该网站将打开一个到webservices的端口，webservices将依次打开另一个端口并通过线路连接到数据库服务器以获取/提交数据。穿越电线的旅程无法避免，但我担心站在中间的网络服务。
我同意在功能（例如业务层，数据访问层等）之间需要有不同的层，但这对我来说似乎过于复杂。我也感觉到会有一些性能问题。
在我看来，最好在解决方案中直接引用（DAL）程序集，从而取消第一个端口到端口的连接。
赞赏和反对这个想法的任何想法（或链接）将不胜感激
P.S。我们是一个.NET商店（从vb迁移到C＃3.5）
编辑/更新 标记大坍作为答案，我还没有被完全卖掉（我仍然有点畏缩，尽管它可能没有我担心的那么糟糕），他提供了一个深思熟虑的答案。我很感激所有的反馈。
答案 0 :(得分：2)
这是一个值得怀疑的设计，但您的商店并不是唯一使用它的商店。
由于您使用的是.NET 3.5并且在同一台计算机上运行，因此您应该使用带有netNamedPipesBinding的WCF，它使用命名管道上的二进制数据传输，仅在同一台计算机上。这应该会在一定程度上缓解性能问题。
答案 1 :(得分：2)
这两个设计（应用程序到网络服务到数据库;应用程序到数据库通过DAL）是非常标准的。 Web服务通常在与客户端连接时使用，以标准化数据访问的语义。 Web服务通常能够比底层持久性存储更准确地表示数据模型的语义，从而通过抽象和封装特定于IO的关注点来帮助系统的可维护性。 Web服务还有另外的目的，即通过通常可跨防火墙访问的协议为您的数据提供公共接口（尽管“公共”可能仍然意味着公司内部）。使用DAL直接连接到数据库时，可以以类似的方式封装数据IO问题，但最终您的客户端必须能够直接访问数据库。通过将IO限制为定义良好的语义（通常是CRUD + Query），可以添加额外的安全层。这对你来说并不是什么大问题，因为你正在运行一个Web应用程序 - 所有数据库访问都是通过可信代码完成的。但是，Web服务确实提高了SQL注入的稳健性。
除了所有网络服务理由外，真正的问题是：
它将被使用多少？网站/网络服务/数据库格式确实会给网络服务器带来稍高的开销 - 如果网站受到重创，你需要考虑之前的漫长而艰难同一台机器上的另一项服务。否则，增加的小的低效率可能不是什么大问题。另一方面，如果网站受到重创，您可能还是想要横向扩展，并且您应该能够同时扩展Web服务。
获得多少收益？拥有Web服务的一个重要原因是为客户端代码提供数据可访问性 - 尤其是在需要支持多个可能的应用程序版本时。由于您的Web应用程序是唯一使用Web服务的客户端，因此这不是一个问题 - 实际上可能不那么费力地对应用程序进行版本化。
您是否正在寻求扩展？您说它可能永远不会被单个网络应用程序以外的任何客户端使用，但这些东西都有增加规模的方法。如果您的Web应用程序有可能在范围或受欢迎程度上增长，请考虑Web服务。通过围绕Web服务进行设计，您已经将目标锁定在一个模块化的多主机解决方案上，因此您的应用程序可能会以更少的成长难度进行扩展。
如果您无法猜测，我是网络服务迷。但以上也是我对这个问题的诚实（如果有些偏见）意见。如果您确实使用Web服务路由，请务必将其简化 - 将应用程序逻辑保留在服务中的应用程序和服务逻辑中，并在扩展两者时尝试在它们之间绘制一条亮线。并且设计您的服务以提高效率并配置托管以使其尽可能顺利地运行。
答案 2 :(得分：1)
我喜欢这个主意，因为它给你灵活性。我们使用非常类似的方法，因为根据我们的客户安装选择，我们可以有多种类型的数据库存储我们的数据（MSSQL或Oracle）。
如果他们选择不使用我们的前端网站，它还可以让客户加入我们的数据库。因此，我们获得了一个开放的API，几乎没有额外的努力。
如果速度是您最关键的问题，那么您必须减少图层。但是，在大多数情况下，Web Service处理数据库请求所需的时间不会增加时间。 （假设你正确地进行了Web服务层，如果你不看它就可以轻松地使它变慢。）