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

更多的设计/概念问题。设计：网站在同一台机器上调用web服务

在工作中，决定让我们的数据访问层通过webservices调用。所以我们的网站会调用webservices来处理数据库中的任何/所有数据。 Web服务的网站&将位于同一台计算机上（因此不会穿越网线），但该数据库位于单独的计算机上（因此无论如何都需要跨网线旅行）。这是全部内部的，网站，网络服务和数据库都在同一家公司内（AFAIK，网络服务不会被另一方重复使用）。

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

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

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

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

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

编辑/更新标记Dathan作为答案，我仍然没有完全销售（尽管倾斜它，我依然没有完全卖掉没有我担心的那么糟糕），他提供了一个深思熟虑的答案。我赞赏所有的反馈意见。

来源

2010-03-22 Chris L

不使用网络服务作为您的DAO的链接。这对你的代码以及你的web服务器来说是一个巨大的性能影响。为什么要添加该图层？所以你可以使用AJAX调用来打DAO？你真的想让你的用户界面直接与你的DAO对话吗？ Bad move，imho – hunter

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

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

这多少会使用吗？网站/网络服务/数据库格式确实会在网络服务器上造成稍高的开销 - 如果网站遭受攻击，您希望在将另一项服务放在同一台计算机上之前考虑花费很长时间。否则，增加的低效率可能不是什么大不了的事情。另一方面，如果网站受到重击，那么您可能想要横向扩展，并且您应该能够同时扩展Web服务。

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

您是否想要扩大？你说它可能永远不会被任何客户使用，除了单一的网络应用程序，但这些东西有一个获得规模的方式。如果您的网络应用程序有可能在范围或流行度上增长，请考虑Web服务。通过围绕Web服务进行设计，您已经瞄准了一个模块化的多主机解决方案，因此您的应用程序可能会以较少的成长困难来扩展。

如果你不能猜到，我是一个Web服务粉丝。但上述也是我对这个问题的诚实（如果有些偏见）的意见。如果你确实去了Web服务路线，一定要简单一些 - 将应用程序逻辑保留在服务中的应用程序和服务逻辑中，并且在扩展它们时尽量在它们之间画一条明亮的线。并设计您的服务以提高效率，并配置托管以保持其运行顺畅。

来源

2010-03-22 19:27:50 Dathan

@Dathan：为什么Web服务比带有与Web服务相同接口的DAO更有帮助？另外，我可能不希望我的客户访问我在应用程序中使用的相同数据访问权限。我可能希望保留某些操作，甚至是数据库的整个部分，供我自己使用，而不是将它们暴露给客户。 –

@John我在回答中指出，就界面和职责分离而言，Web服务与设计良好的进程内DAL没有实际区别。根据我的经验，网络服务可以更好地扩展。对于功能，我假设“不要将它们暴露给我的客户”，你的意思是你会发布缺乏这些功能的DAL？ Web服务通过身份验证和授权提供相同的功能。您可以通过授权限制发布的元数据和实际可访问的功能，而无需维护DAL的两个不同版本。 FTW。（C： – Dathan

@Dathan：我提供给我的客户的数据视图可能与我在我的网站上使用的数据不同，我的DAL显然会为我提供我需要的一切，就规模而言，我很乐意看到数字考虑相同数量的实际数据库服务器，服务和等效DAL之间的差异 –

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

如果客户选择不使用我们的前端网站，它还可以让我们挂钩到我们的数据库。因此我们获得了一个开放的API，只需要很少或没有额外的努力。

如果速度是您最关键的问题，那么您必须缩小层数。但是在大多数情况下，Web Service处理来自数据库的请求所花费的时间并不会增加时间。（这是假设你做你的Web服务层正确，你可以轻松地让它慢，如果你不看它。）

来源

2010-03-22 19:17:24

严，你可以有多种类型的数据库，而不使用这种Web服务额外的层次方法。 – systempuntoout

+1此外，这使应用程序更容易扩展;如果需要的话，很容易分开层，甚至可以在两者之间添加一些负载平衡。 – CodingInsomnia

@systempuntoout Yesyou可以。特别是对于NHibernate，但我们没有得到快速API，这是服务的主要原因。 –

这是有问题的设计，但你的店是不使用它的唯一的一个。

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

来源

2010-03-22 19:20:43

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

回答

相关问题