当我去大学时，老师曾经说过，在结构良好的应用程序中，你有表示层，业务层和数据层。这是我听了超过5年。
当我开始工作时，我发现这是真的，但有时最好只有三层。两三天前，我发现John Papa this article解释了如何在分层应用程序中使用Entity Framework。根据那篇文章你应该：
对我来说，服务层是我工作以来听过的最好的创意之一。然后，您的UI将完全从业务和数据层“划分”。现在，当我通过查看提供的源代码深入研究时，我开始有一些问题。你能帮我解答一下吗？
问题＃0 ：您认为这是一个很好的企业应用模板吗？
问题＃1 ：我应该在哪里托管服务层？它应该是Windows服务还是其他什么？
问题＃2 ：在提供的源代码中，服务层只公开了一个带有WSHttpBinding的端点。这是最具互操作性的绑定，但（我认为）在性能方面最差（由于对象的序列化和反序列化）。你同意吗？
问题＃3 ：如果您在问题2中同意我，您会使用哪种绑定？
期待收到你的来信。祝周末愉快！
马
答案 0 :(得分：6)
问题＃0：这是一个很好的企业 您认为申请模板？
是的，对于大多数中间业务线应用来说，它可能是一个很好的起点。
问题＃1：我应该在哪里举办 服务层？应该是Windows吗？ 服务还是其他什么？
如果您认真使用WCF服务，那么我建议您在Windows服务中自行托管它们。为什么？您不必在服务器上安装IIS，也不必依赖IIS来托管您的服务，您可以根据需要选择服务地址，并且可以完全控制您的选项。
问题＃2：在源代码中 只要服务层公开 WSHttpBinding的端点。这个 是最具互操作性的绑定但是 （我认为）最糟糕的 表演（由于序列化和 对象的反序列化）。你呢 同意？
不，最具互操作性的是basicHttpBinding，没有安全性。任何SOAP堆栈都可以连接到它。或者然后是webHttpBinding用于RESTful服务 - 为此，您甚至不需要SOAP - 只需要一个HTTP堆栈。
我们使用什么？
内部，如果Intranet场景正在发挥作用（服务器和企业防火墙后面的客户端）：总是netTcp - 它是最好，最快，最通用的。虽然在互联网上运行不好:-(（需要在防火墙上打开端口 - 总是麻烦）
外部：webHttpBinding或basicHttpBinding，主要是因为它们易于与非.NET平台集成
答案 1 :(得分：1)
这是我的5美分：
0：是的
1：我首先将它托管在IIS中，因为它非常简单，可以快速到达某个地方。
2：如果您需要安全性，那么肯定是的，请使用WSHttpBinding（或者如果您想要更多的安全性，甚至可以使用wsFederationHttpBinding）。它在实践中表现得相当快，尽管如你所说，它确实有一些开销，并且很难从其他平台（例如java）调用。
3：N / A
最后，请记住在单独的程序集中定义服务的数据协定对象，可以从服务dll 和引用ui层中的使用者。
答案 2 :(得分：1)
您的老师是否也告诉您为什么要创建这样的架构;-)？我在你的问题中遗漏的是你的要求。在我们任何人告诉您这是一个好的架构或模板之前，我们必须知道应用程序的要求。应用程序的非功能性需求或功能应该推动架构的设计。
我想知道您的应用程序最重要的非功能需求是什么？ （可维护性，可移植性，可靠性或......）。例如，请查看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绑定可能是一个选项，但您必须在防火墙中打开一个特殊端口。