n层应用程序中的WCF服务层:性能考虑因素

当我去大学时,老师曾经说过,在结构良好的应用程序中,你有表示层,业务层和数据层.这是我听了超过5年.

当我开始工作时,我发现这是真的,但有时候只有三层以上更好.两三天前,我发现John Papa的这篇文章解释了如何在分层应用程序中使用Entity Framework.根据那篇文章你应该:

UI层和表示层(模型视图模式)

服务层(WCF)

业务层

数据访问层

对我而言,服务层是我工作以来听过的最好的创意之一.然后,您的UI将完全从业务和数据层"双重连接".现在,当我通过查看提供的源代码深入研究时,我开始有一些问题.你能帮我解答一下吗？

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

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

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

问题3:如果您在问题2中同意我的意见,您会使用哪种绑定？

期待着听到您的意见.周末愉快!

马尔科

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

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

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

如果你真的想要使用WCF服务,那么我建议你在Windows服务中自我托管它们.为什么？你不必有IIS的服务器上,你不必依赖于IIS的托管服务,您可以根据需要选择你的服务地址,你必须对你的选择完全控制.

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

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

我们用什么？

在内部,如果Intranet场景正在发挥作用(服务器和企业防火墙后面的客户端):总是netTcp - 它是最好,最快,最通用的.虽然在互联网上不能很好地工作:-((需要在防火墙上打开端口 - 总是麻烦)

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