为什么使用带有 Linq to SQL 的 Web 服务？答案

【问题标题】：Why use a web service with Linq to SQL?为什么使用带有 Linq to SQL 的 Web 服务？
【发布时间】：2010-09-20 01:56:12
【问题描述】：

谁能告诉我使用带有 asp.net gui 的 Web 服务和使用 Linq to SQL 的需要/优势是什么？ Web 服务层似乎没有必要。 Linq to SQL 对我来说是全新的，我正在研究，因为我正在建立一个新项目。有人有这方面的经验吗？

【问题讨论】：

标签： web-services linq-to-sql

【解决方案1】：

对于其他应用程序可能需要访问您的数据的情况（例如智能客户端、其他应用程序、winforms 应用程序等），您可以公开服务。很多人会使用 Web 服务进行开发，以防止自己在未来不得不重组到 Web 服务。

在几乎所有专业/企业 Web 应用程序中，您都希望将 UI 层与数据访问层分开，这样您就不会在 UI 层中嵌入 Linq to SQL 调用。相反，您将在两者之间有一个服务层，无论是它的 Web 服务、WCF，还是只是一个带有业务逻辑的 DLL，用于协调您的数据访问层。独立层更易于维护、更新、重构和学习，因此为创建它们而进行的前期投资是值得的。

【讨论】：

感谢 cfeduke！再说一次，我是新人，所以...我们的解决方案中有一个 asp.net 项目和一个 Web 服务项目 - 您是建议为 linq 创建第三个项目还是将 linq 放入 Web 服务中？
我很确定 cfeduke 说 linq 查询会在 Web 服务中安全地进行。这实际上是一个非常标准的模型，即使对于非 Web 服务实现也是如此。
是否使用 Web 服务可能取决于您的应用程序的规模。如果您的应用程序不打算部署到网络场，我们在这里进行了激烈的讨论，即不为 DAL 使用网络服务。 stackoverflow.com/questions/204653/…
是的，请记住 Web 服务层会使事情复杂化 - 对于我的项目（每天处理数十万个事务），两个负载平衡服务器以及业务服务层作为 DLL 就足够了（我们也可以在任何其他项目中引用该 DLL）。
哦，是的，Linq to SQL over WCF = 一团糟。

【解决方案2】：

这当然不是必需的，但如果您想将数据访问层保持在与演示服务器 (ASP.NET) 不同的服务器上，它会很方便。 Web 服务允许您将两个服务器之间的通信限制为仅端口 80。

请注意，这也适用于普通的旧 ADO.NET 或其他任何东西。

【讨论】：

可以将 Web 服务部署到任何端口，而不仅仅是 80。
我认为他的意思是限制到单个端口，例如 80，以确保两者之间的防火墙安全。

【解决方案3】：

Web 服务成为一个分离层，因为它们旨在作为一种与平台无关的方式将数据发送到其他软件。它们是向其他软件提供信息而不是直接向用户提供信息的网站。
WebService 是对网站进行大修的分离层，并不能完全取代良好的数据、业务逻辑和 UI 分离。
按照您的逻辑执行此操作，但要注意如果您不需要与其他软件通信，您付出的性能下降。

【讨论】：

是的，使用 Web 服务中间层有一定的开销，不要仅仅因为它听起来很整洁就这样做，只有在绝对必要时才这样做，即使那样你仍然有你的业务逻辑在某种图书馆里。

【解决方案4】：

完全同意 Ovidiu Pacurar 的观点。 Web 服务不是对关注层建模的好选择。您应该使用良好的老式 OO 设计来做到这一点。 Web 应用程序没有理由在其自身内部调用 Web 服务以进行数据访问，除非它们是为客户端 ajax 调用而设计的，或者如果您出于极端的安全考虑需要在另一台服务器上运行业务/数据层。

【讨论】：

如果它的安全问题 WCF 是一个更好的选择 IMO（只是一个 PITA）。

【解决方案5】：

同意之前的海报。您可能希望这样做以应用“关注点分离”的想法...

【讨论】：