2010-04-10 123 views
9

当我去大学时,老师常说,在良好的结构化应用程序中,您有表示层,业务层和数据层。这是我听了超过5年。n层应用程序中的WCF服务层:性能考虑

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

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

服务对我来说,图层是我工作以来听过的最好的创意之一。然后,您的用户界面完全从业务和数据层“连接”。现在,当我深入查看提供的源代码时,我开始有一些问题。你能帮我回答他们吗?

问题#0:这是一个很好的enterpise应用程序模板在你看来?

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

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

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

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

马尔科

回答

5

问题#0:这是在你看来一个好的enterpise 应用程序模板?

是的,对于大部分中间道路行业应用,这可能是一个很好的起点。

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

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

问题2:在提供的服务层的源代码 暴露只是 与WsHttpBinding的端点。这 是最具互操作性的结合,但是 (我认为)最差的 表演(由于系列化和对象的 deserializations)条款。你同意 吗?

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

我们用什么?

  • 内部,如果Intranet的场景是在游戏中(服务器和企业防火墙后面的客户端):总是netTcp - 这是最好的,速度最快,功能最全的。难道不能通过互联网很好的工作,虽然:-((需要在防火墙上打开端口 - 总是件麻烦事)

  • 外部:webHttpBindingbasicHttpBinding,主要是因为它们易于集成与non-.NET平台

+1

好,所以在我需要打开我的业务层到内部应用程序的情况下,你建议netTcp,但如果这必须由外部应用程序访问,你建议webHttpBinding或webHttpBinding。完善。非常感谢。 – Marconline 2010-04-10 18:11:57

+0

是的,绝对使用netTcp的内部应用程序和访问 - 你最好的选择。从外部来看,通常是不可能的(因为事实上你必须在防火墙上打洞,才能使流量通过 - 大部分几乎不可能做到......) – 2010-04-10 20:19:13

1

这里是我5毛钱:

0:是

1:我会在IIS托管,因为它是很容易,让你的地方快速启动

2:如果您需要安全则肯定是有的,去与WsHttpBinding的(或者甚至wsFederationHttpBinding如果你想要更多FANCE安全)。它在实践中表现得相当快,尽管如你所说,它确实有一些开销,并且可能很难从其他平台(如Java)调用。

3:N/A

最后,请记住在一个单独的组件,其既可以从服务的dll 消费者在UI层被引用来定义服务数据合同的对象。

+0

好的,谢谢你的意见! – Marconline 2010-04-10 18:10:27

1

难道你的老师也告诉你为什么你应该建立这样的架构;-)?我在你的问题中缺少的是你的要求。在我们任何人都可以告诉你这是一个好的架构还是模板之前,我们必须知道应用程序的要求。应用程序的非功能需求或实际应该推动架构的设计。

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

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

问题#0:这是在你看来一个好的enterpise应用程序模板?

您使用图层体系结构模式,这意味着图层可以更容易地相互独立演变。最常用的架构模式之一,请注意,这种模式也有缺点(性能,可追溯性)。

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

难以回答。在IIS中托管服务有两个优点,它更容易扩展,并且可追踪性更容易(IIS中的WCF具有大量监视器选项)。在Windows服务中托管服务可为您提供更多绑定选项(命名管道绑定/ TCP绑定)。

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

表现明智WSHttpBinding的成本更高,但它在互操作性方面得分较高。所以选择取决于你的非功能性需求。

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

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

相关问题