在 RIA 应用程序中，您应该将尽可能多的业务逻辑放在 RIA 层之外（flash/silverlight 等）。这背后的原因是什么？任何进入表示层的逻辑都可以获得执行速度更快的好处......
这是因为 RIA 技术很可能需要改头换面，而您将不得不重写所有业务逻辑？
【问题讨论】：
标签： silverlight apache-flex flash architecture ria
我不确定我是否同意您的前提，即您“应该”将业务逻辑放在客户端之外。您应该将业务逻辑移到 UI 层之外，但在您使用后端 Web 服务之前，通常还剩下几个客户端层。例如，一个典型的 Silverlight 应用程序基于 MVVM 模型，它规定了一个没有业务逻辑的视图，一个具有相当多的验证和业务逻辑的 ViewModel，以及一个模型，它拥有其余部分。所有这些都在客户端。
另一方面，您也确实需要在服务器上设置一个业务逻辑层。您不能依靠客户端应用程序来过滤掉所有不良数据：有人可能正在运行旧版本的客户端，或者完全不同的客户端，或者可能试图破解您的系统。
换句话说，理想情况下，您应该在客户端和服务器上执行业务逻辑和验证：在客户端上，因为您需要响应能力，而在服务器上，因为您需要安全性。问题是如何得到这个，并没有完美的答案。
Silverlight 应用程序（我对 Flash 不太熟悉）中通常采用的一种方法是使用 WCF RIA 服务，它允许您在一个地方创建在客户端和服务器上都执行的验证。即使您没有使用 WCF RIA 服务框架，您仍然可以通过在客户端和 Web 服务上链接到验证/业务逻辑类的源代码来获得很多相同的效果——这需要更多的工作，但仍然可能比编写两次验证并手动保持同步要少。
【讨论】：
业务逻辑是一个横切关注点。
您的用户会输入日期吗？如果是这样，界面需要知道它们是日期，以便为它们提供选择器，并防止无效条目。甚至可能将条目限制在一个范围内。这就是业务逻辑。怎样才能在保留它的同时保持有意义的界面？
用户会随时进入美国的州或省吗？如果是这样，则必须填充下拉列表，这意味着 UI“知道”外键。
是否会有用户可以看到但不能更改的字段？为什么或者为什么不？这就是业务逻辑。某些用户可以根据某些条件执行的操作是否会受到限制？这就是业务逻辑。
这并不意味着 UI 了解所有业务逻辑，当然，许多数据移动操作与 UI 无关。
但最终的问题不是如何将 BL 排除在 UI 之外，你不能那样做，问题是 UI 中会出现哪种 BL。这往往归结为类型、值的范围、允许的操作等等。
因此，UI 要么从较低层获取所有这些信息，要么在 UI 层中复制其中的一些信息。
【讨论】：
因此，一个原因是可维护性。如果客户端已经分布在各地，当简单的业务规则发生变化时，您不需要重新安装或重新下载。只需将更改部署到后端即可。
它还允许您执行诸如将数据库隐藏在防火墙后面之类的操作。如果您所有的业务逻辑都在前端，那么您可能需要将数据库公开，以便业务逻辑可以在客户端执行。
但我担心“业务逻辑”是一个过度使用的术语。什么是“业务逻辑”？正确的架构是最适合您的应用程序和需求的架构。
正如@Ken Smith 所说，您当然应该避免在 UI 层中使用业务逻辑。这是为了可测试性、可维护性、可设计性等。但这并不意味着一切都进入后端，尤其是在具有重要 UI 规则的 RIA 应用程序中。在 MVVM 应用程序 (Silverlight) 或 Presentation Model 应用程序 (Flex) 中，您将 UI BEHAVIOR 放在 ViewModel 或 PresentationModel 层中。然后，您将任何级别的业务逻辑放在您的模型中。该业务逻辑可能只是一些验证。可能更多。这取决于您的架构。
【讨论】：