应富客户端拱在多级企业系统

Question

我们有一个相当大的企业，多层次，多层次建立在NET 3.5的溶液中使用。该系统是面向服务的体系结构（WCF服务），带有一个ASP.Net MVC用户界面。

一些球队的球员正在努力为工具系统，并正在执行这些作为直接连接到数据库（或其他数据源）WPF富客户端架构。

不知怎的，这只是感觉不对我有以下原因：

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

等等等等

我提出了一个富互联网架构的工具，使我们能够利用的扩展功能，客户端计算机可以然后提供（该浏览器可能不能够在浏览器上做或者会更难）。至少在这种情况下，主要业务逻辑仍将保留在应用程序服务器上的服务层中，并且不需要直接连接到SQL Server。

我可以了解使用富客户端对于字处理应用程序或excel，但如果你已经有一个完整的多层次的解决方案，当然它不是做的最好方法是什么？！？

我想获得的话题去，因为我不认为这是可以很容易地通过一个行响应来回答那些东西（我可能是错;-)一个很好的讨论。

您认为如何？你们过去经历过什么？我在哪里可以找到资源来证明或反驳我的观点？

---

参见：Google Earth - Rich Client or Rich Internet Architecture?

Answer 1

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

1. 不，这是SQL 服务器的原始角色。连接到同一数据库的多个应用程序 。 这与 内部网，其中多个独立的 应用程序所使用的相同DB 90年代是很常见的。数据库 支持这一点，这是 他们有这么多 安全粒度为用户 帐户（也意见， 约束e.t.c）的原因。“唯一的应用程序 服务器谈判DB”是一个较新的 模式开始在最后9-10 年
2. 是的，你是对的。建议的 解决方法是独立的 客户端访问服务器应用程序的业务逻辑 组件 而不是直接db。我不知道关于.NET的知识，但在J2EE中，这个 将意味着击中EJB或使用RMI/Web服务。这种方式业务逻辑代码只存在一次（在服务器中）。
3. 同样你是对的，但是这个 是可以解决的。在J2EE世界中，这个 是用Java Web Start解决的，因此我猜想在.NET中有一些类似的工作 。

我已经在真实世界的应用程序中使用了这种模式（Web应用程序+多个独立的应用程序，使用Web服务访问应用程序服务器），它工作得很好。

Answer 2

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

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

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

我已经看到了我所看到的相当成功的是在可以从多个不同的UI实现中访问的服务层中开发可重用服务。 RIA +服务是一个很好的，可扩展的架构模式，我感到非常自在。

Answer 3

对于所有较新的系统，我们有一个客户层与服务层进行对话，然后与服务层进行对话以与数据库对话。

http://blogs.msdn.com/blogfiles/brada/WindowsLiveWriter/Whatis.NETRIAServices_8178/image_6.png

如果你正在使用微软的技术也可用来实现这个净RIA服务：

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