业务逻辑不在表示层上

Question

在RIA应用程序中，您应该在RIA层（flash / silverlight等）之外放置尽可能多的业务逻辑。这背后的原因是什么？进入表示层的任何逻辑都可以更快地执行...

这是因为RIA技术很可能需要改头换面，你必须重写所有业务逻辑吗？

Answer 1

我不确定我是否同意您的前提，即您“应该”将业务逻辑放在客户端之外。您 应该将业务逻辑移到UI层之外，但在您点击后端Web服务之前，通常仍会有几个客户端层。例如，典型的Silverlight应用程序基于MVVM模型，该模型规定了没有业务逻辑的View，具有相当大的验证和业务逻辑块的ViewModel，以及具有其余部分的模型。所有这一切都在客户端。

另一方面，您确实需要服务器上的业务逻辑层。您不能依赖客户端应用程序来过滤掉所有不良数据：有人可能正在运行旧版本的客户端，或者完全不同的客户端，或者可能正在尝试破解您的系统。

换句话说，理想情况下，您应该在客户端和服务器上执行业务逻辑和验证：在客户端上，因为您需要响应，并且在服务器上，因为您需要安全性。问题是如何得到这个，并没有任何完美的答案。

Silverlight应用程序中常用的一种方法（我不太熟悉Flash）是使用WCF RIA服务，它允许您在一个地方创建在客户端和服务器上执行的验证。即使您没有使用WCF RIA Services框架，通过链接到客户端和Web服务上的验证/业务逻辑类的源代码，您仍然可以获得更多相同的效果 - 这是更多的工作，但仍然可能比编写两次验证并手动保持同步的工作要少。

Answer 2

业务逻辑是一个贯穿各领域的关注点。

您的用户是否会输入日期？如果是这样，接口需要知道它们是日期以给它们一个选择器，并防止无效条目。甚至可能将条目限制在一个范围内。这是业务逻辑。你怎么能保持它并仍然有一个有意义的界面？

用户是否会随时进入美国各州或省？如果是这样，则必须填充下拉列表，这意味着UI“知道”外键。

用户可以看到但不会改变的字段吗？为什么或者为什么不？这是业务逻辑。某些用户可以根据特定条件进行限制吗？这是商业逻辑。

这并不意味着UI知道所有业务逻辑，当然，许多数据移动操作与UI无关。

但最后问题不在于如何将BL保留在UI之外，你不能这样做，问题是UI中将包含哪种BL。这往往归结为类型，值范围，允许的操作等等。

因此，要么UI从较低层获取所有信息，要么在UI层中再现一些信息。

Answer 3

因此，一个原因是可维护性。如果客户端已遍布各处，则在简单业务规则更改时无需重新安装或重新下载。只需将更改部署到后端即可完成设置。

它还可以让您在防火墙后面隐藏数据库。如果您的所有业务逻辑都在前端，则可能需要公开公开数据库，以便可以在客户端上执行业务逻辑。

但我担心“业务逻辑”是一个超载的术语。什么是“业务逻辑”？正确的架构是最符合您的应用和需求的架构。

正如@Ken Smith所说，你当然应该避免在你的UI层中使用业务逻辑。这是为了可测试性，可维护性，可设计性等。但这并不意味着一切都进入后端，尤其是在具有重要UI规则的RIA应用程序中。在MVVM应用程序（Silverlight）或Presentation Model应用程序（Flex）中，您将UI BEHAVIOR放在ViewModel或PresentationModel层中。然后，您将任何级别的业务逻辑放在模型中。业务逻辑可能只是一些验证。它可能更多。这取决于您的架构。