【问题标题】:WPF/Layered Architecture Question -WPF/分层架构问题 -
【发布时间】:2011-04-13 16:17:24
【问题描述】:

我正在考虑 WPF 应用程序的高级架构。

通常我会这么想

  • 数据库服务器
  • 自己的服务器上的数据访问层
  • 自己服务器上的业务逻辑层
  • 围绕业务层的 WCF 包装器
  • 用于客户端的 UI 层。

例如一个瘦客户端,所有的魔法都发生在远程服务器上。

但是团队中有人质疑业务逻辑层是否需要在远程服务器上。为什么不把它也滚到客户端上,让它不再是瘦客户端,而更像是胖客户端服务器应用程序。

目前我们不需要 WCF,并且假设我们仍然在构建业务逻辑,因此它位于单独的层上,这对我来说在简化基础架构方面是有意义的。

我的问题是......当不需要 Web 服务时,是否有任何好的架构理由不将业务逻辑层与 UI 层一起部署到客户端机器?

我能想到 drwabacks,但这些似乎都没有那么大

  • 客户端更新的需求减少(但 clickonce 肯定会缓解这种情况)
  • 客户端计算机上的负载增加。
  • 需要确保数据库服务器足够大并且与它的连接足够大

【问题讨论】:

    标签: .net wpf wcf architecture


    【解决方案1】:

    我通常会将业务逻辑与 UI 分开。为什么 ?因为您的 UI 可能只是该服务的一个客户

    目前,您的客户是该服务的唯一消费者,但在稍后阶段,您可能希望有其他客户(包括其他服务)使用它。通过分离业务逻辑,您可以将其提供给其他消费者。

    我通常会将业务逻辑设为组件,然后我可以选择如何部署它(在客户端或服务器中)。然而,在许多情况下,我无法做到这一点。例如如果客户端和服务器使用不同的技术实现(C#/Java 是常见的组合)。

    【讨论】:

    • 我和你在一起。但是,从务实的角度出发,并减少最初的开发工作量(No WCF)。如果我们对 BLL 的架构有纪律,是否还有其他理由避免使用上述方法。
    • 查看我上面关于组件化和不同技术的 cmets。
    【解决方案2】:

    完全同意布赖恩的观点。我通常构建它的方式是在单独的服务器上拥有从客户端到业务逻辑的 Web 服务,这使它可扩展,但这完全取决于系统需要有多健壮。

    还要考虑部署,部署到 1 台服务器比部署到所有客户端更容易。不同客户端运行不同版本的业务逻辑的可能性有多大?

    【讨论】:

      【解决方案3】:

      嗯,我也完全同意布赖恩和伯特的观点。 “不同的客户端运行不同版本的业务逻辑”真的很有道理。

      基本上,关注点分离 (SoC) 是最重要的一点,它允许任何应用程序扩展至足以满足未来需求的扩展。作为一种架构,您至少应该意识到这一点并建立一些基础工作。

      当今的大多数应用程序都不是单一的,也不会保持不变。业务需求变化如此之快,因此他们也需要对应用程序进行更改。

      在设计应用程序以允许轻松扩展它们时,将可更改的内容与不可更改的内容区分开来很重要。

      HTH

      【讨论】:

        猜你喜欢
        • 2011-04-03
        • 1970-01-01
        • 2012-02-27
        • 2012-03-12
        • 2022-01-14
        • 2013-09-27
        • 1970-01-01
        相关资源
        最近更新 更多