Rich Client Arch是否应在多层企业系统中使用

Question

我们有一个基于.Net 3.5的相当大的企业级，多层，多层解决方案。该系统是面向服务的体系结构（WCF服务），其中包含ASP.Net MVC用户界面。

团队中的一些人正在为系统工作，并将这些工作实现为直接连接到数据库（或其他数据源）的WPF富客户端架构。

由于以下原因，这对我来说感觉不对：

1. 这将要求SQL Server需要直接由许多机器（运行工具）访问。是不是只允许应用程序层连接到数据库层的最佳做法？无论如何都将使用传递身份验证来实现可审计性，因此管理多个登录帐户的开销不是问题。
2. 必须发生业务逻辑的重复（或至少分发）。它不必托管要重用的服务器上的业务逻辑，而是必须驻留在每台客户机上。
3. 维护多个客户端安装：现在，每次发布新版本的工具时，所有这些计算机都必须单独更新。好的，您仍然可以使用一键式保持自动更新。

等等。

我为这些工具建议了一个富Internet体系结构，以便我们可以利用客户端机器可以提供的扩展功能（浏览器可能无法执行或浏览器上的功能更难） 。至少在这种情况下，主业务逻辑仍将保存在应用程序服务器的服务层中，并且不需要与SQL Server的任何直接连接。

我可以理解使用Rich Clients来处理word或excel等应用程序，但是如果你已经拥有一个完整的多层解决方案，那肯定不是最好的方法吗？！？

我想就这个话题进行一次很好的讨论，因为我不认为这是一个可以通过一行回答轻易回答的事情之一（我可能错了; - ）。

你怎么看？你们过去经历过什么？我在哪里可以找到证明或反驳上述观点的资源？

---

另请参阅：Google Earth - Rich Client or Rich Internet Architecture?

Answer 1

是的，他们可以/应该被使用！。评论你的理由：

1. 不，这是SQL的原始角色 服务器。多个应用程序 连接到同一个数据库。 这在90年代非常普遍 多个独立的内部网 应用使用相同的数据库。数据库 支持这个很好，这是 他们有这么多的原因 用户的安全粒度 帐户（以及观点， 约束e.t.c）。 “唯一的应用程序 服务器与DB的对话“是一个更新的 模式始于最后的9-10 年
2. 是的，你是对的。推荐 解决这个问题的方法是独立的 客户达到了业务逻辑 服务器应用程序的组件 而不是直接的数据库。我不 了解.NET，但在J2EE中 意味着要点击EJB或使用 RMI / Web服务。这种方式业务逻辑代码只存在一次（在服务器中）。
3. 再一次，你是对的，但又是这个 是可以解决的。在J2EE世界中 用Java Web Start解决了这个问题 猜猜类似的东西有效 在.NET。

我已经在现实世界的应用程序中使用了这种模式（Web应用程序+多个独立应用程序，这些应用程序可以通过Web服务访问应用程序服务器），并且运行正常。

Answer 2

如果你有一个具有任何重要逻辑的服务层，那么我觉得绕过它从RIA UI直接进入数据库是非常危险的。

这显然是一种权衡，从UI开发人员的角度来看，他们觉得他们觉得自己可以更快地提供价值，并且可能在短期内看到更好的表现。

从长远来看，我认为您倾向于在UI层以及UI和服务层之间看到业务逻辑的重复，并且您可能会错过服务层中缓存提供的性能优化机会。

我已经看到了我所看到的相当大的成功是在服务层开发可以从几个不同的UI实现访问的可重用服务。我很高兴RIA +服务是一种良好的，可扩展的架构模式。

Answer 3

对于所有较新的系统，我们都有一个与服务层对话的客户层，而服务层又与数据库进行通信。

_{（来源：msdn.com）}

如果您使用的是Microsoft技术，可以使用.Net RIA服务来实现此目的：

http://blogs.msdn.com/brada/archive/2009/03/19/what-is-net-ria-services.aspx