ASP.NET MVC Web 应用程序中的视图逻辑和域逻辑之间的混淆

Question

我在域/应用程序逻辑和用户界面逻辑之间感到困惑。为了说明我试图确定的内容，我将在下面描述一个虚构的程序以进行说明：

(1) 想象一个带有一组 3 个级联下拉菜单的小型应用程序。当您选择一个下拉菜单时，它会触发一个 jQuery Ajax GET，该 GET 最终会到达一个 MVC 控制器，提供先前选择的下拉菜单的选定值。控制器为下一个下拉菜单返回允许的选项。 javacript（在视图中）将这些结果排列到下拉列表中。等等。因此，每次您选择一个下拉菜单时，都会填充下一个下拉菜单。

(2) 现在扔扳手..有一些例外。假设如果用户在第一个下拉菜单中选择“FOO”或“BAR”，那么行为会发生变化，因此第二个下拉菜单被禁用，而第三个下拉菜单将显示一个 texbox。

我的问题是，在 MVC 的上下文中，这个“决策”逻辑的合适位置是什么？比如我在 (2) 中解释的负责做出这些决定的代码。我把它放在最方便的地方就是在视图的 javascript 中。我只是编写了javascript来测试第一个框是“FOO”还是“BAR”，然后禁用第二个下拉菜单，并将第三个下拉菜单换成文本框。但这对我来说并不完全正确。因为它看起来应该是业务逻辑，因此代码应该属于某个地方的域层。但这也感觉不太对。

所以我觉得我在绕圈子。有人能解释一下这个小设计吗？

Answer 1

在您发生非常特殊的操作的情况下，您需要将其放入 js 中的逻辑中，就像您在下拉示例中所做的那样。您还总是希望将验证放在服务器端，以确保您的数据是干净的。

随着 MVC 2 的出现，他们正在进行一些非常棒的验证服务器/客户端验证。查看 Scott Gu 的帖子，了解更多信息：MVC 2 Blog Post

Answer 2

不要分裂太多头发或过于狂热必须做些什么来保持模式的纯粹...

显然，控制器知道必须进行此更改，因为它将处理两种结果情况（下拉选择或文本输入）。所以将与此相关的逻辑放在 Controller 中不是罪过。

同样明显的是，视图必须根据第一个下拉菜单的内容来改变它的显示方式。虽然这种行为的混合并不是我能想象到的最好的 UI 体验，但如果需要，那么 UI 中必须存在某种程度的逻辑。但是，天哪，这是我们在这里谈论的网站。你真的想从 javascript 中删除所有逻辑并将其移动到控制器方法中吗？ View 决定如何显示数据，这是它的工作，所以 不可能是罪。

避免在火刑柱上被烧毁的真正方法是重新设计以避免首先引起争议。或者，只是编写代码，然后一边喝啤酒一边抱怨你糟糕的设计要求。

Answer 3

让我们从领域模型开始。域模型是一种 API，它以技术中立的方式对域进行建模。它对诸如 JQuery、HTML 或（就此而言）XAML 或 Windows 窗体之类的 View 技术一无所知。

领域模型包含描述领域的类和接口，让您能够以丰富且富有表现力的方式对领域概念进行建模 - 无论您正在开发何种类型的应用程序。

考虑到这一点，很容易看出您描述的显示逻辑不属于域模型。因此，它必须属于特定于 UI 的层。

你可以把它放在一个单独的 UI Logic 模块中，或者和你的 UI 应用程序一起——在你的例子中是一个 ASP.NET MVC 应用程序。是用 JavaScript 还是服务器端表达所需的 UI 逻辑并不重要。

就个人而言，我会在 Partial Views 中定义这个逻辑服务器端，但那是因为我非常关心可测试性，而且我知道如何对这种行为进行单元测试（有人告诉我可以对 JQuery 代码进行单元测试也一样，但我不知道这是不是真的）。​​

如果您最终基于相同的域模型编写另一个应用程序，那么显示逻辑很可能会非常不同，因为不同的技术意味着不同的范例。

Answer 4

鉴于您的示例，我不介意控制器中的这种逻辑，它绝对不属于域模型。我个人觉得在控制器中获取 ajax GET 请求并决定使用 JSON 从那里输出什么而不是在 jQuery 中执行所有逻辑（我只是在 C# 中感觉比在 javascript 中更舒服）。话虽如此，我喜欢让我的操作方法保持精简，所以我要做的是将涉及的逻辑与计算出在控制器上的方法中填充下拉列表的内容相关联，并用 [NonAction] 装饰它。