n 层应用程序中的 WCF 服务层 : performance considerations

Question

当我上大学时，老师曾经说过，在良好的结构化应用程序中，您有表示层、业务层和数据层。这是我5年多以来听到的。
当我开始工作时，我发现这是真的，但有时最好不要只有三层。两三天前发现this article John Papa 解释了如何在分层应用程序中使用 Entity Framework 。根据那篇文章，您应该拥有:

UI 层和表示层(模型 View 模式)

服务层 (WCF)

业务层

数据访问层

对我来说，服务层是我工作以来听到的最好的想法之一。然后，您的 UI 将与业务和数据层完全“断开”。现在，当我通过查看提供的源代码进行更深入的研究时，我开始有一些问题。你能帮我回答他们吗？
问题 #0 :您认为这是一个很好的企业应用程序模板吗？
问题 #1 : 我应该在哪里托管服务层？它应该是 Windows 服务还是其他什么？
问题 #2 :在提供的源代码中，服务层只公开一个带有 WSHttpBinding 的端点。这是最具互操作性的绑定(bind)，但(我认为)在性能方面最差(由于对象的序列化和反序列化)。你同意？
问题 #3 : 如果你同意我在问题 2 中的观点，你会使用哪种绑定(bind)方式？
期待着听到您的意见。周末愉快!
马可

Answer 1

Question #0: is this a good enterpise application template in your opinion?

是的，对于大多数中间业务线应用程序来说，这可能是一个很好的起点。

Question #1: where should I host the service layer? Should it be a Windows Service or what else?

如果您对使用 WCF 服务很认真，那么是的，我建议您将它们自托管在 Windows 服务中。为什么？您不必在服务器上安装 IIS，不必依赖 IIS 来托管您的服务，您可以根据需要选择服务地址，并且您可以完全控制您的选项。

Question #2: in the source code provided the service layer expose just an endpoint with WSHttpBinding. This is the most interoperable binding but (I think) the worst in terms of performances (due to serialization and deserializations of objects). Do you agree?

不，最具互操作性的是 basicHttpBinding没有安全感。任何 SOAP 堆栈都可以连接到它。或者然后是 webHttpBinding对于 RESTful 服务 - 为此，您甚至不需要 SOAP - 只需一个 HTTP 堆栈即可。

我们用什么？？

在内部，如果 Intranet 方案正在运行(服务器和客户端在公司防火墙后面):总是 netTcp - 它是最好的、最快的、最通用的。但是在互联网上不能很好地工作:-((需要在防火墙上打开端口 - 总是很麻烦)

对外:webHttpBinding或 basicHttpBinding ，主要是因为它们易于与非 .NET 平台集成