n 层应用程序中的 WCF 服务层：性能注意事项答案

【问题标题】：WCF Service Layer in n-layered application: performance considerationsn 层应用程序中的 WCF 服务层：性能注意事项
【发布时间】：2011-02-06 11:41:23
【问题描述】：

当我上大学时，老师曾经说过，在良好的结构化应用程序中，您有表示层、业务层和数据层。这是我 5 年多以来听到的。

当我开始工作时，我发现这是对的，但有时不只是三层更好。两三天前，我发现了 John Papa 的 this article，它解释了如何在分层应用程序中使用实体框架。根据那篇文章，你应该有：

UI 层和表示层（模型视图模式）
服务层 (WCF)
业务层
数据访问层

对我来说，服务层是我工作以来听到的最好的想法之一。然后，您的 UI 将与业务和数据层完全“断开”。现在，当我通过查看提供的源代码进行更深入的研究时，我开始有一些问题。你能帮我回答一下吗？

问题#0：您认为这是一个好的企业应用程序模板吗？

问题 #1：我应该在哪里托管服务层？它应该是 Windows 服务还是其他什么？

问题#2：在提供的源代码中，服务层只公开了一个带有 WSHttpBinding 的端点。这是最具互操作性的绑定，但（我认为）在性能方面最差（由于对象的序列化和反序列化）。你同意吗？

问题 #3：如果您在问题 2 中同意我的观点，您会使用哪种绑定方式？

期待您的来信。周末愉快！

马可

【问题讨论】：

标签： wcf architecture performance

【解决方案1】：

问题#0：这是一家好企业吗？您认为申请模板？

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

问题 #1：我应该在哪里举办服务层？它应该是一个Windows 服务还是什么？

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

问题 #2：在源代码中只要服务层暴露带有 WSHttpBinding 的端点。这是最具互操作性的绑定，但（我认为）最糟糕的是表演（由于序列化和对象的反序列化）。你同意吗？

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

我们用什么？？

在内部，如果 Intranet 方案正在运行（服务器和客户端位于公司防火墙后面）：总是 netTcp - 它是最好、最快、最通用的。但是在互联网上效果不佳:-(（需要在防火墙上打开端口 - 总是很麻烦）
外部：webHttpBinding 或 basicHttpBinding，主要是因为它们易于与非 .NET 平台集成

【讨论】：

好的，所以在我需要向内部应用程序打开业务层的情况下，您建议使用 netTcp，但如果必须由外部应用程序访问，您建议使用 webHttpBinding 或 webHttpBinding。完美的。非常感谢。
是的，绝对使用 netTcp 进行内部应用程序和访问 - 您的最佳选择。在外部，这通常是不可能的（因为事实上你必须在防火墙上戳洞才能让流量通过——几乎不可能做到……）

【解决方案2】：

这是我的 5 美分：

0：是的

1：我会先将它托管在 IIS 中，因为它非常简单，而且可以让你快速到达某个地方。

2：如果您需要安全性，那么肯定是的，请使用 WSHttpBinding（如果您想要更多的安全性，甚至可以使用 wsFederationHttpBinding）。尽管正如您所说，它在实践中执行得相当快，但确实有一些开销，并且很难从其他平台（例如 java）调用。

3：不适用

最后，请记住在单独的程序集中定义服务的数据合同对象，该程序集可以从服务 dll 和 ui 层中的使用者引用。

【讨论】：

【解决方案3】：

您的老师是否也告诉过您为什么要创建这样的架构 ;-) ？我在您的问题中缺少的是您的要求。在我们任何人告诉您这是否是一个好的架构或模板之前，我们必须知道应用程序的要求。应用程序的非功能性需求或缺陷应该驱动架构的设计。

我想知道您的应用程序最重要的非功能性需求是什么？（可维护性、可移植性、可靠性或......）。例如看看http://en.wikipedia.org/wiki/ISO/IEC_9126 或http://www.serc.nl/quint-book/

我认为我们架构师应该根据业务需求创建架构。这意味着我们架构师应该让业务更加意识到非功能性需求的重要性。

问题 #0：您认为这是一个好的企业应用程序模板吗？

您使用层架构模式，这意味着层可以更容易地相互独立发展。最常用的架构模式之一，请注意，这种模式也有缺点（性能、可追溯性）。

问题 #1：我应该在哪里托管服务层？它应该是 Windows 服务还是其他什么？

很难回答。在 IIS 中托管服务有两个优点，它更容易扩展和更容易跟踪（IIS 中的 WCF 有很多监视器选项）。在 Windows 服务中托管服务可为您提供更多绑定选项（命名管道绑定/ TCP 绑定）。

问题 #2：在提供的源代码中，服务层只公开了一个带有 WSHttpBinding 的端点。这是最具互操作性的绑定，但（我认为）在性能方面最差（由于对象的序列化和反序列化）。你同意吗？

在性能方面，WSHttpBinding 成本更高，但它在互操作性方面得分很高。所以选择取决于你的非功能性需求。

问题 #3：如果您在问题 2 中同意我的观点，您会使用哪种绑定方式？

命名管道和 TCP 绑定非常快。名称管道绑定仅应在单机通信时使用。 TCP 绑定可能是一个选项，但您必须在防火墙中打开一个特殊端口。

【讨论】：

【解决方案4】：

我知道这个问题很老，但我在搜索当前架构问题时发现了它，即重构为 Web 应用程序提供服务的服务层。在谷歌上搜索时，我发现了微软的这些更现代的指南，希望这可以帮助某人，这里是链接：

关于业务层和不鼓励的贫血领域模型https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/microservice-domain-model
关于数据持久层 https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/infrastructure-persistence-layer-design

整个模式书可以下载为 pdf 格式。

[编辑] 通过文档，我发现了一种技术，根据我的经验，它有助于避免大量的 switch case 并应用强大的模式来解决复杂的问题。建议的实现比我的好（我不得不使用旧的 c# 版本）：https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/enumeration-classes-over-enum-types

【讨论】：